Allow `ipylab` to consume arbitrary Token without rebuilding
TK-21st opened this issue · comments
General Description
ipylab
interfaces with JLab by exposing requires
Tokens as follows:
const extension: JupyterFrontEndPlugin<void> = {
id: EXTENSION_ID,
autoStart: true,
requires: [IJupyterWidgetRegistry, ILabShell], // <= Token Consumed
optional: [ICommandPalette], // <= Optional Token Consumed
activate: (
app: JupyterFrontEnd,
registry: IJupyterWidgetRegistry,
shell: ILabShell,
palette: ICommandPalette
): void => {
widgetExports.JupyterFrontEndModel.app = app;
widgetExports.ShellModel.shell = shell;
widgetExports.CommandRegistryModel.commands = app.commands;
widgetExports.CommandPaletteModel.palette = palette;
...
Every time an update is introduced that exposes additional tokens to ipylab
, the plugin will be rebuilt.
Specific use case for FocusTracker
discussed in #44
Following up on the original discussion around providing a mechanism for ipylab
to be aware of the sessionContext
associated with the current widget from which ipylab
is invoked. The current approach is to expose the entire global FocusTracker
to user, but the more disciplined approach will be to use INotebookTracker
and IConsoleTracker
instead. However, if there is a custom extension that needs to track the current sessionContext
that is not tracked in either tokens (since this custom extension would not be notebook or console), the user could provide custom tracker token but that will require rebuilding ipylab
.
Right, but it could indeed be useful! Maybe we could track that in a separate issue?
But I was also considering the super edge-case where the user wants to use, say, CodeCell in a custom extension not tracked by INotebookTracker or IConsoleTracker, and hope to inject some code there with ipylab, then this won't work.
The custom extension could provide its own track (
ICustomTracker
), and then ipylab could require this token as optional in the activate function. Although that would mean making a change to ipylab everytime we need to support a new extension. So yes a more general focus tracker could probably scale better.
Possible Solutions
- Use global
FocusTracker
as it is and work from there. Or maybe exposeapp
to every widget and do some black magic within each widget. 🔨 - Ask user to define custom tracker and rebuild every time.
- Somehow allow user to specify arbitrary token as a string? wolfv had a solution to go through the token maps in application in browser (https://github.com/wolfv/jupyterlab-dynext/blob/df14dd245b0b487eb9ba2bec185964d266ad7b85/src/index.ts#L20-L32).
Thanks @TK-21st for opening and all the details!