Custom documentregistery

Hi, currently the front end Document Registry get the file types that match a file name based on the extension in the name. getFileTypesForPath in @jupyterlab/docregistery. I would like to implement a different logic for mapping (not based on the name) but where the server returns the appropriate file type. I couldnt find any examples to override the Document Registery can you please point me in the right direction ?

The docregistry is rather tightly bound to the application itself. I do not know of an example of overriding it.

If you want this to be a pluggable thing (it appears it may once have been) creating an issue on the repo might be appropriate, as it’s currently in the alpha phase of the 4.0 release cycle, and this would almost certainly entail a breaking change.

Ignoring the “right” way: here be dragons:

You can monkeypatch that method (this is JS, after all: almost nothing is really static, private, etc.) but would potentially encounter race conditions up front.

Of course, this has limitations. And many extensions expect their custom registered files types to actually work, based on file names, irrespective of what your server does. This is probably why this behavior is not customizable.

Because the registry is provided by the app, a plugin that applies this patch could ensure it runs “kinda early” by just not requires-ing anything other than the app, as almost everything else requires something.

const plugin: JupyterFrontEndPlugin<void> = {
  id: '@myorg/my-pkg:customfiletypes'
  requires: [],
  activate: (app: JupyterFrontEnd): void => {
    const {docregistry} = app;
    const oldGetFileTypesForPath = docregistry.getFileTypesForPath;
    docregistry.getFileTypesForPath = (path: string): DocumentRegistry.IFileType[] => {
      // do something clever or...
      return oldGetFileTypesForPath(path);
    }
  }
}

If you need that to be exensible, you could provide a token that allowed for dynamic reconfiguration: this would be a way to balance customizable features with dependency injection.

Thank you vm for your help and the amazing work you do @ jupyterlab.