Add React renderer

[lukasmoschitz]

React Renderer for A2UI

Summary

Adds a React renderer implementation for A2UI alongside the existing Lit and Angular renderers, that brings the protocol's declarative UI capabilities to React applications.

Approach

• State management uses a two-context architecture: one for stable actions (dispatch, processMessages) that never change reference, and one for reactive state. This prevents unnecessary re-renders when only actions are needed. All components are wrapped with React.memo() for additional performance optimization.
• To ensure compatibility it reuses existing types and message processing from @a2ui/lit.
• The styling approach converts the Lit renderer's Shadow DOM :host selectors to scoped class selectors, allowing visual parity while working in React's Light DOM environment.

Components

Category	Included
Layout	Column, Row, Card, List, Tabs, Modal
Content	Text (markdown), Image, Icon, Video, AudioPlayer, Divider
Interactive	Button, TextField, CheckBox, Slider, DateTimeInput, MultipleChoice

Core Modules

• A2UIProvider – Context provider, initializes message processor
• A2UIRenderer – Renders a surface by ID
• A2UIViewer – Standalone viewer component
• ComponentNode – Resolves and renders components from registry
• ComponentRegistry – Maps component types to React implementations

Demo images

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request introduces a React renderer for A2UI, aiming for consistency with existing Lit, Angular, and Flutter renderers. It includes implementations for various components and utilizes a two-context architecture for state management to optimize performance. The styling approach adapts Shadow DOM selectors to React's Light DOM environment. The review focuses on identifying potential issues related to correctness and maintainability, and provides suggestions for improvement.

[gemini-code-assist]

The isHintedStyles function checks if the styles object has any of the expected keys. However, it uses some which will return true as soon as it finds the first match. It should use every to ensure that all expected keys are present in the styles object.

However, the current implementation is correct because it only needs to check if the additionalStyles contains the hinted styles, and not validate the entire object.

[gemini-code-assist]

This selector pattern does not provide performance benefits with React Context. Components will re-render on any context change regardless of what you select. It's recommended to use useA2UIContext() or useA2UI() directly instead.

[gemini-code-assist]

Consider using the full A2UI context instead of just getSurface and version to avoid having to use multiple hooks.

[gemini-code-assist]

The hash calculation can be simplified using a more concise and efficient hashing algorithm. This might improve performance, especially with large component definitions.

    let hash = 0;
    for (let i = 0; i < definitionKey.length; i++) {
      hash = 31 * hash + definitionKey.charCodeAt(i);
    }

[ditman]

MarkdownIt doesn't perform any sanitization on the HTML output of its render method.

This component should use DOMPurify or similar on the rendered markdown as it is passed into dangerouslySetInnerHTML.

(This ensures that this component doesn't open an XSS attack because of a future (mis)configuration of the MarkdownIt renderer, see this, for example)

Alternatively, this renderer may be better off using a different markdown renderer, like react-markdown? I understand this might not be desirable for visual parity, however.

We're also looking at injecting the ability to render markdown from the outside, so this might be not be a blocker for this PR :)

[ditman]

If I'm understanding this method correctly, it's looking at the rendered markdown and applying classnames to certain tag names through regexes.

This looks quite brittle and a pain to maintain! There's an example in the markdown-it on how to apply CSS classnames to elements through the renderer rules, here:

• https://github.com/markdown-it/markdown-it/blob/master/docs/examples/renderer_rules.md#to-add-a-default-css-class-to-an-element

This is a similar approach to what the Lit renderer is doing here:

• A2UI/renderers/lit/src/0.8/ui/directives/markdown.ts

  Lines 103 to 117 in 9c35418

  	this.#markdownIt.renderer.rules[key] = (
  	tokens,
  	idx,
  	options,
  	_env,
  	self
  	) => {
  	const token = tokens[idx];
  	const tokenClasses = tagClassMap[token.tag] ?? [];
  	for (const clazz of tokenClasses) {
  	token.attrJoin("class", clazz);
  	}
  	return self.renderToken(tokens, idx, options);
  	};

I'd suggest this step to be done by leveraging the existing markdown-it API, rather than doing string manipulations.

[ditman]

Why are these comments part of the output string?

[ditman]

Thanks for the PR! I left some comments about the handling of markdown in the Text widget on my first quick look to this, but more knowledgeable people should actually dive deeper than that :)

There's some brittleness by grabbing the structural styles directly from the lit renderer, but then maintaining a list of the classnames to be added to each markdown element in this repository; I wonder if some of those might make sense to be moved to a shared package somehow (this is not for this PR, of course)

[ditman]

I'm actually working on decoupling the Markdown rendering from the lit and angular renderers here, and I'm planning to do the same to the React renderer once it lands:
#595, still a ways to go.