Learning Electron: 4 Things I Wish I Knew Sooner
Learning Electron: 4 Things I Wish I Knew Sooner
Although the community surrounding Electron makes it easy to get started, there are a lot of mistakes people frequently make and things people misunderstand that chew up a lot of their time. So, here are a few tips to make your experience faster and easier.
Join the DZone community and get the full member experience.Join For Free
Jumpstart your Angular applications with Indigo.Design, a unified platform for visual design, UX prototyping, code generation, and app development.
Electron is a fun stack to work with. If you’re familiar with Node or with building front ends in the browser, Electron makes it easy to build desktop apps.
Although the community surrounding Electron makes it easy to get started, there are a lot of mistakes people frequently make and things people misunderstand that chew up a lot of their time.
For the sake of brevity here, I’ll assume that you’ve gone/will go through the Electron getting started docs.
4 Things I've Learned That Might Help You.
1. Keep Your Code Separated
window object, your application will not fare so well.
"I’ll just be careful," you might say... developers are, after all, masters of hubris above all else. It’s well worth it to spend 20 minutes up front avoiding hours of refactoring later. I generally find it worthwhile to separate code into a few folders: one for the main process, one for each type of window, and one for shared code that should get run across all types of processes.
It looks like this:
Background: a hidden window (more on these later)
Main: main process
Renderer: the window the user will interact with
Shared: code that gets loaded for both the main process and all windows
2. Accommodate for Native Modules
The prevalent workflow for this is to install normally, and then run a Grunt task or similar script to compile your modules again to work with Electron. My best guess is that people prefer compiling twice so that they have more time for swordfighting. However, while I enjoy swordfighting, I also have entirely too much to get done, so I prefer to only compile code once.
To add to it, while most modules will compile in 30 seconds or so, some larger modules like NodeGit can take nearly 10 minutes to compile, so compiling twice is a brutal time waster. Mentioned very briefly in the Electron docs is an alternative, which is the way I prefer to do things. Code is only compiled once, plus this way we can take advantage of modules that provide pre-compiled binaries. Using a file called a ".npmrc" in the root of our project, we can get npm to compile/download everything correctly from the get go.
Below, you'll see a .npmrc setup for using Electron 0.36.5.
The other thing to pay attention to here is that native modules compiled for Electron won’t necessarily work normally in Node. so If you have a Grunt build process or anything of the sort which uses some native modules, they’ll need to be kept separately.
What I do (and what they do in Atom) is to separate out modules into two areas to distinguish between those used in the application, and any modules used in the build but outside of the actual application. I keep those used in the application (including actual dependencies, and dev dependencies like test frameworks that run inside of the application) in the root of my project, and a build folder with its own package.json file for those modules used outside the application:
3. Don’t Block the UI Thread OR the Main Thread
Node is single threaded. While Electron runs multiple processes, each one is still single threaded. So, if you run a long running synchronous task in your window, the user isn’t going to be able to interact with your application for the duration of its task. Unless you’re out to spite the end user, this is generally regarded as "bad."
The common first attempt at getting around this that new-to-Electron developers make is to move things to the main process, but this is still "bad." Lots of small actions (like quitting the app, resizing the window, etc.) happen in the main process, so now, while your buttons are still clickable, the app can’t resize, or exit, or any number of other related things which make the app seem frozen and broken to the end user.
In the browser, people generally get around this by using Web Workers, but rather than spend time implementing that, the Electron team decided to make it even easier. To perform processes that don’t block the main process or renderer process, all you have to do is open another window that isn’t visible to the user.
This invisible window will open up the other process behind the scenes. Despite being invisible to the user, it can communicate with the main process (and other windows) using Electron’s IPC module just like a normal viewable window.
4. Use Old School for Web Requests
If your app needs to do any communication over the Web (perhaps to an API server or such), it’s logical to use the built-in node http/https modules, or the popular "request" module. However, none of these accommodate for system-configured proxies.
Chromium, however, does account for this, and fortunately, it’s super easy to tap into that, just by using the Old-School browser XMLHttpRequest object. By using XMLHttpRequest, it’s all handled automatically, and you don’t have to do any extra work or make the user configure anything in your application.
Take Advantage of My Suffering
I hope you’ll take a real stab at using Electron. I spent plenty of my supposed vacation time on the beach still working, but maybe these tips mean that next time you go on vacation you can actually do some vacationing.
Published at DZone with permission of Max Korp . See the original article here.
Opinions expressed by DZone contributors are their own.