Architecture for an extensible electron app?

Viewed 505

This is a somewhat open-ended question but, what are good ways to make a good extensible electron app? VSCode, Atom and many others support extensions but their codebase is too huge to understand what is going on for me. I am very surprised of Jupyterlab, according to them, it consists in a little core, and everything else is just extensions on top of it. So I was wondering how these apps can be built.

Specific questions I have are:

  • Are there any best practices for creating extensible architectures?
  • How is it that the electron part 'recognizes' the extension? How is it loaded? When should it be loaded?
  • Is there a minimal example of how to do it? Providing these two examples would, in some sense, answer the whole question:
    • An extension that just adds a button in a certain space of the page (so, how to manipulate the dom from an extension)
    • How to add another option in the menubar (so, how to interact with the electron api from an extension.)
1 Answers

No built-in support in Electron (BYOEF)

Electron is BYOEF (Bring Your Own Extension Framework), which means there is no built-in support for extensions in Electron (and yes, I made that term up). VS Code and Atom have implemented their own extension layer on top of Electron.

To support extensions, one would need to implement two core aspects:

  1. An API which defines all of the actions the extensions are allowed to perform, and all of the events that the extensions can hook.
  2. An system to package, distribute, select and install extensions.

How VS Code handles extensions

Since you mentioned VS Code, let's take a closer look at it to see how it implements extensions (this may well be considered de facto best practice for extensible architecture).

Extension-handling source code

You mentioned trying to look at the source code. VS Code's codebase is huge, as you mentioned, but the most important code relating to extensions can be found in the src/vs/workbench/services/extensions/electron-browser folder.

Basic extension format

VS Code distributes extensions as npm modules. This allows each extension to have dependencies on other npm modules, and allows VS Code to easily update extensions (which it does, every time it is opened).

Extension installation lifecycle

When you elect to install an extension, it is downloaded from VS Code's npm repository. The extension's dependencies are installed (as would happen normally, and automatically, when an npm package is installed). The extension exports an activate function, which is called by VS Code after the extension has been fully installed.

It also exports a deactivate function so that it can be removed cleanly.

VS Code's API

VS Code exposes an API for extensions. They can subscribe to events to listen for them, call exposed API functions, register new providers or register new commands to add new functionality.

Implementing the requested functionality

The examples you requested really depend on what you're trying to do and how you want to do it.

To add a button, your main page would have to look for registered buttons and include them on the page. In the VS Code way of doing things, each extension would register their button in the activate() function, if they wanted to do so.

Similarly, to add an option in the menubar, your Electron app's menubar would have to look for any registered menu extensions and populate the menubar with them. Again, the extensions never interact with the Electron API, only with your application's API. You'll need to explicitly define an API and make this accessible to the extension (or just make the entire Electron API accessible, but this would result in a big mess).

Related