feat: Retrofit existing and add new advanced A2UI v0.9 basic catalog samples#941
Conversation
There was a problem hiding this comment.
Code Review
This pull request is a significant and valuable enhancement to the A2UI v0.9 examples. Retrofitting existing static samples to use dynamic features like templating, formatting, and validation, along with adding new advanced examples, greatly improves the test coverage and demonstrative power of the specification. The changes are well-structured and effectively showcase the new capabilities. My review identified a few areas for improvement: a logic bug in a form validation example, a visual regression in a refactored list, and an accessibility concern with a checkbox component. Addressing these points will further strengthen the quality of these important examples.
| "condition": { | ||
| "call": "and", | ||
| "args": { | ||
| "values": [ | ||
| { | ||
| "call": "email", | ||
| "args": { | ||
| "value": { | ||
| "path": "/email" | ||
| } | ||
| } | ||
| }, | ||
| { | ||
| "call": "length", | ||
| "args": { | ||
| "value": { | ||
| "path": "/password" | ||
| }, | ||
| "min": 8 | ||
| } | ||
| } | ||
| ] | ||
| } | ||
| }, |
There was a problem hiding this comment.
The validation check on the login-btn is incomplete. It only validates the email format and password length, but omits the required check that is present on the individual fields. This can lead to an inconsistent UI state where the button is enabled even if a field is empty (assuming email('') is considered valid), while that field simultaneously displays a "required" error. To ensure the button is only enabled when the form is fully valid, the and condition should also include the required check for the email field.
"condition": {
"call": "and",
"args": {
"values": [
{
"call": "required",
"args": {
"value": {
"path": "/email"
}
}
},
{
"call": "email",
"args": {
"value": {
"path": "/email"
}
}
},
{
"call": "length",
"args": {
"value": {
"path": "/password"
},
"min": 8
}
}
]
}
}| "id": "status-checkbox", | ||
| "component": "CheckBox", | ||
| "label": "", | ||
| "value": { | ||
| "path": "/completed" | ||
| } |
There was a problem hiding this comment.
The status-checkbox has an empty label. This is problematic for accessibility, as screen readers won't have a description for the checkbox. A label is required to make the UI understandable for users of assistive technologies. Consider redesigning this part of the example. For instance, if the CheckBox component's label is intended to be the primary text, you could bind the task's title to the label property and adjust the layout accordingly.
| "id": "step-text", | ||
| "component": "Text", | ||
| "text": "Delivered", | ||
| "variant": "caption" | ||
| "text": { | ||
| "path": "label" | ||
| }, | ||
| "variant": "body" |
There was a problem hiding this comment.
The refactoring to use a single template for all shipping steps has resulted in a loss of visual hierarchy. Previously, the current step was emphasized with an h4 variant, and future steps were de-emphasized. Now, all steps use the body variant, making them visually indistinct. This alters the "overall look" of the example. To preserve the intended visual distinction, you might need to consider a different structure, for example by using separate templates for past, current, and future steps, especially if the specification does not support dynamic variants on the Text component.
Description of Changes
This PR significantly enhances the test coverage and demonstrative power of the A2UI v0.9 basic catalog examples. It addresses the gap where previously all examples were completely static.
1. Retrofitted Existing Samples:
11 existing examples have been refactored to natively utilize advanced protocol features without altering their overall look or core purpose.
ChildList): Refactored hardcoded lists intoChildListobject templates mapping over data model arrays in03_calendar-day,04_weather-current,12_chat-message,13_coffee-order,18_track-list, and21_shipping-status.formatCurrency,formatDate,formatNumber, andformatStringacross various samples to format raw data instead of hardcoding strings (e.g.01,05,08,11,13,15,16,17,18,19,23,24,26,27,28).pluralizein05_product-cardand24_recipe-cardfor review counts.checksconstraints to input fields in09_login-formand implemented a logicalandto the submit button to ensure valid input.AudioPlayer(replaced basic play button in26_podcast-episode).ModalandVideo(added a trailer modal to29_movie-card).Tabs(wrapped content in24_recipe-card).ChoicePicker(replaced static billing text in19_software-purchase).CheckBoxandDateTimeInput(added to07_task-card).2. Created New Advanced Samples:
Added 4 new high-fidelity samples designed to stress-test complex A2UI renderer behaviors.
30_live-invitation-builder.json: Demonstrates reactive two-way data binding (editor fields instantly updating a live preview without a server roundtrip).31_incremental-dashboard.json: Demonstrates progressive structural updates (updateComponentsreplacing placeholder loading nodes with real components).32_advanced-form-validator.json: Stress-tests deeply nestedformatStringcalls and complexcheckslogic (e.g.,or(and(...), and(...))).33_financial-data-grid.json: Tests layout engine constraints, specificallyweightandalignwithin nestedListtemplated rows.Rationale
The v0.9 specification introduces powerful dynamic features (templating, client-side functions, validation) that were completely unexercised by the initial set of 29 static examples. To ensure new renderer implementations correctly handle these advanced features, we need a robust, representative set of JSON payloads that accurately model real-world, living UIs.
Testing/Running Instructions
All updated and new examples have been verified against the protocol schema. Reviewers can verify this locally:
python3 specification/scripts/validate.py=== Validating v0_9 ===print[PASS]and the script exits withOverall Validation: PASSED.Fixed #940