Add a plugin to be able to swap the doc provider

[jtpio]

References

Fixes #10252

Early draft for what it would look like to have a plugin that can be used to set custom providers.

TODO

• Move the doc provider instantiation to a plugin
• Rename IProvider to IDocumentProvider
• Docstrings for the IDocumentProvider interface
• Move reading the page config option to the plugin?
• Create a docprovider-extension package?

Code changes

Move the creation of the provider in the document context to a plugin, which can then be disabled or replaced in other lab extensions and distributions.

User-facing changes

None

Backwards-incompatible changes

Add an optional parameter to some of the instantiation options.

[jupyterlab-dev-mode]

Thanks for making a pull request to JupyterLab!

To try out this branch on binder, follow this link:

[jtpio]

Rebased to grab #10258, so this PR can be tested on Binder with RTC enabled.

[echarles]

@jtpio quick feedbacks

• The token IDocumentProviderFactory defined in docprovider is provided with a plugin const docProviderPlugin: JupyterFrontEndPlugin<IDocumentProviderFactory> = { in the docmanager-extensionpackage. Is that inline with jupyterlab architecture? I mean, I was expected to see a new docprovider-extension package to do that job. A new package for that single bit may sound overkill, but it is like that in many other existing packages.

• What about docregistry. For now, the IDocumentProviderFactory is passed to the registry through options. Wouid it make sense to also inject it? In that case we would need to convert the docregistry to an extension, which is not the case now.

[jtpio]

• I was expected to see a new docprovider-extension package to do that job. A new package for that single bit may sound overkill, but it is like that in many other existing packages.

Yes, it's still one of the remaining TODO items listed in #10256 (comment).

This was also discussed yesterday during the RTC call (https://hackmd.io/UbnBH58hS8itoWgfiWT77A) and the conclusion was that it would indeed make sense to have a docprovider-extension package.

I can update this PR to add it.

[jtpio]

• What about docregistry. For now, the IDocumentProviderFactory is passed to the registry through options. Wouid it make sense to also inject it? In that case we would need to convert the docregistry to an extension, which is not the case now.

Not sure yet. But probably something to think about as a follow-up?

[echarles]

I can update this PR to add it.

Great!

Not sure yet. But probably something to think about as a follow-up?

Looking more at the constructs, the Context is created by the docmanager which is injected with the correct IDocumentProviderFactory, so having an docregistry-extension does not make sense for that case.

Another enhancement would be to make the docregister/context a bit more agnostic, so not having to depend directly on the yjs library, so not having to maintain those 2 fields

  private _ydoc: Y.Doc;
  private _ycontext: Y.Map<string>;

[jtpio]

The splice_source check fails because docprovider-extension is not published to npm yet.

[jtpio]

Added the docprovider-extension package (cc @echarles if you want to have a look).

Some CI checks will fail until the package is published to npm.

[echarles]

I have quickly scanned the diff and it LGTM. Do you have more to add before I review?

[jtpio]

Thanks.

I think it should be ready to go.

[echarles]

Reviewed and tested. LGTM. Let's wait 2 days before merging to get any further comment.

[jtpio]

Thanks @echarles.

A follow-up to this PR would be to publish the new docprovider-extension package to npm to fix the failing CI checks.

[blink1073]

Thanks @jtpio and @echarles! I'll cut another alpha with this today (in a few hours), but will hold off merging until then so CI stays working.

[blink1073]

Releasing now

[blink1073]

https://github.com/jupyterlab/jupyterlab/releases/tag/v3.1.0a9

[echarles]

Thx @jtpio and @blink1073