obsidian/command-handlers/command-handler-component

Component that registers CommandHandlers with Obsidian and ties their removal to its lifecycle.

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 component unload to remove every command still registered through it. 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 component unload to remove every command still registered through it. 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.