a2ui-project / a2ui-project/a2ui

Define array-index deletion semantics for `updateDataModel`

Đang mở
#1,504 2 bình luận 0 reaction 0 người được giao Xem trên GitHub
component: specification other renderers P2 type: feature/enhancement
Ngôn ngữ chính
TypeScript
Star
16.4k
Fork
1.3k
Merge trung bình
2 ngày 13 giờ
Pull request đã merge (30 ngày)
134

Mô tả

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

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Đánh giá

Issue này chưa được đánh giá.

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.