Transfer jupyterlab-rjsf

[martinRenou]

Target

• The code repository: https://github.com/deathbeds/jupyterlab-starters/tree/main/packages/jupyterlab-rjsf
• The npm package on npmjs.com (if available): https://www.npmjs.com/package/@deathbeds/jupyterlab-rjsf
• The python package on pypi.org (if available):
• The conda-forge recipe on https://github.com/conda-forge (if available):
• The documentation website (if available):

Reason

Checklist

• You are owner of the repository you want to transfer
• Which role do you want to have in the jupyterlab-contrib organization (check one of):
  • Help with all jupyterlab-contrib repositories
  • Help with the transferred repository only
  • I don't have time anymore to keep helping the project
• The transferred repository (check one of):
  • Must keep the extension name
  • Cannot use the original name
  • I don't care
• The code is available under a Open Source license
• A license file is present in the code repository
• The extension is working on at least JupyterLab 3.x
• The repository contains a README file describing:
  • The provided feature(s)
  • A picture illustrating the feature(s)
  • The available options/settings (if applicable)
  • How to install the extension
  • optional a Binder link to test the feature online
• optional The frontend code (Typescript/Javascript) is tested
• optional The backend code (Python) is tested
• I certify the extension is not using exclusively paid-plan of any commercial service
• I will help the transfer process on the code repository AND the built packages

You must enable two-factor authentication on GitHub

cc. @bollwyvl

We would like to move jupyterlab-rjsf https://github.com/deathbeds/jupyterlab-starters/tree/main/packages/jupyterlab-rjsf into a place we can maintain as a community. Right now that package is buried inside a monorepo that makes it difficult for us to contribute and update.

We depend on this in multiple packages, and the fact that it still builds against JupyterLab 3 packages makes it difficult to work with.

I suggest we move that under jupyterlab-contrib and continue the maintenance there.

[bollwyvl]

I'll echo my position from during the implementation of the settings form: this feature (if not perhaps this implementation) belongs in JupyterLab itself, available to all extension authors. This could be delivered either via rjsf, or, and likely better, as a lumino component agnostic to the actual leaf node renderer.

Considering the former: as rjsf is already a dependency (and part of the public API of) JupyterLab, a low-react lumino widget could be made available (in e.g. ui-components), with an rjsf Theme which fully participates in the jupyterlab theming system, design language, configurable markdown renderer, etc. It should be possible to add additional schema renderers, templates, etc. to a default registry. In the specific case of settings, that metaschema would expand to provide the full uiSchema object, allowing for very precise control of individual fields, rather than the "big stick" of an entirely custom react widget.

Such an implementation could then go further, making more key jupyterlab UI features available as JSON-configurable widgets. Examples include: LSP-enabled CodeEditor components, lumino DataGrid, etc.

In light of the react/lumino dissonance, the other direction (implementing an accessible, themable, lumino-first JSON schema renderer) would likely be more maintainable long term, and would make deeper reuse more plausible.

[martinRenou]

I fully agree with this. Having this in core JupyterLab would be great.

Having it in jupyterlab-contrib as an intermediary step also does not sound crazy to me, getting it in good shape and updated with latest jupyterlab packages. Then porting it to the JupyterLab codebase would be easier and convincing other JupyterLab maintainers to get it in may be easier.

[bollwyvl]

My experience has been that supporting complex extensions in the 4.x line has become increasingly difficult. If an organization has the means to support this work in any form, going directly for lab 4.4.x will provide the most benefits for the greatest number of extension authors and thereby users. I doubt there is much to convince about: unless replaced with a feature-complete lumino implementation, rjsf (and clearly codemirror, marked) aren't going anywhere in the codebase in the 4.x line, and making these features available via declarative JSON (instead of JSX soup) would be a boon.