Skip to content

feat(web-core): implement client capabilities API in MessageProcessor#826

Open
jacobsimionato wants to merge 16 commits intogoogle:mainfrom
jacobsimionato:clientCapabilities
Open

feat(web-core): implement client capabilities API in MessageProcessor#826
jacobsimionato wants to merge 16 commits intogoogle:mainfrom
jacobsimionato:clientCapabilities

Conversation

@jacobsimionato
Copy link
Collaborator

@jacobsimionato jacobsimionato commented Mar 12, 2026

Description

Updates the getClientCapabilities implementation in the web core renderer to fully support functions and theme schemas, aligning with the A2UI specification. Restructures the TypeScript definitions for the capabilities payload to live natively within the schema layer, and adds comprehensive guidelines for managing protocol serialization boundaries across all renderers.

Changes

  • Client Capabilities Typings: Extracted the protocol-specific payload typings (InlineCatalog, FunctionDefinition, JsonSchema, A2uiClientCapabilities) out of message-processor.ts and into a dedicated schema/client-capabilities.ts file, establishing strong deep typings corresponding to the client_capabilities.json schema.
  • Catalog Types: Added an optional themeSchema property to the Catalog class and updated its constructor.
  • Capabilities Generation: Updated MessageProcessor.generateInlineCatalog to successfully serialize functions and themeSchema into the client capabilities object. Applied processRefs to these schemas to ensure correct JSON Schema references.
  • Schema References: Added REF: tags to shared schemas in common-types.ts (e.g., DataBinding, FunctionCall, DynamicValue, ChildList, Action, Checkable) to enable automatic $ref node generation during capability exchange.
  • Testing: Added comprehensive test cases to message-processor.test.ts covering edge cases for REF: tags, multiple catalogs, nested references, and empty schema states.
  • Documentation (renderer_guide.md):
    • Updated the capabilities serialization logic for future A2UI renderer implementations.
    • Added a new "Protocol Models & Serialization" architecture section. This explicitly defines the boundary between raw JSON network streams and internal state models, instructing future renderer authors to build strict data classes (like A2uiMessage or A2uiClientCapabilities) that handle serialization/validation before passing objects into the MessageProcessor.

- Enhanced the Standard Observer Pattern details with clear Unsubscribe Pattern notes and Payload Support specifics.
- Added clarification that the instantiating system is responsible for extracting functions from the Catalog.
- Replaced the brief overview with a highly detailed section on 'Generating Client Capabilities and Schema Types'.
- Inserted a new rationale detailing observability consistency and function categorizations.
- Replaced the brief 'Demo Application' outline with the full, detailed 'The Gallery App' documentation.
*   Moves zod-to-json-schema to dependencies for runtime schema generation.
*   Adds getClientCapabilities to MessageProcessor to report supported catalogs.
*   Implements generateInlineCatalog to dynamically export component schemas.
*   Implements processRefs to transform REF: tags into standard JSON Schema  pointers.
*   Adds comprehensive test suite for capability generation and schema transformation.
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a getClientCapabilities API to the MessageProcessor, enabling the client to advertise its rendering capabilities to the server. The implementation includes generating JSON schemas from Zod definitions and handling custom $ref transformations. The changes are well-tested and include significant updates to the renderer guide documentation. My feedback focuses on improving type safety by replacing any types with specific interfaces and suggesting a refactor for clarity in the recursive schema processing logic. I've also noted an opportunity to enhance the updated documentation by restoring some explanatory comments.

* Options for generating client capabilities.
*/
export interface CapabilitiesOptions {
/** If true, the full definition of all catalogs will be included. */
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought the idea for this option was to allow inline catalogs, not to include the full definition of all of them.

return;
}

// If not a REF target, recurse into its children.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if an expanded $ref has a REF: in it? Or is that not possible? Or is this just an incorrect comment?

"@preact/signals-core": "^1.13.0",
"zod": "^3.25.76"
"zod": "^3.25.76",
"zod-to-json-schema": "^3.25.1"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be bloating the front end, though. I was tempted to add this in the past too, but decided against it in order to keep the front end lean. If you think it's worth it, we should quantify the size hit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

2 participants