@dxos/app-framework - v0.15.0
    Preparing search index...

    Interface PluginModule

    A unit of containment of modular functionality that can be provided to an application. Activation of a module is async allowing for code to split and loaded lazily.

    Ordering between modules is expressed through capability dependencies, not registration order: a module declares the capabilities it provides and requires, and the plugin manager activates providers before consumers (topological order). Runtime-event modules (activatesOn) activate only when their event fires. See plugin-client/src/ClientPlugin.ts for a worked example.

    org.dxos.app-framework.moduleActivationOrdering applies: sequencing one plugin module's activation before or after another instead-of: assuming module registration order controls activation order uses: ActivationSpec

    interface PluginModule {
        "[PluginModuleTypeId]": typeof Plugin.PluginModuleTypeId;
        activate: (
            props?: any,
        ) => Effect<
            ModuleActivateResult,
            Error,
            Scope
            | Plugin.Service
            | Capability.Service,
        >;
        activation: ActivationSpec;
        id: string;
    }
    Index

    Properties

    "[PluginModuleTypeId]": typeof Plugin.PluginModuleTypeId
    activate: (
        props?: any,
    ) => Effect<
        ModuleActivateResult,
        Error,
        Scope
        | Plugin.Service
        | Capability.Service,
    >

    Called when the module is activated. Declared requires are provided as Effect services; CapabilityManager and PluginManager are ambient (Capability.Service, Plugin.Service).

    Type declaration

    activation: ActivationSpec

    Normalized activation specification — how and when the module activates.

    id: string

    Unique id of the module.