Refactor v0.8 Angular renderer into versioned directory#876
Refactor v0.8 Angular renderer into versioned directory#876gspencergoog merged 13 commits intogoogle:mainfrom
Conversation
b6a7e45 to
a8512c2
Compare
|
@gemini-code-assist[bot] The perceived downgrade of |
|
Thank you for the further clarification. It's good to know that the version change to |
- Centralized all v0.8 types in `angular/src/v0_8/types.ts`. - Standardized component types to use the `...Node` suffix. - Updated all internal v0.8 files to import types from the local `types.ts`. - Fixed `Theme` service to use explicit `WebCore.Theme` properties. - Corrected style assignment in `Text` component for union types. - Fixed `MarkdownRenderer` provider. - Corrected `Checkbox` component action handling. - Fixed `$schema` path in `ng-package.json`. - Verified changes with a successful library build.
jacobsimionato
left a comment
There was a problem hiding this comment.
I don't feel super strongly, but Lit and web_core branch the versions below the src/ folder, rather than above, e.g. https://github.com/google/A2UI/tree/main/renderers/lit/src/0.8 or https://github.com/google/A2UI/tree/main/renderers/web_core/src/v0_8 .
Should we follow that pattern? e.g. renderers/angular/src/v0_8 ?
Updated @a2ui/angular renderer v0.8 to provide the expected interfaces and exports for the contact sample project, enabling it to build without modifying sample code. - Renamed SurfaceHost component to Surface. - Added DEFAULT_CATALOG with standard component registration. - Enhanced MessageProcessor with events Subject, dispatch(), and clearSurfaces(). - Updated provideA2UI and provideMarkdownRenderer to match sample usage. - Exported missing types like A2AServerPayload and Surface.
The symlink samples/client/angular/projects/lib/v0_8 was redundant because the build system already finds the correct sources through the src symlink. Removing it restores more of the sample's original state.
| @@ -0,0 +1 @@ | |||
| src/v0_8 No newline at end of file | |||
There was a problem hiding this comment.
Would it make sense to have an entrypoint in the package.json of the angular renderer to explicitly create a module entrypoint into the v0_8 directory, instead of relying on paths? (that way it could potentially be moved around later, I think?)
We can probably add this later if we need it, though!
There was a problem hiding this comment.
My plan was to have two ways to import this: the default way (@a2ui/angular), and a versioned way (@a2ui/angular/v0_8). In that way, once we have v0.9 up and in use, we can switch the default to 0.9 and someone who wants to stay on 0.8 after that point can still import the 0.8 import.
There was a problem hiding this comment.
But maybe you have a better way to do this than I know about. This is the way I know about. :-)
…lity Reverted the v0_8 Catalog from a Class to an interface to align with its layout on main. Updated Renderer lookup procedures using indexable direct matching so that custom configuration object literal spreads and custom mapping bindings in legacy samples (like rizzcharts) are supported natively without static type assertions. Verified cleanliness on locally compiled app samples.
Description
This PR refactors the existing Angular v0.8 renderer files into a versioned subdirectory (
v0_8/) and creates a secondary entry point.Changes
renderers/angular/v0_8/: Moved existing library components and core renderer source code into versioned node.renderers/angular/v0_8/ng-package.json: Added configuration for compiled subpath exports (@a2ui/angular/v0_8).renderers/angular/src/public-api.ts: Re-routed base client index imports to look up fromv0_8implicitly, preserving default component backward compatibility.Impact & Risks
@a2ui/angulardirectly will continue to use v0.8.Testing
@a2ui/angularbuild compiles accurately with the new modular entry point layouts (dist/v0_8).