solidjs / solid / 36285537802

74%

main: 89%

push

github

fix(signals): keep a chained optimistic write back to the base's previous value (#3674)

* fix(signals): chained optimistic write to base value is kept (#3672)

A chained optimistic store (`createOptimisticStore(base)` over a
`createStore`) serves the base's live value; its own nodes are links whose
`_value` is never served and never updated when the base commits. The
engine's no-op check in optimisticWrite compared the draft's write against
that stale `_value`, so once a first action had been confirmed in the base,
a second action writing the key back to its earlier value (position 1 then
0), re-adding a key the base had deleted, or popping a row the base had
appended emitted no override while the action's other writes showed.

notifyOptimisticWrites now syncs a chained node that carries no active
override to the visible committed value right before the engine write, on
the value, presence and length emits alike. Non-chained families are
untouched; the optimistic module is tree-shakeable, and every size scenario
stays under its cap.

* fix: address review findings

The optimistic add and delete branches sync a chained node's `_value` to
the unwrapped raw of the inner store's child, not its proxy, so the
settle-time revert compare against the override's raw no longer notifies
readers of a row that was deleted and re-added in one action.

The add and delete branches read `old[key]` once per key instead of
running a chained backing's get trap twice.

The rules index lists optimistic.ts among §7b's citations, which the
`emit` comment's citation had left stale.

* fix(signals): chained optimistic revert compares against the base's live value (#3672)

The write side (previous commits) handed optimisticWrite's no-op check the
visible committed value. The revert consulted the same link `_value`:
resolveOptimisticNodes decides whether to notify by comparing the override
against `_value`, and a chained node's `_value` is never served, so it only
ever held the ... (continued)

625 of 914 branches covered (68.38%)

Branch coverage included in aggregate %.

922 of 1183 relevant lines covered (77.94%)

27.19 hits per line