a2ui-project / a2ui-project/a2ui

Define array-index deletion semantics for `updateDataModel`

Ouverte
#1,504 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub
component: specification other renderers P2 type: feature/enhancement
Langage dominant
TypeScript
Étoiles
16.4k
Forks
1.3k
Merge moyen
2 j 13 h
PR mergées (30 j)
134

Description

The renderer guide's [JSON Pointer Implementation Rules](https://github.com/google/A2UI/blob/305336f137034922053874471d95614a3831e186/specification/v0_9/docs/renderer_guide.md#L279-L284) specifies the following:

> **Undefined Handling**: Setting an object key to `undefined` removes the key. Setting an array index to `undefined` preserves length but empties the index (sparse array).

@gspencergoog posed some good questions while reviewng a downstream PR implementing this behavior ([flutter/genui#938](https://github.com/flutter/genui/pull/938)):

> When are the nulls in lists cleaned up? And how are they handled when rendering? Wouldn't you expect the list to change size if you remove an entry?

The current semantics are a bit difficult for non-JS renderers. JSON has no `undefined`, JSON arrays have no sparse slots, and many implementation languages do not natively represent array holes. In Dart, for example, a renderer must either invent hole marker or collapse the hole to `null`. Collapsing to`null` is lossy because `null` can also be an intentional list value.

This also means the protocol can create a state that it cannot faithfully serialize as JSON. If a client has `[a, , c]`, what should it send back? `[a, null, c]` changes the meaning.

As far as I can tell, once a list accumulates holes, the only protocol-level way for the server to compact it is to overwrite the entire list.

## Suggestion

Define deletion of an array index as a compacting remove/splice operation. For example, deleting `/items/1` from `[a, b, c]` should produce `[a, c]`.

The main downside is index shifting. After removing `/items/1`, what was previously `/items/2` becomes `/items/1`. The spec should therefore also state that implementations must notify/rebind the parent list and affected descendant paths, not only the deleted path.

Other alternatives:

1. Keep sparse semantics, but explicitly define a protocol-level representation for holes that is distinct from `null`, including how that state is serialized.
2. Add separate operations for "clear this slot" and "remove this item".

P.S.: somewhat related: #1499

Guide de contribution

Ouvrir le guide de contribution

Évaluation

Cette issue n'a pas encore été évaluée.

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.