Problem

Authors of extensions (and JupyterLab) want to have a detailed description for more complex setting objects in the JSON settings editor. This descriptions are often auto-generated to include all necessary options. However, once a custom setting UI form is added these descriptions are no longer needed, and in fact confusing to the user of UI editor as they do not correspond to options in the UI. There are a few examples where a way to hide a description would be useful:

• JupyterLab shortcuts UI (currently hard-coded to hide description)
• jupyterlab-lsp server configuration options Implement settings UI using native JupyterLab 3.3 UI  jupyter-lsp/jupyterlab-lsp#778
• in the future: custom forms for edition of the menus and toolbars (see example screenshot of current, non-relevant description for toolbars below)

Currently shortucuts UI has description hidden thanks to hard-coded override:

which was fine as a quick workaround, but does not allow extension authors to take advantage of this option.

Proposed Solution

Currently custom form components can be registered by adding a renderer function:

I propose to wrap the renderer into a component-describing interface so that we can pass additional option to custom field templates:

/**
 * Form component options
 */
export interface IFormComponent {
  /**
   * A function that takes props and returns a rendered component.
   */
  renderer: Field;
  /**
   * Whether the description derived from schema should be hidden. Default is false.
   */
  hideDescription?: boolean
}

In backward-compatible fashion two methods will be added:

• addComponent(id: string, component: IFormComponent): boolean
• components(): { [id: string]: IFormComponent } to match existing renderers

Following methods will be deprecated:

• addRenderer(id: string, renderer: Field): boolean
• getRenderer(id: string): Field - currently not used in JupytyterLab codebase

Subsequently code handling description will be added to the CustomTemplate (Factory, see #12732)

Additional context

This approach will allow to expand IFormComponent in the future with additional attributes and methods without introduction of breaking changes.