introduction

107 notes in this subject, read out of this brain and free to use. This is page 2 of 2.

Renderer process code should follow web standards

Code run in renderer processes should behave according to web standards insofar as Chromium does. All user interfaces and app functionality within a single browser window should be written with the same tools and paradigms used on the web.

Renderer process web content entry point is HTML file

An HTML file is the entry point for the renderer process. UI styling is added through Cascading Style Sheets (CSS). Executable JavaScript code is added through script elements.

Renderer process has no direct access to require or Node.js APIs

The renderer process has no direct access to require or other Node.js APIs. To include NPM modules in the renderer, you must use the same bundler toolchains used on the web, such as webpack or parcel.

Utility process spawned from main process using UtilityProcess API

Each Electron app can spawn multiple child processes from the main process using the UtilityProcess API. The utility process runs in a Node.js environment, meaning it has the ability to require modules and use all of Node.js APIs.

Utility process use cases: untrusted services, CPU tasks, crash-prone components

The utility process can be used to host untrusted services, CPU intensive tasks, or crash-prone components which would have previously been hosted in the main process or in child processes spawned with Node.js child_process.fork API.

Utility process can communicate with renderer via MessagePort

The primary difference between the utility process and processes spawned by the Node.js child_process module is that the utility process can establish a communication channel with a renderer process using MessagePorts. An Electron app should prefer the UtilityProcess API over Node.js child_process.fork API when forking a child process from the main process.

TypeScript type definition subpaths for process types

Electron's npm package exports subpaths containing process-specific TypeScript type definitions: electron/main includes types for all main process modules, electron/renderer includes types for all renderer process modules, and electron/common includes types for modules that can run in main and renderer processes.

Spellchecker support by Electron version

Electron has built-in support for Chromium's spellchecker since Electron 8. On Windows and Linux this is powered by Hunspell dictionaries, and on macOS it makes use of the native spellchecker APIs. For Electron 9 and higher the spellchecker is enabled by default. For Electron 8 you need to enable it explicitly in webPreferences.

Set spellchecker languages on Windows and Linux

On Windows and Linux, use myWindow.webContents.session.setSpellCheckerLanguages(['en-US', 'fr']) to set the languages for the spellchecker. By default the spellchecker will enable the language matching the current OS locale. You can get an array of all available language codes with myWindow.webContents.session.availableSpellCheckerLanguages.

Spellchecker language setting on macOS

On macOS, there is no way to set the language that the spellchecker uses because the native APIs are used. By default on macOS the native spellchecker will automatically detect the language being used.

Add spellchecker suggestions to context menu

All required information to generate a context menu is provided in the 'context-menu' event on each webContents instance. The event provides params.dictionarySuggestions array containing spelling suggestions and params.misspelledWord containing the misspelled word. Use myWindow.webContents.replaceMisspelling(suggestion) to replace a misspelled word and myWindow.webContents.session.addWordToSpellCheckerDictionary(word) to add a word to the dictionary.

Spellchecker dictionary download source

The spellchecker itself does not send any typings, words or user input to Google services. However, the hunspell dictionary files are downloaded from a Google CDN by default. To avoid this, provide an alternative URL with myWindow.webContents.session.setSpellCheckerDictionaryDownloadURL('https://example.com/dictionaries/').

Context menu with spelling suggestions example

const { Menu, MenuItem } = require('electron') myWindow.webContents.on('context-menu', (event, params) => { const menu = new Menu() // Add each spelling suggestion for (const suggestion of params.dictionarySuggestions) { menu.append(new MenuItem({ label: suggestion, click: () => myWindow.webContents.replaceMisspelling(suggestion) })) } // Allow users to add the misspelled word to the dictionary if (params.misspelledWord) { menu.append( new MenuItem({ label: 'Add to dictionary', click: () => myWindow.webContents.session.addWordToSpellCheckerDictionary(params.misspelledWord) }) ) } menu.popup() })

Enable spellchecker in Electron 8

To enable the spellchecker in Electron 8, set the spellcheck property to true in the webPreferences object when creating a BrowserWindow.

Electron does not use system Node.js installation

Electron comes bundled with its own Node.js runtime and does not use your system's Node.js installation to run its code. This means that end users do not need to install Node.js themselves as a prerequisite to running an Electron application. The version of Node.js running in an app can be checked by accessing the global process.versions variable in the main process or preload script, or by referencing https://releases.electronjs.org/releases.json.

Electron embeds Chromium and Node.js

Electron is a framework for building desktop applications using JavaScript, HTML, and CSS. By embedding Chromium and Node.js into a single binary file, Electron allows you to create cross-platform applications that work on Windows, macOS, and Linux with a single JavaScript codebase.

Prerequisites for Electron development

To develop an Electron application, you need the following tools: a text editor (Visual Studio Code is recommended), a command-line interface (Command Prompt or PowerShell for Windows, Terminal for macOS, or varies by distribution for Linux), Node.js runtime with npm package manager (LTS version recommended), and Git with a GitHub account (required for setting up automatic updates later in the tutorial).

Node.js installation recommendations for macOS

For macOS development, it is recommended to install Node.js using a package manager like Homebrew or nvm rather than pre-built installers, to avoid directory permission issues.

Tutorial structure for Electron apps

The Electron tutorial is structured in six parts: (1) Prerequisites, (2) Building your First App, (3) Using Preload Scripts, (4) Adding Features, (5) Packaging Your Application, and (6) Publishing and Updating.

Electron Forge create-electron-app boilerplate

Electron Forge provides a create-electron-app command for quickly starting a project with a single-command boilerplate, as an alternative to building a minimal Electron application from scratch.

Use process.platform to run code conditionally by OS

Check Node's process.platform variable to run code conditionally on specific platforms. Electron supports three platforms: 'win32' (Windows), 'linux' (Linux), and 'darwin' (macOS).

Electron entry point is main.js specified in package.json

The 'main' property in package.json specifies the entry point for an Electron application. This script controls the main process, which runs in a Node.js environment and is responsible for controlling the app's lifecycle, displaying native interfaces, performing privileged operations, and managing renderer processes.

Avoid Windows Subsystem for Linux when developing Electron apps

Do not use Windows Subsystem for Linux (WSL) when developing Electron apps on Windows machines, as it causes issues when trying to execute the application.

Electron module capitalization convention

Electron follows JavaScript conventions where PascalCase modules are instantiable class constructors (e.g. BrowserWindow, Tray, Notification) while camelCase modules are not instantiable (e.g. app, ipcRenderer, webContents).

app.whenReady() is preferred over app.on('ready')

Use app.whenReady() as a helper for the 'ready' event instead of directly listening with app.on('ready') to avoid subtle pitfalls specific to that event.

Renderer processes run separate from main process

Each web page displayed in a window runs in a separate process called a renderer process. Renderer processes have access to the same JavaScript APIs and tooling as typical front-end web development, such as webpack and React.

Process responsibilities and access differences

Electron's main and renderer processes have distinct responsibilities and are not interchangeable. The main process has full operating system access and can use Node.js APIs. The renderer process runs web pages and does not run Node.js by default for security reasons. It is not possible to access Node.js APIs directly from the renderer process, nor the HTML DOM from the main process.

Electron capabilities for desktop integration

Electron provides tools for integrating with the desktop environment, including creating tray icons, adding global shortcuts, and displaying native menus. It also provides access to the full power of a Node.js environment in the main process.

Two directions for Electron app development

There are two broad directions for developing an Electron application: adding complexity to the renderer process's web app code, and deeper integrations with the operating system and Node.js. Building UI complexity in Electron uses standard web tools (HTML, CSS, JavaScript) and does not require Electron-specific resources. Operating system integrations and use of the Node.js environment in the main process are what separate Electron applications from running a website in a browser tab.

Three options for embedding web content in Electron

To embed third-party web content in an Electron BrowserWindow, three options are available: iframe tags, webview tags, and WebContentsView. Each offers different functionality and is useful in different situations.

Iframe behavior in Electron

Iframes in Electron behave like iframes in regular browsers. An iframe element in your page can show external web pages, provided that their Content Security Policy allows it. To limit the capabilities of a site in an iframe tag, it is recommended to use the sandbox attribute and only allow the capabilities you want to support.

WebView is not recommended

WebViews are not recommended for use because this tag undergoes dramatic architectural changes that may affect stability of your application. You should consider switching to alternatives like iframe and Electron's WebContentsView, or an architecture that avoids embedded content by design.

WebView is not officially supported by Electron

WebViews are based on Chromium's WebViews and are not explicitly supported by Electron. Electron does not guarantee that the WebView API will remain available in future versions of Electron.

Enable webview tag in BrowserWindow

To use webview tags, you must set webviewTag to true in the webPreferences of your BrowserWindow.

WebView is implemented as out-of-process iframe

WebView is a custom element that only works inside Electron. It is implemented as an out-of-process iframe, which means that all communication with the webview is done asynchronously using IPC. The webview element has many custom methods and events, similar to webContents, that provide greater control over the content.

WebContentsView is not part of the DOM

WebContentsView objects are not a part of the DOM. Instead, they are created, controlled, positioned, and sized by your Main process. Using WebContentsView, you can combine and layer many pages together in the same BaseWindow.

WebContentsView control and implementation

WebContentsView objects offer the greatest control over their contents, since they implement webContents similarly to how BrowserWindow does it. However, as WebContentsView objects are not elements inside the DOM, positioning them accurately with respect to DOM content requires coordination between the Main and Renderer processes.

Electron project root structure with src folder

Electron's project contains a single `src` folder that corresponds to a specific git checkout of Chromium's `src` folder. Electron's repository code is contained in `src/electron` (with its own nested git repository), and Electron-specific third-party dependencies like nan and node are located in `src/third_party` along with all other Chromium third-party dependencies such as WebRTC or ANGLE.

Electron source code build directory structure

The Electron source code is organized in the following top-level directories: build/ (build configuration files for GN), buildflags/ (feature flags), chromium_src/ (code copied from Chromium), default_app/ (default app when Electron starts without a consumer app), docs/ (documentation), lib/ (JavaScript/TypeScript source code), patches/ (patches for upstream dependencies), shell/ (C++ source code), spec/ (test suite components), typings/ (internal TypeScript types), and BUILD.gn (building rules).

Electron lib/ directory structure for different processes

The lib/ directory contains JavaScript/TypeScript source code organized by process type: browser/ (main process initialization and APIs), common/ (logic for both main and renderer processes), isolated_renderer/ (isolated renderer process creation), node/ (Node.js initialization for main process), preload_realm/ (sandboxed preload script initialization), renderer/ (renderer process initialization), sandboxed_renderer/ (sandboxed renderer process creation), utility/ (utility process initialization), and worker/ (Web Worker Node.js environments).

Electron shell/ directory C++ structure

The shell/ directory contains C++ source code organized as: app/ (system entry code), browser/ (main window, UI, main process functionality), renderer/ (code running in renderer process), common/ (code used by both main and renderer processes), services/node/ (Node.js runtime for utility processes), and utility/ (utility process code). Browser-specific UI implementations are in shell/browser/ui/ with subdirectories for cocoa/ (macOS), win/ (Windows), and x/ (X11).

Electron patches directory organization

The patches/ directory contains git patches applied to Electron's core dependencies to handle differences between use cases and default functionality. It includes subdirectories for boringssl/ (patches to BoringSSL), chromium/ (patches to Chromium), node/ (patches to Node.js), and v8/ (patches to V8 engine).

Electron script directory for development and release

The script/ directory contains scripts for development purposes including building, packaging, and testing. It includes codesign/ (fake codesigning for testing), lib/ (Python utility scripts), and release/ (scripts for the release process with subdirectories notes/ for generating release notes and uploaders/ for uploading release files).

LanguageModelCreateCoreOptions object structure

LanguageModelCreateCoreOptions is an object with two optional fields: expectedInputs of type LanguageModelExpected[] (optional) and expectedOutputs of type LanguageModelExpected[] (optional).

LanguageModelCreateOptions object structure

LanguageModelCreateOptions object extends LanguageModelCreateCoreOptions. It has two properties: signal (AbortSignal, required) and initialPrompts (LanguageModelMessage array, optional).

LanguageModelCreateOptions signal parameter

The signal parameter of LanguageModelCreateOptions is of type AbortSignal and is required.

LanguageModelCreateOptions initialPrompts parameter

The initialPrompts parameter of LanguageModelCreateOptions is of type LanguageModelMessage array and is optional.

Give your agent this brain