A component copies an incoming input value into its own state when created; what breaks when the parent later passes a different value?

## Stored versus derived, and where a copy fits Every value a component renders comes from one of three places: state it owns, an input it was handed, or a computation over those. Storing a value is a commitment — you now own it, you must keep it correct, and nothing else may assume it matches anything. Deriving a value commits to nothing: it is recomputed from whatever the current truth is, so it cannot be stale. Copying an input into state looks like storing but is meant as deriving, and that mismatch is the bug. ## Why the copy goes stale An initial value is, by construction, initial. The component is created, the cell is given a starting value taken from the input at that moment, and from then on the cell's only inputs are writes. The parent's later value goes into the input, which the component may not even read any more. Both values are live, both are internally consistent, and the screen shows whichever one the markup names. Runtimes differ in the shape of the trap, not in the trap itself: where a component function re-runs on every write, the initialiser expression is re-evaluated but its result is deliberately discarded after the first run, which is why the code reads as if it should update; where reads are tracked individually, assigning a tracked value into a new state cell copies the value out of tracking, so later changes reach nothing; where the reactive declaration is recognised at compile time, only what is declared derived stays linked, and a plain state declaration seeded from an input is not. ## Symptoms an interviewer will recognise - The component shows correct data the first time and stale data after the parent changes it. - It becomes correct after an unrelated action that happens to recreate the component. - There is a watcher whose whole body copies an input into state. - Two fields must "agree", and a bug report says they sometimes do not. - A list row keeps a neighbour's values after the list is reordered or filtered. ## The four responses, and when each is right | Response | What it means | Right when | |---|---|---| | Do not store it | Render the input, or compute from it | The component only displays or formats the value | | Lift the change | The parent owns the value; the child requests edits | Anyone else needs to see the edit as it happens | | Own a real draft | The child's cell is new state, not a mirror | Edits are provisional until committed, and only this component cares | | Copy in on input change | A watcher writes the input into the cell | Rarely — a last resort, and it needs a rule for conflicts | The last row deserves its bad reputation. Syncing a copy from a watcher means the value is written twice per change, there is a moment where the rendered value is the old one, and two writers now exist: the parent's change and the user's edit. The question "what if the user typed while the parent's value changed?" has no default answer, and code that syncs silently answers it by accident — usually by discarding the user's work. ## When the copy is correct A draft is the honest case. A form that lets the user edit and then save is *supposed* to hold a value that differs from the parent's: that difference is the feature. What makes it correct is that the component is the **owner** of the draft, not a mirror of the input, and that the relationship to the input is stated: 1. The input is the starting point for a new draft, and after that it is not the draft's source. 2. When the input identity changes — a different record is being edited — the draft must start over, either because the instance is replaced or because something resets it deliberately. 3. When the input's value changes for the *same* record, the product has to choose: keep the user's edit, overwrite it, or surface the conflict. Silence here is what produces "my change vanished". ## The general rule Prefer derivation over duplication, and where you must store, be explicit that you own it. The tell you can carry into any codebase: a state cell whose value is supposed to equal something the component already receives is a cache with no invalidation rule, and a cache with no invalidation rule is a stale value waiting for a bug report.