How client plugins load
DataMind Oda's interface is built from client plugins. Every time the interface starts, Oda decides which of them load, in what order, and which are prefetched before you can interact. This page, for plugin developers, describes that loading model. What a client plugin can add to the interface is on Extending Oda's interface.
How a client plugin reaches the browser
- The interface is assembled from client plugins, and each plugin ships as a bundle that the app serves to the browser.
- At startup, the app composes a startup graph from its client plugins: which plugins are part of the interface, where each bundle lives, and how they depend on one another.
- The app serves each plugin's bundle and exposes the plugin inventory.
- The browser keeps a lazy module table: a client plugin's module is fetched from it only when the interface needs it, so plugin code loads on demand instead of all at once.
- Plugins the interface needs from the first paint are prefetched at startup, so they are ready before you interact.
- The module system is part of the interface from the start: it is the baseline that every other client plugin builds on.
What a plugin's loading metadata decides
Every client plugin carries loading metadata, and the metadata decides how and when the plugin loads.
- Platform. Client plugins target the web interface, and the metadata records that platform.
- Load stage. A plugin can be marked to load immediately: it joins the stage-one prefetch set that is fetched at startup. Every other plugin loads lazily, when the interface reaches it.
- Injections. A plugin declares the services it needs. What a plugin declares is resolved before the plugin starts, so it starts only once its declared services are available.
What this means for your plugin
- Only the listed plugins load. The interface loads the client plugins its startup graph lists. A plugin that is not part of that set is never mounted, so nothing of it appears in the interface.
- Declare what you need. A plugin gets the services it declares, and the startup order follows the declarations.
- Pick the right load stage. Mark a plugin to load immediately only when the interface needs it from the first paint; otherwise let it load lazily.
- Check the inventory. The loaded plugins appear as a read-only inventory in Settings > Plugins; see Settings sections and plugins. To see what a running plugin exposes, start from Inspecting plugins.
- While you develop. Edited client code can swap into an open page by itself while the web development loop runs; see Live reload for client plugins.
Questions, answered
Which client plugins load when Oda starts?
The plugins marked to load immediately: the stage-one prefetch set. The module system is in it, since every other client plugin builds on it. Plugins outside the set load lazily, when the interface needs them.
What does a plugin's loading metadata cover?
Three things: the platform the plugin targets, whether it loads immediately or lazily, and the services it declares. How the plugin loads follows from that metadata.
What are injections, and why declare them?
Injections are the services a plugin declares it needs. What a plugin declares is resolved before the plugin starts: a plugin starts only once the services it declares are available.
What decides the order client plugins start in?
The declared services. A plugin starts after the services it declares are available, so the startup order follows the plugins' declarations.
Does a client plugin's code load at startup even when it is not needed yet?
No. Only the stage-one prefetch set is fetched at startup; every other plugin stays in the lazy module table and loads when the interface needs it.
Why does my client plugin not appear in the interface?
The interface mounts only the client plugins its startup graph lists. A plugin that is not part of that set never loads, so nothing of it appears in the interface.
How do I check which plugins are loaded?
The loaded plugins appear in Settings > Plugins as a read-only inventory; see Settings sections and plugins. To inspect what a running plugin exposes, start from Inspecting plugins.