a2ui-project / a2ui-project/a2ui

Define array-index deletion semantics for `updateDataModel`

オープン
#1,504 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る
component: specification other renderers P2 type: feature/enhancement
主要言語
TypeScript
スター
16.4k
フォーク
1.3k
平均マージ
2日 13時間
マージ済み PR(30日)
134

説明

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

コントリビューションガイド

コントリビューションガイドを開く

評価

この issue はまだ評価されていません。

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。