A detail panel keeps the previous record's unsaved edits when a new record is selected; how does changing its key fix that, and what does it cost?

## Why the stale draft is the default, not a bug in the runtime Identity in a component tree is decided by the same pairing step that matches list children: for a child at a given position, is this the same child as last time? A detail panel rendered in one place, with only its inputs changing, is the same child every time. So the runtime pairs it with its existing instance and updates it: inputs are refreshed and the output is recomputed from them. What is *not* recomputed is everything the instance owns independently of its inputs: - state it initialised once — a draft copy of the record, an edit-mode flag, which tab or section is open; - host-node state the runtime never wrote — an uncontrolled field's current text, focus and caret, a scroll offset; - derived values it computed at creation and has not recomputed since; - pending work it started for the previous record — an in-flight save whose response is about to arrive. That is the leak: the record changed, the panel did not. ## The key as a deliberate discard Because identity is decided by the pairing, an author can change identity on purpose. Give the panel a key derived from the selected record's id and a new selection produces a child whose key the runtime has never seen. Its response is not a patch: 1. the previous instance is treated as gone — its teardown runs and its host nodes are removed; 2. a new instance is built for the new key, initialising its state from scratch; 3. its children are built too, since the whole subtree below the keyed element is new. This is why the technique is reliable. You are not enumerating the fields that must reset; you are declaring that a different record means a different panel, and every piece of per-record state is covered by construction — including state added to a child six months from now. ## What it costs | Concern | Remount by changing the key | Explicit reset when the record changes | |---|---|---| | Coverage | total: all state below the key, present and future | only what you remembered to clear | | Host nodes | destroyed and recreated | kept | | Focus and caret | lost | kept | | Scroll position inside the subtree | lost | kept | | Entry animations | replay for the whole subtree | do not replay | | Children's setup work | runs again, including subscriptions and requests they own | runs only if you trigger it | | Cost profile | scales with the size of the subtree | proportional to what you reset | | Maintenance | one expression | rots as fields and children are added | The honest summary: remounting is correct-by-construction and blunt; an explicit reset is surgical and easy to forget. Neither is the right answer everywhere. ## Choosing, and narrowing the boundary The decisive question is *how much of the subtree is genuinely per-record?* - If everything below the panel belongs to the record, remount by key. It is the smallest expression of the intent and it cannot be partially applied. - If some state must survive the selection change — a scroll container, a collapsed sidebar, an expensive cached list, a filter the user set — it must not live below the keyed element. Lift it above the boundary, or hold it in a store outside the component tree. - If only one or two things are per-record and the rest should persist, reset explicitly: recompute the affected state when the identifying input changes, and keep the nodes. And keep the boundary narrow. Keying the whole page or route by record id works and is the usual overshoot: it discards the shell, the navigation, the scroll position and every cached child along with the form. Put the key on the smallest component that actually owns per-record state. There is a second reason to be careful about *how wide* the keyed element is: a remount replays whatever mount-time work the subtree does. If a child fetches on creation, the remount refetches; if several do, the selection change becomes a burst of requests. That is often acceptable and sometimes exactly what you want — but it should be a decision, not a surprise. ## The same lever under different reactivity models What differs between frameworks is how much a normal input change would have done on its own. In a runtime that re-runs the component function, a plain update already re-executes the body and the stale state is the state it deliberately preserves across runs. In one with fine-grained tracking, an input change updates only the cells that depend on it, and the untouched cells are the stale ones. In a compile-time runtime, the generated update path touches exactly the bindings the compiler linked to the changed input. In all three, changing the key means *this is a different child*, and in all three the answer is a discard-and-build rather than a smarter update — because identity, not the diff, is what you changed. ## The reviewable rule When a component's state is meaningful only for one entity, make that entity part of the component's identity. Then "reset when the record changes" is not a checklist maintained by hand; it is a consequence of what you declared.