Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow hooking into command palette commands and command loaders #58200

Open
Aljullu opened this issue Jan 24, 2024 · 2 comments
Open

Allow hooking into command palette commands and command loaders #58200

Aljullu opened this issue Jan 24, 2024 · 2 comments
Labels
[Feature] Extensibility The ability to extend blocks or the editing experience [Package] Commands /packages/commands [Type] Enhancement A suggestion for improvement.

Comments

@Aljullu
Copy link
Contributor

Aljullu commented Jan 24, 2024

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

  1. Know how certain features and UX elements are called, so the plugin can adapt its UX based on that.
  2. Add tracking to know which commands are run, which helps know how users interact with Gutenberg and the plugin itself.
@Aljullu Aljullu added [Type] Enhancement A suggestion for improvement. [Package] Commands /packages/commands labels Jan 24, 2024
@mtias mtias added the [Feature] Extensibility The ability to extend blocks or the editing experience label Jan 24, 2024
@Vrishabhsk
Copy link
Contributor

Hi @Aljullu 👋

Let me know your thoughts on it. Thanks

@Aljullu
Copy link
Contributor Author

Aljullu commented Nov 12, 2024

Thanks for working on this, @Vrishabhsk! This would be perfect for our needs. Is there anything I can help with? I don't think I'm entitled to review/approve that PR, but if there is anything else I can do, let me know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Extensibility The ability to extend blocks or the editing experience [Package] Commands /packages/commands [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

3 participants