An activation event tells the plugin manager when a module should load. Modules wait for their event, so a plugin’s code loads
when it is needed, not all at startup.
ActivationEvent.make declares an event from an NSID. ActivationEvent.pluginStart returns a plugin’s own start event,
which the plugin manager fires on demand and while it is idle.
A plugin's feature-start event, by convention <pluginKey>.event.start. A plugin's
off-critical-path modules declare activatesOn on its own start event (conventionally
exported as <Name>Events.Start from the plugin's types); cross-plugin contributions (a
skill, a markdown extension) declare the CONSUMING plugin's start event. Deriving the id
from the key alone lets fire sites (enable, idle, demand signals) activate a feature
without importing its package.
Helper to define an eager module body with the same spec-carrying shape as
lazyModule
— for bodies that are plain values (translations, schema) or too small
to justify a chunk, so plugin definitions stay a uniform chain of spec-carrying modules.
@param ― name The module name — used to auto-compute module IDs.
Requirements order modules within an event. A module that requires a capability activates after the module that
provides it, whichever event activated the provider. Registration order does not matter.
1
import*as
import Effect
Effectfrom'effect/Effect';
2
import*as
import Capability
Capabilityfrom'@dxos/app-framework/Capability';
3
4
// No `activatesOn`: this module waits for `Index`, so it activates whenever the
Helper to define an eager module body with the same spec-carrying shape as
lazyModule
— for bodies that are plain values (translations, schema) or too small
to justify a chunk, so plugin definitions stay a uniform chain of spec-carrying modules.
@param ― name The module name — used to auto-compute module IDs.
Provides a way to write effectful code using generator functions, simplifying
control flow and error handling.
When to use
Use when you want to write effectful code that looks and behaves like
synchronous code, while still handling asynchronous tasks, errors, and complex
control flow such as loops and conditions.
Generator functions work similarly to async/await but keep errors,
requirements, and interruption in the Effect type. You can yield* values
from effects and return the final result at the end.
A module fires an event with Plugin.activate. This is how a plugin loads another plugin’s modules on demand, for
example when a person opens the create dialog.
Fired when the app is started.
Defined in core; see
ActivationEvent$.Startup
.
Startup,
5
import ActivationEvents
ActivationEvents.
const Idle: ActivationEvent.ActivationEvent
Fired once by the host at main-thread idle after the app is interactive.
For REGISTRATION contributions only — graph builders, operation handler sets, settings: the
app-wide indexes a user can reach from anywhere (the navtree, the operation registry, a
settings read) and which therefore no single surface can gate. A feature's own modules ride
its plugin start event, fired when its surface renders; putting a feature body here instead
is what turned the former DeferredStartup into a second startup pass.
This is also what omitting activatesOn normalizes to, so a module that must run at boot has
to say activatesOn: ActivationEvents.Startup explicitly. Defined in core; see
Demand signal for React surfaces, keyed by role NSID. Fired when a Surface for the role
first renders (and by availability checks that miss), so surface modules gated on their bound
roles load exactly when a screen region that can host them appears.
SurfacesRequested('org.dxos.role.article'),
7
];
8
Module makers such as AppCapability.surface set the right event for their capability, so most manifests never name
one.
