[v0.10 Proposal] Universal Dynamism: Making all component properties dynamic by default

[jacobsimionato]

This proposal introduces a foundational shift in the A2UI protocol for version 0.10: Universal Dynamism.

Overview

In previous versions (v0.8, v0.9), component properties were explicitly categorized as either static (e.g., string, number) or dynamic (e.g., DynamicString). This forced developers and AI agents to constantly consult the specification to determine if a specific property supported data binding or function calls.

Universal Dynamism removes this distinction. In v0.10, every visual or behavioral property of an A2UI component (excluding structural identifiers like id and component) will support the full range of dynamic capabilities: literal values, data model bindings (path), and client-side function calls (call).

Rationale

1. Developer Ergonomics: Simplifies the mental model. If a property exists, it can be bound to data.
2. LLM Efficiency: Reduces token usage in prompts by eliminating the need to explain which fields are dynamic.
3. Reactive Layouts: Enables data-driven layout changes (e.g., binding a Column's justify property or a component's weight to the data model).
4. Implementation Uniformity: Streamlines renderer logic by allowing a single "Dynamic Resolver" path for all properties via the Generic Binder.

Proposed Specification Changes

1. JSON Schema Refactoring (common_types.json & basic_catalog.json)

• Promotion of Dynamic Primitives: All component property definitions in catalogs should migrate from raw types (e.g., type: "string") to dynamic references (e.g., $ref: "common_types.json#/$defs/DynamicString").
• Dynamic Enums: For properties with a fixed set of allowed literal values (like variant, align, fit), we will introduce a schema pattern that validates the literal enum values while still permitting objects containing path or call.
• Nested Structures: Component schemas will explicitly support arbitrary nested objects and arrays, provided that the leaf values of these structures are defined as dynamic primitives. This allows components to have structured "config" objects while maintaining full reactivity.

2. Protocol Documentation Updates (a2ui_protocol.md)

• Changes from v0.9: Add a dedicated section describing the "Everything is Dynamic" philosophy.
• Data Binding Section: Reframe the explanation to show that dynamism is the baseline for the entire component property tree, not just specific "content" fields.
• Type Conversion: Clarify how renderers should handle coercion when a dynamic property (like an enum variant) receives an unexpected value from a data binding.

Impact on Renderers

The reference web_core renderer's GenericBinder must be updated to recursively traverse any nested property structure defined in a Zod schema and apply reactive subscriptions to every leaf node. Performance optimizations should ensure that literal values are treated as "Constant Signals" to avoid unnecessary reactive overhead.

[jacobsimionato]

Coding agent prompt:

Context References:

• @specification/v0_10/json/
• @specification/v0_10/docs/a2ui_protocol.md
• @renderers/web_core/src/v0_9/ (Reference for migration)

Implementation Strategy:

1. Schema Refactoring (specification/v0_10/json/):

   • Update common_types.json to ensure DynamicString, DynamicNumber, DynamicBoolean, etc., are the standard for all property definitions.
   • Implement the "Dynamic Enum" pattern for all catalog components.
   • Update basic_catalog.json so that properties like variant, fit, align, justify, and weight use dynamic primitives.

2. Documentation (specification/v0_10/docs/a2ui_protocol.md):

   • Update the "Changes from previous versions" section.
   • Update all examples to reflect that previously static properties can now accept {"path": "..."} or {"call": "..."}.
   • Explicitly document that arbitrary nesting is supported as long as leaves are dynamic.

3. Renderer Migration (renderers/web_core/src/v0_10/):

   • Port the logic from v0_9 to v0_10.
   • Modify GenericBinder.ts to recursively handle arbitrary nested objects/arrays in resolveAndBind.
   • Ensure scrapeSchemaBehavior correctly identifies leaf nodes that need dynamic resolution regardless of depth.
   • Optimization: If a leaf value is a literal primitive, the binder should avoid creating a reactive subscription to save resources.

4. Testing:

   • Create a test case with a complex, nested component schema where multiple leaf values are bound to different parts of the DataModel.
   • Verify that updating any of those paths correctly triggers a partial property update in the renderer.

[jacobsimionato]

@gspencergoog @jgindin - curious about your thoughts on this?

[gspencergoog]

In general, I like it, although I suppose technically it is actually complicating the schema in the sense that if you were to use this schema for something like structured output, it would involve a lot more states in the state machine. But conceptually, it does make things simpler, and probably allows an agent to generalize that all properties are dynamic.

[jgindin]

Other types that should not be dynamic is function call parameters and return types :-)

The part of me that has been manually creating UIs for .... many years..... is a bit nervous about allowing for reactive layouts -- not because I don't see it being potentially useful, but from the stand point of a user looking at a page and then having it completely re-arrange itself in unexpected ways. That probably comes down to the application itself and how the instructions are being provided to the LLM to construct it.

But overall, I think this is a good direction.