So here I was inspired to work with Electron and everything was just fine until I start stumbling dozens over dozens of different ways to organize your code. I can write many articles about this, but in this one.
This one is short and it’s about the two major concepts you must understand when working with Electron: The Main process and The Renderer process. Electron has a decent documentation, but doesn’t give much of the whys.
Their names are not very intuitive to what they are, but are basically:
- Main: The shell that has access to your OS, and:
- Renderer: The HTML based app that gets rendered inside the Shell.
Runs purely in NodeJS, in whatever ECMAScript version Node supports at the time you read this article, let’s say, ECMA6.
This process interfaces directly with the Operating System you are running your app. So every call to the Electron API, or Node API that in turn, can access directly your files, network, registry and pretty much everything other desktop apps can in other languages are made here.
Electron presents itself, in its default setup, as a windowed frame, with a default menu and the window buttons to close the application, minimize or expand. Inside this frame, it puts a Chromium web browser to enable you, the developer, to render anything you would render in a browser, which takes us to the next section.
Architecturaly nested inside the Main Process, the Renderer Process is everything that runs inside this Chromium instance, in this case, your Angular app, your or React, Vue, plain HTML, doesn’t matter.
Because you can literally point that Chromium instance to open a remote URL online, it can get exposed to all the dangers of the internet, no different than a browser. That’s why the Renderer Process is sandboxed by the Main Process, and you cannot access any OS native API, either Electron or Node directly from the Renderer Process.
It would be tragic if you redirect your Chromium to a place that got hacked, and the hacker probe for Electron plugs in your Chromium and start wiping out all your hard drive. Bad.
How Main and Renderer communicate
They work exactly like a Subscriber/Observer pattern. You define the topics, which are just strings, and Subscribe or Emit them with values.
ipcRenderer sends messages, ipcMain gets it – and you can also get replies.
Important: If you want ipcMain to send messages to the Renderer process, use the command
Tips on that
Think those two processes are completely different worlds. Code your Renderer app like you would code without Electron, and build up those calls yourself, define your own API contract.
Same way goes for the Main process. Pretend you are a web server who just respond to calls to that API. This is the best way to keep your app decoupled, and therefore, more secure.
If you want a solid boilerplate code to start your Electron app, there is this one if your Renderer would be coded in React: github.com/electron-react-boilerplate/elect..
If you found that one too big, you can start with this smaller one: github.com/diego3g/electron-typescript-react
A nice in-depth article about developing in Electron: getstream.io/blog/takeaways-on-building-a-r..
Did you find this article valuable?
Support Dorival Neto by becoming a sponsor. Any amount is appreciated!