When a list matched by position has a middle item removed, which per-item state ends up on the wrong row and why?

## The trace, step by step Take a list rendered as `[A, B, C, D]`, one component instance per item, matched by position because no key was supplied. Each row holds something of its own: a checkbox, an open/closed toggle, a text field the framework does not control, or simply focus. Now `B` is removed, so the new description is `[A, C, D]`. | Slot | Old occupant | New data | What the runtime does | |---|---|---|---| | 1 | `A` | `A` | pairs them, refreshes inputs — correct | | 2 | `B` | `C` | pairs them: `B`'s instance now renders `C`, keeping `B`'s own state | | 3 | `C` | `D` | pairs them: `C`'s instance now renders `D`, keeping `C`'s own state | | 4 | `D` | — | no new child at this slot, so `D`'s instance is destroyed | The counter-intuitive part is the last line. Nothing belonging to `B` was thrown away; `B`'s *data* left, but its instance stayed and was handed `C`'s data. The instance destroyed is `D`'s — the one at the end. If a user had ticked `D`'s checkbox and typed into `D`'s field, that is what vanishes, while `B`'s tick appears to have moved down onto `C`. ## Why the inputs look right and the state does not A paired instance is updated, not rebuilt. Everything it renders **from its inputs** is recomputed, so the row's title, its badge and its formatted date all switch to the new item immediately — which is exactly why the bug is so hard to see. What is not recomputed stays: - **the instance's own state** — a checked box, an expanded section, an edit-in-progress flag, a locally sorted order; - **host-node state the runtime never wrote** — focus, the text caret and selection, an uncontrolled field's current text, a scroll offset inside the row, a media element's playback position; - **a running animation or transition** on that node, which continues from wherever it was; - **handles other code holds** to that node, and any observer attached to it; - **work the instance started** — an in-flight request or a timer whose result will land on the wrong item. So the symptom is not "state is lost". It is "state belongs to a position instead of an item": the wrong row looks selected, focus jumps to a neighbour mid-typing, an entry animation plays on a row that was already there, a save lands on the record beside the one the user edited. ## Why the runtime cannot simply notice This is the part interviewers push on. The runtime is given two lists of descriptions and, without keys, no identities. From its side, `[A, C, D]` after `[A, B, C, D]` is *indistinguishable* from a four-item list that became a three-item list whose every item changed its data. Both readings produce the same pairing, and the cheaper reading — update in place, drop the surplus at the end — is the one it takes. The information needed to prefer the other reading is precisely what a key supplies. This also explains why an **index as a key** changes nothing about the bug. The index *is* the position, so keys `0, 1, 2, 3` are compared against `0, 1, 2` and pair slot to slot exactly as before. Its one real effect is social: in a framework that warns on a missing key, an index silences the warning, converting a visible smell into a silent bug. ## How the symptom varies by mutation 1. **Append or remove at the end.** No misalignment: the shifted region is empty. Positional matching is correct here, which is why lists that only grow at the end can run for years without anyone noticing the missing key. 2. **Insert or remove in the middle, or prepend.** Every row from that point on is off by one, and one instance at the end is created or destroyed. This is the classic reproduction. 3. **Pure reorder.** The instance count never changes, so nothing is created or destroyed at all; each instance simply renders someone else's item with its own leftover state, and no animation or teardown gives the user a clue. 4. **Filtering.** The worst case in practice, because a filter reshapes the list on every keystroke and the misalignment shifts each time. ## When it is not a bug at all If a row holds nothing that must travel — no state of its own, no focusable or editable node, no scroll container, no animation, no handle held elsewhere — positional matching produces a correct screen. It is still doing more host work than a keyed list on a reorder, since it rewrites contents instead of moving nodes, but nothing is wrong. Judging a list by what its rows own, rather than applying a blanket rule, is what separates a memorised answer from an understood one. ## The fix Supply a key from the data — an id that belongs to the item and stays with it across updates, reorders and refetches. Then removing `B` destroys `B`'s instance, and `A`, `C` and `D` keep theirs along with everything attached to them.