New repository: AI related components for the chat

[brichet]

This is a proposition to add an extension that would share AI related frontend components to display in the chat.

Currently the repo is at brichet/jupyter-chat-components.

DESCRIPTION

MIME renderer

Components are exposed through a custom MIME type: application/vnd.jupyter.chat.components.

This extension registers a MIME renderer factory with JupyterLab's render MIME registry. To display a component, produce output with the MIME type above, where:

• the data value is the component name (e.g. "tool-call")
• the metadata contains the props to pass to the component

The MIME renderer looks up the component name in the factory's registry and renders the corresponding React component.

Component registry

The registry is available directly on the IComponentsRendererFactory token as the registry property. It maps component names to React components and exposes the following methods:

• add(name, component) — register a new React component under a unique name
• get(name) — retrieve a registered component by name
• has(name) — check whether a component is registered
• getNames() — list all registered component names

Other JupyterLab extensions can consume the IComponentsRendererFactory token and use registry.add() to register their own components, which will then be available for rendering via the MIME bundle.

Available components

Currently only a tool call component is available, to display the state and output of a tool call. It allows an awaiting approval state, that display buttons to approve or reject a tool call.

MOTIVATION

The main motivation is to avoid each extension to provide their own components, that probably won't be compatible and reused.

Related discussion in jupyter-chat: jupyterlab/jupyter-chat#276

For example the tool call component is already defined at least in 2 projects:

• https://github.com/jupyterlite/ai/blob/62da3ae6181f4c437eb2b27420a2285b49848cb1/src/chat-model.ts#L1130
• https://github.com/jupyter-ai-contrib/jupyter-ai-acp-client/blob/a168388967f7fbc5ead9e002ac4adad433f6bac0/src/tool-calls.tsx#L15

[brichet]

Although the “tool call” component currently corresponds to that of @jupyterlite/ai, the goal is to make it compatible with other projects that might use it. It will probably need some update to be really usable by several projects.

[brichet]

The package name can also be changed if there are more relevant ones.

[brichet]

@jupyter-ai-contrib/decision-makers

[jtpio]

The repo now also includes a diff component, based on the current implementation in https://github.com/jupyter-ai-contrib/jupyter-ai-acp-client:

You can try it in your browser with JupyterLite: https://brichet.github.io/jupyter-chat-components/notebooks/?path=components_demo.ipynb

[jtpio]

Gentle ping @jupyter-ai-contrib/decision-makers

[Zsailer]

I'm 👍 on this.

[krassowski]

I'm not a decision maker here but 👍

[ellisonbg]

Ouch, sorry this has been sitting for so long. Feel free to ping us personally through other channels if we miss something like this.

I am +1 on adding this repo and want to make sure we have a single set of components for these things in the long run. We will need to go through a process of merging this with the components we have in the ACP clients and ensure high quality. I don't have a sense of which repo has which components and what the de-dup/merge will look like yet - we may end up keeping some from the ACP repo and some from the new repo being pulled in.

[ellisonbg]

Also, I love the JS kernel usage to show demos of components, very cool!

[dlqqq]

👍 +1, totally agree that this would be a valuable addition to the JAI contrib org. We need more time to review & test before making it a dependency of jupyter_ai, but we're happy to see this being worked on & would love to see it grow.

[3coins]

+1 on shared, reusable components. The duplication problem is real and this is a great initiative. Before we commit to a specific repo location though, a few things I'd love to see us think through:

1. Long-term home: Should these components eventually live in @jupyter/chat (which already owns the types they render and the MIME renderer infrastructure), or is jupyter-ai-contrib the right permanent home given the AI-specific nature of the components? Worth being explicit about this so downstream consumers know what to depend on.
2. Migration of existing components: We already have tool-call and diff-view implementations in jupyter-ai-acp-client that overlap with what's here. The types are encouragingly close (mostly a snake_case vs camelCase difference), so convergence should be straightforward. It would be good to have a plan for how and when existing consumers migrate to the shared components.
3. Governance: Who drives decisions on the shared component API going forward? Since changes here will affect multiple downstream projects, we'll need a responsive review process. This discussion sat for over a month after the initial @jupyter-ai-contrib/decision-makers ping, that turnaround time would be tough to sustain once other projects are depending on this library.

[brichet]

Thanks for approvals and suggestions.

After discussion during the weekly meeting, I'll move the repository in jupyter-ai-contrib to ease tests, as a first step.

[brichet]

Done https://github.com/jupyter-ai-contrib/jupyter-chat-components