a2ui-project / a2ui-project/a2ui

Define array-index deletion semantics for `updateDataModel`

未关闭
#1,504 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
component: specification other renderers P2 type: feature/enhancement
主要语言
TypeScript
星标
16.4k
派生
1.3k
平均合并
2 天 13 小时
30 天内合并 PR
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 摘要。