Electron, v3

Project Setup

Steve Kinney

Steve Kinney

Electron, v3

Check out a free preview of the full Electron, v3 course

The "Project Setup" Lesson is part of the full, Electron, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Steve walks through the contents of the Firesale app's index.ts file. Updating the index.ts to not show the application window until it's fully loaded and where the dev tools should be shown is also demonstrated in this segment.


Transcript from the "Project Setup" Lesson

>> We could do the eating our vegetables where we do everything the hard way first. In the interest of time and attention, I'm going to use Electron Forge to kind of give us a solid foundation here. Because, again, it will have a lot of those processes wired up and ready to go.

And also I think it becomes useful cuz it's a great way to look at it and then be able to see how to engineer that ourselves. So I am going to pause for a minute, and I would say that over here we've got the three repositories. The first one we're gonna use is this one here called Firesale.

You don't need to download anything over here, these are just useful if you need it, Electron Fiddle is useful. First one we're gonna do is Markdown Editor that we talked about earlier. So I would say, if you have not pulled it down and done the requisite npm installs, let's just do that for a moment.

We took a look at a just first vanilla Electron app. You will see that there is not a lot different in this Electron Forge app. But there are a few additional tasting notes that we should talk about. One is, despite the fact that it doesn't look that much different, this is in TypeScript, right?

Like I said, most TypeScript these days, you could probably copy and paste this directly to JavaScript and not have an issue whatsoever, right? But this is technically a TypeScript file, so we've got that in place. Electron Forge is running either Webpack or a Vite server to do the hot module reloading.

So we do have a dev server that is running, and so it is running localhost, whatever it runs. The Webpack version, I think it's running at port 9000. For the Vite version, I believe it's 5173. Why that lives rent-free in my head, I don't know, but I believe those are true.

Otherwise, it will go ahead and try to load the compiled assets, right? So that's just for us in development, something that we have in that case as well. And then, at this moment, I am choosing to load the Dev Tools open in the detached mode. Again, you can put in whatever mode you want, you want it at the bottom, you want it at the side.

These are not particularly big windows, so I've chosen to detach it, you can change that as you want. And yeah, that's a createWindow function. And then when the app is ready, when it's fully started up, we go ahead and create the window. And we have very similar to what we saw previously.

And that is my main process file, and we will add to it. Trust me, we will add to it in our time together. But that is the initial kind of like first version. A pattern that you'll see a lot too, though, is, as you can imagine, there is a period of time between opening a window, loading up the HTML and all the CSS and stuff along those lines as well.

Which could theoretically give you the flash of white content or what have you. So there are ways around that, and let's kinda just talk about that. Cuz it gives you a sense of a little bit more of the kind of model here as well. So for instance, we could theoretically choose to, if we say show:false, that will not show the window by default, right?

And we could at that point say something along the lines of, You've got this main window ready to show. And this is like, now, okay, we've got a DOM, we've got everything kinda loaded up. That's when we could theoretically choose to show it. Now, it depends like on what you're doing in this case, but I think it's a pretty solid practice in this case.

And so the same way show was false, we can call this a method here, which is to show it. And then you could also choose, for instance, to focus it as well, right? So load everything up while it's hidden, and then go ahead when it's ready to show it, so on and so forth.

But we don't have a really great use case for it, right? But I do wanna kinda point out that the ability to start up renderer processes and not show them does at least open up some interesting possibilities, right? Cuz we said before, renderer processes are Chromium, they've got GPU acceleration support.

You can theoretically spin up threads that don't necessarily show a window, but could theoretically be doing image processing or something along those lines. You could have one that has maybe a canvas that is resizing or doing stuff to images, and then message back and forth with that. All those things become very involved.

But the ability to spin up processes and not show them, and not necessarily do the child process dance in Node. And have all of the Web APIs available and stuff along those lines is a relatively powerful concept as well. And to point that out as well, in any given browser context, you again have all the Web APIs.

So all the service worker stuff, all the shared workers, all the web workers, right? All of those things are available and accessible to you in your application as well. A lot of those are very niche use cases, if you need those things above and beyond the standard kind of pieces.

Cuz we already have multiple processes here, we've got the main process, we've got the renderer processes. We're gonna do everything asynchronous. So we are taking advantage of a lot of things that make JavaScript fast and snappy to begin with. But should you have a very specific use case, there is a lot of power and flexibility here in what you can do.

So let's go ahead. One of the things is that, yes, we have Vite for our client-side processes. But could you play with Nodemon or something along those lines to regenerate the app every time? I'm choosing not to for the name of simplicity. But in this case, now we do still show it, but we wait for the DOM to load before we see anything.

That's a little tweak there that I think, generally speaking, I tend to use a lot, which is this once. A lot of these things extend from Node.js Event Emitter, right? And so we're saying one time when the window is ready to show, all right, actually go and show it, and stuff along those lines.

And like I said, if you don't want the Developer Tools opening, you can totally just get rid of this. Cuz they are always accessible to you by default in the actual View menu as well. So I will leave that to you whether you want it or not. At various times I will turn it off and turn it on depending on what kind of point that I'm trying to make.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now