Theia architecture

Previous: Theia-- cloud and the desktop version of the IDE

Architecture Overview

　　This section describes the overall architecture of Theia.

　　Theia is designed as a can, can work between the browser and the remote server desktop applications running locally. In order to support these two modes, Theia run in two separate processes, they are referred to as front and rear ends communicate with each other through the REST APIs on JSON-RPC or HTTP message on WebSockets. For Electron, the front and rear ends are run locally, but in the context of the remote, the remote server is running on the backend.

　　For front and rear ends each have their own dependency injection (DI) of the container (see below), to facilitate the development extend.

front end

　　UI front-end part responsible for client presentation. It simply render loop runs in a browser. In Electron, which runs Electron window, which is an Electron and Node.js APIs of the browser window contains. Therefore, any front-end code can Node.js browser rather than as an operating platform.

　　Front-end process will start all loaded first expansion pack DI module, then get a FrontendApplication instance and calls on it Start () .

rear end

　　Back-end processes running on Node.js. We use the express as an HTTP server, it can not use any code (DOM API) need a browser platform.

　　Start back-end application will first load all the expansion pack of DI module, then get a BackendApplication instance and calls on it Start (portNumber) .

　　By default, the rear end of the front-end server is also to provide express codes.

Differentiated by platform

　　In the expansion pack root, it contains the following subdirectory level, differentiated by different platforms:

common code embodied in the directory does not depend on any operation.
browser code contains the directory needs to be run on a modern browser platform (DOM API).
electron-browser directory contains the front-end code needs Electron DOM API and the rendering process of a specific APIs.
node directory contains the back-end code that needs to run under the Node.js.
node-electron directory contains Electron specific back-end code.

Expansion Pack

　　Theia consists extended package. An extension package is a package npm, discloses a plurality of modules DI (DI container used to create in this package npm ContainerModule ).

　　By application package.json to add a dependency using the extended package npm packet. Expansion packs can be installed and uninstalled at runtime, which will trigger a recompilation and restart.

　　By DI module, the extended package providing from binding to type specific implementation, i.e., to provide services and functions.

Services和Contributions

　　In this section we will describe how to use an expansion pack another extension package services, and how they function to provide Theia.

Dependency injection (DI)

　　Theia using DI frame Inversify.js to connect different components.

　　DI implantation when creating a component (as a parameter to the constructor), whereby the component completely decoupled from the dependencies. DI container to create the configuration item when you start provided by the so-called container module.

　　For example, Navigator widget requires access to FileSystem used to display folders and files in the tree structure, but FileSystem implementation of the interface for the Navigator is not important, it can safely be assumed FileSystem a consistent interface object is ready and can used. In Theia, the FileSystem achieved simply send a message to the backend JSON-RPC agent, it requires a special configuration and processing procedures. Navigator does not need to care about these details, because it will get injected a FileSystem instance.

　　Further, decoupling, and this structure is to allow expansion pack when needed to provide very specific features implemented, for example, mentioned here FileSystem , without requiring access to the FileSystem any interface implementation.

　　DI in Theia is a very important part, therefore, we strongly recommend that you learn Inversify.js basics.

Services

　　Service is only available to a binding other components used. For example, a package can be extended disclosed SelectionService , so that other extended package can get an injected instance and use it.

Contribution-Points

　　If an extension package is intended to provide a hook to achieve one of the functions performed by the other expansion packs, then it should define a contribution-Point . A contribution-point is a packet interfaces may be implemented other extensions. The extension can when it needs to be delegated to other portions.

　　For example, OpenerService defines a contribution point, allowing further expansion pack registration openHandler . You can see here the code.

　　Theia has provided a lot of contribution points list to see contribution points existing in a good way is to look bindContributionProvider references.

Contribution Providers

　　A contribution provider substantially contributions container, wherein the contributions are examples of the type of binding.

　　It is very versatile.

　　To type bound to the contribution provider, you can do this:

（来自messageing-module.ts）

export const messagingModule = new ContainerModule(bind => {
    bind<BackendApplicationContribution>(BackendApplicationContribution).to(MessagingContribution);
    bindContributionProvider(bind, ConnectionHandler)
});

　　The last line contains a ContributionProvider bind to a bound on the object ConnectionHandler all instances.

　　Used like this:

（来自messageing-module.ts）

constructor( @inject(ContributionProvider) @named(ConnectionHandler) protected readonly handlers: ContributionProvider<ConnectionHandler>) {
    }

　　Here we injected a ContributionProvider, its name value is ConnectionHandler, before this value is determined by bindContributionProvider binding.

　　This makes anyone can bind ConnectionHandler, now, when messageingModule starts, all of ConnectionHandlers will be initialized.

Original Address: https://theia-ide.org/docs/architecture