Settings UI improvement

[brichet]

Fixes #35

record-2025-02-20_18.17.07.webm

This PR uses a react component in the settings panel, to make it more reactive and configurable.
With this new setting component:

• settings are saved for each provider, and restored when loading the page again (use local storage)
• the field containing the word 'key' are replaced by a password widget

It also use a simpler way to import generated schema, no need to set it up manually when adding a new provider.

[brichet]

This PR is missing some helpers about the use of each provider, as described in #35 (comment).

Since this is using a FormComponent, helper could easily be included above or below it.
A better user experience could be to include it between the provider select and the dynamic settings. This option needs some refactoring to split the form, and include the helper.

[brichet]

Instructions added to the settings (currently only for MistralAI and ChromeAI), those from the readme.

record-2025-02-27_13.15.05.webm

[brichet]

The instructions are displayed using the markdown renderer from Jupyterlab, provided by IRenderMimeRegistry.
The way Jupyterlab allows to render a specific widget in place of the regular settings form doesn't allow to pass some arguments to that widget. Therefore, we use a static variable to provide the IRenderMimeRegistry, I did not find a another option.
I explored the use of the formContext props, but it doesn't seems that we can pass additional properties to it currently (see here)

[jtpio]

I explored the use of the formContext props, but it doesn't seems that we can pass additional properties to it currently (see here)

Thanks for looking into this 👍

Having a way to provide more parameters would indeed also be useful to pass a secret manager (#37), so the secrets could be saved elsewhere.

For now I guess we can use the trick of the static method, but maybe there is something so be done in JupyterLab to make this more flexible.

[jtpio]

Probably fine to leave them here in one file here for now.

Later when third-party extensions can register additional AI providers (#45) they could also provide their own instructions for their provider.

[jtpio]

Wondering how this would play with a custom overrides.json, in case some deployments would like to pre-configure a model (and some of its options) by default?

[brichet]

That would probably overwrite it.
I don't really know how works overrides.json. Can we get its default values with annotatedDefaults() ?
In this case we could simply replace '{}' with this._settingsRegistry.annotatedDefaults().

BTW, we should probably rename this._settingsRegistry to this.settings for consistency.

[brichet]

Looks like annotatedDefaults() returns the overrides.json contents.

In the constructor, we could check if there is a value in localStorage.getItem(STORAGE_NAME).
If not, read the annotatedDefaults() and, if the provider is set in the default settings, fill the local storage with its contents and set the default provider as current. If the provider is not set in the default settings we can probably not use these values.

[brichet]

@jtpio I updated the PR according to my previous comment, using this._settings.default('AIprovider') instead of this._settingsRegistry.annotatedDefaults().

[brichet]

@jtpio this PR is ready.

• the AISettings component does not use a static rendermime registry anymore. The renderer uses a factory to provide the rendermime registry to the component (thanks again @jtpio for providing this solution)
• if there are no settings in the local storage, it uses the user settings (which lead to the default settings if empty too)

[jtpio]

Thanks!