Creating Angular Desktop Apps with Electron

Creating a new Angular project

Following this tutorial, you can use any existing angular app you want and it should work out just fine.

For this tutorial, we are going to create a new angular project from scratch using the angular-cli.

To create a new project, install the angular-cli if you haven’t done so already

 npm install -g @angular/cli

Next, create a new project using the following command:

 ng new angular-electron

angular-electron will be the name of our project. This will become important later.

Adding electron to the project

Afterward, we need to install electron itself.

To do that, we switch to the projects root directory and add it to the project as dev-dependency like so:

 npm i -D electron

Why is it just a dev-dependency?

Because we don’t want it to be included in our app itself. We only need it at build-time to build the desktop app.

Installing types

Because we will be using TypeScript for our angular application as well as in our electron-files, we need to add the corresponding type definitions to our project.

We can do so using npm again:

 npm i -D @types/electron

Because types are irrelevant for the running application, we add it as dev-dependency, as well.

Fire up the application

Now it’s time to fill the main.ts with some code.

First, we import the required dependencies:

import { app, BrowserWindow } from 'electron'
import * as path from 'path'
import * as url from 'url'

Afterward, we create a variable that will hold a reference to the browser window. This is the window electron spawns to host our angular application.

let win: BrowserWindow

Next, we register some listeners on the app object we imported above. These listeners will let us know when the application is ready to go.

app.on('ready', createWindow)
 
app.on('activate', () => {
  if (win === null) {
    createWindow()
  }
})

The second listener for the “activate”-event is only required for macOS applications, as these behave a little bit differently.

The application window

Now we need to implement the createWindow function we called before.

This function will create a new electron window to host our angular application. In the background, this window is just a chrome-tab. This is why the class to create a new window is called BrowserWindow.

function createWindow() {
  win = new BrowserWindow({ width: 800, height: 600 })
}

Inside of the BrowserWindow constructor, we define the dimensions of the new window. You can also start the application in fullscreen-mode like this:

function createWindow() {
  win = new BrowserWindow({ fullscreen: true })
}

Spawning the angular application in electron

Next, we need to fill our new browser window with content: Our angular app.

To do that the browser window provides a method called loadUrl.

We use this method to load the index.html of our (already build) angular application. The build output (when we call ng build) typically is located in a directory called dist in the project root.

Since angular 6 there is an additional sub-folder called like the project itself. In this case, it is “angular-electron”.

function createWindow() {
  win = new BrowserWindow({ width: 800, height: 600 })
 
  win.loadURL(
    url.format({
      pathname: path.join(__dirname, `/../../dist/angular-electron/index.html`),
      protocol: 'file:',
      slashes: true,
    }),
  )
 
  win.webContents.openDevTools()
 
  win.on('closed', () => {
    win = null
  })
}

We also add a function call to open the chrome dev-tools at the start. It’s up to you if you want that and you definitely want to remove that when you ship the application.

Also, we added an event listener to the window close event. Again, this is a special case required for macOS applications.

How electron works

Electron consists of two parts.

The first part is the main process which is a node.js application. This is the core of any electron program.

The code we defined in our main.ts file is running on the main process.

Because the main.ts is running in node, we can make calls to the node.js API here.

This main process is then spawning the second one by opening the browser window, which is the second part of the app and runs our angular application.

This process is (almost) a regular chrome window and the JavaScript code running in that window has the same access as any other application running in a browser.

We can’t access the node.js API from here. Especially we do not have access to the file system.

Inter-process Communication (IPC)

But if we cant use the node.js API in our angular application, how do we get access to the file system?

The answer is called inter-process communication. It is a method the operating system provides so that two different processes can communicate with each other.

In our case, the main process has to communicate with the browser process and vice versa.

Using electron IPC

Now, IPC sounds highly technical and complicated and it really is.

Luckily, electron provides a convenient way of implementing this using simple JavaScript methods.

There are two different parts we will use for this. One for the main process and on for our angular application.

Setting up IPC in the main process

The first part is the one for the main process and called ipcMain.

To use it, we import it at the beginning of our main.ts file.

import { app, BrowserWindow, ipcMain } from 'electron'

In this example, we want to listen to messages from the browser window. To do that we use ipcMain to notify us when a new message arrived.

Because we are not interested in every message, we also specify a so-called channel. Basically, channels are a way to organize messages by topic.

In our case, we listen to messages on a channel called “getFiles”.

ipcMain.on('getFiles', (event, arg) => {})

We are following an idea called remote procedure calls (RPC) here by calling the channel like a function we later “call” remotely from our angular application.

Inside of the callback, we then get the required information using the node.js API and send back the response on a different channel called “getFilesResponse”.

ipcMain.on('getFiles', (event, arg) => {
  const files = fs.readdirSync(__dirname)
  win.webContents.send('getFilesResponse', files)
})

That’s already it for the main process. Now we have to call our remote function from our angular application.

A simple workaround

The solution is a method called require that electron injects into the window object at runtime. With that, we can import the required object.

And because we can check that require-method for null (as it does not exist in the browser window) we are still compatible with the web.

import { Injectable } from '@angular/core'
import { IpcRenderer } from 'electron'
 
@Injectable({
  providedIn: 'root',
})
export class FileService {
  private ipc: IpcRenderer
 
  constructor() {
    if ((<any>window).require) {
      try {
        this.ipc = (<any>window).require('electron').ipcRenderer
      } catch (error) {
        throw error
      }
    } else {
      console.warn('Could not load electron ipc')
    }
  }
}

You might notice that we are importing IpcRenderer at the top. That is just the type and does not contain the actual logic.

The getFiles method

Now that we have our ipc-object, we can start communicating with our main process.

We do so by creating a method called getFiles that handles all the IPC communication for us and gives back the result.

 async getFiles() {
    return new Promise<string[]>((resolve, reject) => {
      this.ipc.once("getFilesResponse", (event, arg) => {
        resolve(arg);
      });
      this.ipc.send("getFiles");
    });
  }
 

Again, we are defining a listener that is listening on the “getFilesResponse” channel. Because we do so by using the “once” method, it will unsubscribe itself after the first message.

Only after that, we send a request message on the channel “getFiles” to our main process.

Please be aware that this is a small example that should not be used in production as it can result in the application waiting forever if the main process does not respond. A production-ready function would need some type of timeout.

Also, you would probably give every request an id, to identify which request got what answer.

Finally, you can use that service now anywhere in your application just like a normal service.