command-handlers/command-handler-component

Component that registers CommandHandlers with Obsidian and ties their removal to a chosen lifetime.

Classes

Class Description

CommandHandlerComponent Registers CommandHandlers with Obsidian and manages their lifecycle. Call registerCommandHandlers to register a batch of handlers on demand (as many times as needed while the component is alive); dispose the returned DisposableEx to unregister exactly those handlers — including any menu events they registered — or let the batch’s LIFETIME OWNER unload to remove every command still registered through it. That owner is this component by default, which is why a standalone component removes its own commands when it unloads. It is overridable because the registering component and the registered commands do not always share a lifetime: PluginBase keeps ONE of these running for the whole life of the plugin — it is what the “your dependency went away” notice is built beside — while the commands a subclass registers from onloadImpl belong to the feature surface the gate tears down and rebuilds underneath it. So the owner is resolved per call, from a CommandLifetimeOwnerProvider or from the call’s own lifetimeOwner. The same handlers are fed to every menu surface the component knows about: Obsidian’s own workspace events, plus each additional MenuEventRegistrar bridging another plugin’s menus.

Class	Description
CommandHandlerComponent	Registers CommandHandlers with Obsidian and manages their lifecycle. Call `registerCommandHandlers` to register a batch of handlers on demand (as many times as needed while the component is alive); dispose the returned DisposableEx to unregister exactly those handlers — including any menu events they registered — or let the batch’s LIFETIME OWNER unload to remove every command still registered through it. That owner is this component by default, which is why a standalone component removes its own commands when it unloads. It is overridable because the registering component and the registered commands do not always share a lifetime: `PluginBase` keeps ONE of these running for the whole life of the plugin — it is what the “your dependency went away” notice is built beside — while the commands a subclass registers from `onloadImpl` belong to the feature surface the gate tears down and rebuilds underneath it. So the owner is resolved per call, from a `CommandLifetimeOwnerProvider` or from the call’s own `lifetimeOwner`. The same handlers are fed to every menu surface the component knows about: Obsidian’s own workspace events, plus each additional MenuEventRegistrar bridging another plugin’s menus.

Types

Type Description

CommandHandlerFactory Builds a fresh set of CommandHandlers. A factory rather than a ready-made array because CommandHandlerComponent registers the same handlers against several menu surfaces, and a handler carries per-registration state (its active-file provider, its plugin name, and whatever a subclass records in CommandHandler.onRegistered) — so every surface needs its own instances. Returning shared instances (() => [handler1Singleton, handler2Singleton]) reintroduces exactly the bug the factory exists to avoid, so it is not merely discouraged: CommandHandler.onRegistered throws on the second registration of an instance. CommandHandlerComponent.registerCommandHandlers awaits it, so that throw rejects the caller’s promise instead of degrading into a wrong context menu.

Type	Description
CommandHandlerFactory	Builds a fresh set of CommandHandlers. A factory rather than a ready-made array because CommandHandlerComponent registers the same handlers against several menu surfaces, and a handler carries per-registration state (its active-file provider, its plugin name, and whatever a subclass records in CommandHandler.onRegistered) — so every surface needs its own instances. Returning shared instances (`() => [handler1Singleton, handler2Singleton]`) reintroduces exactly the bug the factory exists to avoid, so it is not merely discouraged: CommandHandler.onRegistered throws on the second registration of an instance. CommandHandlerComponent.registerCommandHandlers awaits it, so that throw rejects the caller’s promise instead of degrading into a wrong context menu.