-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Description
What problem does this address?
A plugin might need to hook into specific commands or command loaders used in the command palette in order to fire a parallel action when the hook is executed.
This can be achieved by registering a new command like the original but running the plugin logic inside the callback. Something like:
const { commands } = useSelect(
( select ) => {
const { getCommands } = select( commandsStore );
return {
commands: getCommands(),
};
},
[]
);
commands.forEach( ( command ) => {
if ( command.name === /* Command that needs to be modified */ ) {
dispatch( commandsStore ).registerCommand( {
...command,
callback: ( ...args ) => {
/* The plugin would add its logic here. */
command.callback( ...args );
},
} );
}
} );While that works, it has some drawbacks, like having to iterate through all commands every time the command palette is opened, being error-prone in case a plugin abuses the system or modifies the command callback signature, etc.
What is your proposed solution?
If there was a hook plugins could use to attach some logic to existing commands, the code above would be greatly simplified, helping make it more future-proof and less likely to break.
I'm thinking of an API similar to addAction() or something on top of that. Each command could run its own doAction(), this way plugins that only extend one specific action would only need to add the action to the particular command.
Use cases
- Know how certain features and UX elements are called, so the plugin can adapt its UX based on that.
- Add tracking to know which commands are run, which helps know how users interact with Gutenberg and the plugin itself.