Define component garbage collection behavior and make it easy to implement

[jacobsimionato]

An agent can continually update components on the client, and ideally we would remove unused components, to avoid leaking memory and retaining data that shouldn't be retained.

In v0.8, you could theoretically implement client-side garbage collection, but it would need to be implemented at the specific catalog level and could not be implemented at the framework level. Framework level would be better. The issue is that to garbage collect, you need to understand the graph structure, e.g. the parent-child relationship between components. In the catalog, there was no real structure around what a child property looks like e.g. it's typically just a string field called child, but could also be called imageChild or headerContent etc.

I propose that in v0.9, we define that the client should run garbage collection on the tree after every A2UI Part is processed (which could perform arbitrary atomic operations - see https://github.com/google/A2UI/issues/234). That way, a server can do stuff like atomically restructure the tree to add a new layer without triggering garbage collection. When garbage collection runs, it should remove all components which are not reachable from the root node.

I'm less certain on exactly how to identify orphaned components to garbage collect. I think it should ideally be simple, and not require an entire renderer to be implemented to do this. That way, it's easy for us to do interesting things like have a server-side A2UI accumulator which parses incremental A2UI updates to maintain a mirror of the client state, to use as context etc. Ideally, this could be implemented in a way that is generic to any Catalog.

Orphan Component Identification

Option (A) - child/children name suffix convention

• Require that every single child field ends with the suffix "Child"
• Require every array of children ends with suffix "Children"
• Parser logic in the client scrapes the graph to find child and children IDs to identify orphaned elements

Option (B) - catalog-specific renderer implementation [status quo]

The client renderer marks components as "used" as it renderers. At the end of the render cycles, we can then identify and remove unliked components.

Option (C) - formal schema annotation - [my favourite]

In the Catalog definition, add some identifying flag on child and Children properties. A parser can read the Catalog definition schema to figure out what properties are actually child and Children properties, regardless of name, and then parse the tree.

In v0.9, we formally have a childrenProperty schema, so perhaps client logic could use that to find children for multiple child components. We could also add a child property schema. Then the parser could perhaps find references to these schemas in the catalog definition.