Problem

The URL api is robust for one-off solutions, but makes it harder to integrate.

Proposed Solution

In addition to a well-documented URL param scheme, offer a postMessage API that allows for basic things like "run some code", arbitrary lumino commands, or anything that an extender can imagine.

Background

Having fought with more than a few IFrames, it can be nice to offer both a bare-minimum, fire-and-mostly-forget URL api, as well as a well-structured, message-based API. A good (counter-)example is the drawio embed mode:

• hooray! it can do lots of things!
• boo! that's pretty much it for docs!
  • a robust API in a JSON schema and typings would go a long way to helping implementers who wanted to build e.g. replite-react or replite-vue or whatever they want
    • indeed, as a low-effort integrator demo, it could use rjsf to draw a message builder/viewer

Why both?

By splitting "long term" URL params and "on-demand" postMessage an integrator can then get interesting interplay effects: pass ?ui=0&input=0 and then have the host take over firing all of the execute methods with their own buttons

For e.g. wasm-based kernels, until we can figure out a SharedWorker worker kernels it's particularly important to not add 10s of 100mb kernels, even if in iframes. In a long-form document, a more feasible approach one would be to have a single iframe/kernel/cell, fixed in the viewport, that gets updated as the reader scrolls/clicks on things.

Design Considerations

As for what actually goes in this API: a really quick win is the app.commands.execute... while no a-priori schema exists, a running lab could at least enumerate what commands it has.

Similar to #10

It should be possible to choose a different language than English via a query string parameter. For example French or Simplified Chinese.

The deployments would need to include the language packs.

Right now the console toolbar is empty:

Maybe we should add a couple of buttons to it, for example:

• run
• restart
• clear

So the kernel dialog popup doesn't show up:

Right now the cell prompt is stacked on top of the cell when the width is less than 760px:

Based on this CSS in JupyterLab: https://github.com/jupyterlab/jupyterlab/blob/3.2.x/packages/cells/style/inputarea.css#L52-L68

For the console, we should override that or maybe even remove the prompt?

For now we override the CSS to hide the RetroLab extra UI elements with:

https://github.com/jtpio/nano-console/blob/805094013d07a749d3d540c9a6e9d1399ca06b80/index.css#L1-L13

This is not ideal. Instead we could make a small prebuilt extension that would customize the interface, so it gets properly deployed with jupyter lite build.

This would also be useful if we want to make a "Powered by JupyterLite" banner (similar to GitHub gists) at the bottom of the frame.

Eventually this minimal REPL should be one of the apps distributed by default in JupyterLite.

For now lite ships lab and retro by default: https://jupyterlite.readthedocs.io/en/latest/api/py/jupyterlite.html#jupyterlite.constants.JUPYTERLITE_APPS

There could be a new app called cell.

If this is a standalone app like retro, the look and UX could be different and not limited to the JupyterLab code console.

We'll want to fix jupyterlite/jupyterlite#118 first though.

The cell app could be either in core, or as a third-party app under the jupyterlite org. The latter might require some work in the jupyterlite CLI to allow apps as (federated) plugins.

Related to jupyterlite/jupyterlite#148

It would be great to be able to choose the default theme via a command line parameter.

For example the JupyterLab light and dark themes. But this would also work with other third-party themes distributed as prebuilt extensions.