List of Figures

Chapter 1. Introducing Electron

Figure 1.1. LevelUI is a GUI for Node’s LevelUp database built with Electron. You couldn’t build this application in a traditional browser because it wouldn’t have the ability to access a local database on the user’s computer. It also couldn’t use the LevelUI library because it’s a compiled C++ module, which only Node—and not the browser— can use.

Figure 1.2. Electron combines the core web browsing component of Chromium with the low-level system access of Node.

Figure 1.3. Brave is an entire web browser built on top of Electron.

Figure 1.4. In a browser-based web application, it might not be practical to rely on the Fetch API, given its inconsistent support. But in your Electron applications, you’re bundling the current stable build of Chromium with full support for the Fetch API.

Figure 1.5. Electron allows you to create custom application menus.

Figure 1.6. You can create an application that lives in the operating system’s menu bar or system tray.

Figure 1.7. Electron applications can use their Node.js runtimes to make requests to third-party APIs.

Figure 1.8. Electron’s multiprocess architecture

Chapter 2. Your first Electron application

Figure 2.1. A wireframe of the application we build in this chapter

Figure 2.2. The file tree structure for our first Electron application

Figure 2.3. npm init provides a series of prompts and sets up a package.json file

Figure 2.4. The application in the dock isn’t just any Electron application; it’s the Electron application we just set up.

Figure 2.5. An empty BrowserWindow without an HTML document loaded

Figure 2.6. A BrowserWindow with a simple HTML document loaded

Figure 2.7. The BrowserWindow executing JavaScript from the context of the renderer process.

Figure 2.8. The complete Bookmarker application

Chapter 3. Building a notes application

Figure 3.1. A wireframe of our application shows that the user can enter text in the left pane or load it from a file from the user’s filesystem.

Figure 3.2. The structure of our project

Figure 3.3. Electron starts by looking for our single main process, which is in charge of spawning one or more renderer processes in charge of displaying our UI.

Figure 3.4. The main process will create a renderer process and tell it load index.html, which will then load CSS and JavaScript just as it would in the browser.

Figure 3.5. The unstyled beginnings our first Electron application

Figure 3.6. Our application has been given some basic styling using modern features of CSS.

Figure 3.7. We’ll add an event listener to the left pane that will render the Markdown as HTML and display it in the right pane.

Figure 3.8. Our application takes the content typed by the user in the left pane and automatically renders it as HTML in the right pane. This content was provided by the user and is not part of our application.

Figure 3.9. The Chrome Developer Tools are available in the renderer process just as they would be in a browser-based application.

Figure 3.10. The tools can be toggled on and off in the default menu provided by Electron. You can also toggle them using Control-Shift-I on Windows or Command-Option-I on macOS.

Figure 3.11. Triggering the build task without one in place will prompt Visual Studio Code to create one on your behalf.

Figure 3.12. Inside the Debug tab, click on the gear and Visual Studio Code will create a configuration file for launching the debugger on your behalf.

Figure 3.13. The debugger built in to Visual Studio Code allows you to pause the execution of your application and drop in to investigate bugs.

Chapter 4. Using native file dialog boxes and facilitating interprocess communication

Figure 4.1. Our application will trigger the Open File dialog box when it starts. By the end of the chapter, this functionality will be replaced by the ability to trigger the dialog box from the UI.

Figure 4.2. Electron is able to trigger native file dialog boxes in each of its supported operating systems.

Figure 4.3. Upon selecting a file, the full path of the file is logged to the console in our terminal window.

Figure 4.4. The contents of the file are logged to the user’s terminal.

Figure 4.5. If the user selects a nontext file, the function logs the binary data.

Figure 4.6. In Windows, we can switch between different types of files.

Figure 4.7. macOS does not support switching between types of files but does allow us to select any file that is eligible as defined by the filters option.

Figure 4.8. Instead of appearing as an additional window in front of our application’s window, the Open File dialog box now drops down from the menu’s title bar in macOS.

Figure 4.9. The division of responsibilities in Electron applications versus traditional web applications.

Figure 4.10. Electron provides different modules to the main and renderer processes. These modules represent the code capabilities of Electron. This list is likely to grow and may be incomplete by the time you read this. I encourage you to visit the documentation to see the latest and greatest features.

Figure 4.11. Implementing the Open File button involves coordinating communication between the renderer process and the main process.

Figure 4.12. The remote module shares many of the same properties as the Electron module in the main process.

Figure 4.13. The remote module provides access to modules normally available only to the main process.

Figure 4.14. BrowserWindow instances have methods that are aliases to Electron’s webContents API.

Chapter 5. Working with multiple windows

Figure 5.1. In chapter 4, we set up communication between the main process and one renderer process.

Figure 5.2. In this chapter, we update Fire Sale to support multiple windows and facilitate communication between them.

Figure 5.3. To figure out to which window to send the file’s content, the renderer process must send a reference to itself when communicating to the main process to call getFileFromUser().

Figure 5.4. New windows are offset from the current window.

Chapter 6. Working with files

Figure 6.1. Users expect to interact with files in several ways. In this chapter, we implement all the necessary features to meet our users’ expectations.

Figure 6.2. The name of file in the filesystem is displayed in the window’s title.

Figure 6.3. The Fire Sale UI when the file has not been modified. Notice that the Save File and Revert buttons have been disabled.

Figure 6.4. The Fire Sale UI when the file has been modified. Notice that the title bar content has (Edited) appended to it and the Save File and Revert buttons are no longer disabled.

Figure 6.5. Pressing and holding Command while clicking the file icon in the title bar allows us to see its location on the filesystem. We can also drag and drop the icon as if it were the file itself.

Figure 6.6. Recent files in macOS

Figure 6.7. Recent files in Windows 10

Figure 6.8. System-wide recent documents in macOS

Figure 6.9. Fire Sale allows users to save their Markdown content in the left pane as well as the rendered HTML output shown in the right pane.

Figure 6.10. Adding a CSS class to the Markdown view provides a visual cue to the user that this is a valid place to drop this file.

Figure 6.11. In the same vein, Fire Sale does not support images. The code we’re about to write will reject any file that is not one of our supported types, but visually showing the user that the file won’t be accepted allows them to cancel their action in advance.

Chapter 7. Building application and context menus

Figure 7.1. In this chapter, we build custom menu items that trigger some of the functionality found in the UI.

Figure 7.2. The structure of the application menu for Fire Sale

Figure 7.3. macOS takes the first menu item and uses it as the Application menu, which is not always the expected or intended behavior.

Figure 7.4. By shifting all of the menus down one position, the Edit menu renders correctly. Soon, we implement an Application menu that behaves like a native macOS application.

Figure 7.5. The Edit and Window menus as implemented in Electron’s builtin menu

Figure 7.6. The structure of the application menu in macOS applications

Figure 7.7. Menu items in the application menu use special roles in Electron that allow you to trigger operating system functionality without reinventing the wheel.

Figure 7.8. The Window menu in macOS allows you to see all of the windows currently open in the application.

Figure 7.9. On macOS, the Help menu allows you to search for items in your menu.

Figure 7.10. The structure of the Help menu that we build in listing 7.8.

Figure 7.11. In this section, we will add a File menu with application-specific functionality.

Figure 7.12. Electron allows developers to define custom context menus when the user right-clicks on a specific part of the DOM.

Chapter 8. Further operating system integration and dynamically enabling menu items

Figure 8.1. Electron allows us to integrate with the operating system to trigger the file browser to navigate to the location of a given file or to open a file path in the default application for that file type.

Figure 8.2. The Show File and the Open in Default Application buttons have been present since chapter 3. In this chapter, we’ll use the Electron shell module to implement their functionality.

Figure 8.3. Menu items that work with the Electron shell module to communicate with the native operating system

Figure 8.4. Accessing the shell module from context menus. Show File in Folder and Open in Default Editor are disabled when working on a new, unsaved file because unsaved files do not have a valid file path for the shell module’s methods.

Figure 8.5. Certain menu items are either enabled or disabled depending on the state of the application. In this application, we have two menus: application and context. The application menu must track all the open windows, whereas the context menu should deal with only a subset of the same concerns because it can assume that at least one window is open.

Figure 8.6. Show File in Folder and Open in Default is disabled if there is no file open.

Figure 8.7. If there are no windows open, Save File, Export HTML, Show File, and Open in Default Application should be disabled.

Figure 8.8. If there is a focused window, but the user is working on a file that has not yet been saved to the filesystem, then the Save File and Export HTML items should be enabled. The Show File and Open in Default Application menu items should not be, however, because there is no file location to show or open.

Figure 8.9. If the window is representing a file on the filesystem, all the menu items should be enabled.

Chapter 9. Introducing the tray module

Figure 9.1. This is what the application looks like when completed. macOS is on the top, and Windows is on the bottom.

Figure 9.2. In the first iteration, Clipmaster is nothing more than a small application that allows the user to immediately quit it. Don’t worry: there is more functionality to come, and you’ll have a fully functional application by the end of the chapter.

Figure 9.3. When the user hovers over the icon, they see the tooltip. This can be customized and changed based on the state of the application.

Figure 9.4. If the macOS menu bar is in dark mode, we’ll use the inverted icon.

Figure 9.5. The application with its two basic commands on macOS

Figure 9.6. In addition to being able to quit the application, users need a way to add a clipping to the application. Here the application is shown in the Windows tray.

Figure 9.7. When clippings are added to the array, the menu is updated with a new menu item with the clipping’s content as the label.

Figure 9.8. The application now has keyboard shortcuts.

Figure 9.9. The operating system will eventually truncate long menu item labels, but even this is a bit unwieldy.

Figure 9.10. Clipping menu item labels are now capped at 20 characters. You can adjust this to your liking, or create a setting to allow users to control the length.

Figure 9.11. On Windows, the menu appears beneath the cursor when triggered with the global shortcut.

Figure 9.12. A notification in Windows 10

Figure 9.13. A notification in macOS

Figure 9.14. macOS can use an alternate icon when the menu bar application is clicked. In this example, we used an inverted version of the icon to match the rest of the menu bar icons.

Chapter 10. Building applications with the menubar library

Figure 10.1. This is what the application will look like at the end of the chapter.

Figure 10.2. By default, menubar creates a browser window but does not load an HTML document into it.

Figure 10.3. The basic UI for Clipmaster 9000 is in place.

Figure 10.4. A published clipping on the ClipHub service

Figure 10.5. If you try to use one of your global shortcuts before the window is opened for the first time, you see this error.

Chapter 11. Using transpilers and frameworks

Figure 11.1. In this chapter, we build an application to track what we need to pack for an upcoming trip.

Figure 11.2. electron-compile supports a wide variety of languages.

Figure 11.3. The foundation of our application using React, Sass, and Jade.

Figure 11.4. Jetsetter is broken into small components as illustrated here.

Figure 11.5. The Application component without items

Figure 11.6. The application now includes lists of packed and unpacked items.

Figure 11.7. The application can now add a new item in addition to “Pants.”

Chapter 13. Testing applications with Spectron

Figure 13.1. A simplified version of Clipmaster 9000 that does not live in the menu bar.

Figure 13.2. Spectron is a wrapper around WebdriverIO, which—in turn—is a wrapper around Selenium WebDriver.

Figure 13.3. The Spectron API

Figure 13.4. Spectron adds a number of utility methods to the WebdriverIO API. This is an exploded view of the client in figure 13.3.

Chapter 14. Building applications for deployment

Figure 14.1. By default Electron Packager places builds inside the project’s root. This can be problematic because we typically do not want to commit our built application into source control.

Figure 14.2. With the productName set, our application has the correct name after it is built.

Figure 14.3. Hey, look! We have a custom icon now!

Figure 14.4. The application’s source code is located within the application itself.

Figure 14.5. The application wrapped in an asar archive.

Figure 14.6. Packaging an application with Electron Forge

Chapter 15. Releasing and updating applications

Figure 15.1. The console message verifies that the code inside crash-reporter.js has executed.

Figure 15.2. Verify that the crash reporter code has been executed by checking the console.

Figure 15.3. Triggering a crash in the render process requires a reload of the UI.

Figure 15.4. Electron attempts to send the crash report but cannot find the server.

Figure 15.5. Select Preferences from the Application menu.

Figure 15.6. Select your team from the Accounts tab, and click Manage Certificates.

Figure 15.7. Select Developer ID Application and Developer ID Installer from the drop-down menu.

Figure 15.8. macOS’s codesign utility accesses your keychain to use the certificates you generated to sign the application.

Figure 15.9. Fire Sale automatically notifies users when a new version is available on the server.

Chapter 16. Distributing your application through the Mac App Store

Figure 16.1. Request a certificate using Keychain Access.

Figure 16.2. Enter information for your application signing certificate request.

Figure 16.3. Select macOS as the target platform.

Figure 16.4. Add the certificate request you generated earlier.

Figure 16.5. Select Mac App Store as the type of certificate that you’re requesting.

Figure 16.6. Generate certificates for the application and installer.

Figure 16.7. Upload the certificate signing request file you created earlier.

Figure 16.8. Download your completed certificate.

Figure 16.9. The application and installer certificates listed in Keychain Access.

Figure 16.10. Register your App ID.

Figure 16.11. Select My Apps in iTunes Connect.

Figure 16.12. Add a new Mac application in iTunes Connect.

Figure 16.13. Provide details about the application in iTunes Connect.

Figure 16.14. Fire Sale is now registered with macOS as an application that can open Markdown files.

Figure 16.15. Use the Application Loader to upload your Electron application to the Mac App Store.

Figure 16.16. In this case, we’re uploading a full application to the Mac App Store.

Figure 16.17. Verify that the application’s metadata is correct.