It seems like it is common practice to use commands that have been added to the command registry when developing extensions. For example, we might want to execute the ‘docmanager:new-untitled’ command. However, it isn’t clear to me how we are to know what args we can pass to the execute method.
Presently, the approach I have worked out is to grep the repository for the command…
(jupyterlab-ext-3.0) [null@localhost jupyterlab]$ find ./ -type f -exec grep -H $‘'docmanager:new-untitled’ {} ;
./packages/docmanager-extension/src/index.ts: export const newUntitled = ‘docmanager:new-untitled’;
…and then look in the corresponding addCommand for hints at what arguments can be passed to the command.
Am I approaching this correctly? This a pretty broad question. Perhaps a better approach is to not necessarily use commands that have been registered by other plugins?
Yeah, no… it’s not super discoverable from source. But you should use other commands, because they are awesome, and usually reduce your coupling on internal implementation details!
If you’re debugging inside a running app, you can inspect the command registry (e.g. app.commands) in the browser console, and that will at least give you the ids of all the commands (there are lots of dynamic ones!) but it’s not going to help you figure out what they need in order to work.
There’s this (aging) lumino issue to make a CommandRegistry generic over a validation contract. I think I actually hacked some code together, but since it’s unlikely lumino would take a heavyweight validation library as a dependency, and Galileo knows we shouldn’t write another one, it would be up to the application implementation to decide how to implement it. In JupyterLab, which already has ajv around, JSON Schema would be a fairly safe choice.
2 Likes