When a conditional form field disappears, what are the options for its value, its error and its rule?

## Three decisions, not one When a choice elsewhere in the form hides a field, candidates answer "the value is cleared" and stop. There are three independent questions, and getting any one wrong produces a form that is broken in a way the user cannot diagnose: 1. What happens to the **value**? 2. What happens to the **error** already recorded against it? 3. What happens to the **rule** that produced that error? ## The value: three honest policies | Policy | Payload | If the branch returns | Use when | |---|---|---|---| | Drop | field absent | user retypes from defaults | the value is meaningless off-branch, or must not be stored | | Park | must be stripped explicitly | typing is intact | branches are toggled often, or the field is expensive to re-enter | | Hide but submit | field present | control was never emptied | the value is derived, defaulted, or needed regardless | Some notes that decide the choice in practice: - **Drop** is the safest default for anything the server might act on, because nothing invisible reaches it. - **Park** is the kindest to the user, and is the policy with the leak: if the payload is built by serialising the whole model, a parked value ships. Build the payload from the *active* shape, or strip inactive paths on the way out. - **Hide but submit** is a legitimate policy, not a hack, but it must be deliberate: the reader of the form's code should see that the value is intentionally included. The three are not mutually exclusive across a form — a wizard can park a whole branch while dropping one sensitive field inside it. ## The error does not leave on its own A verdict is stored state keyed by the field's path. Removing the control does not necessarily remove the verdict, and models differ on whether withdrawing a field's registration also clears it. The symptom is distinctive and worth recognising on sight: **the submit button does nothing, no message is visible, and the form reports itself invalid**. The cure is to clear the verdicts for the branch's whole subtree in the same update that flips the branch, by path prefix rather than field by field — a branch can contain a repeating group, and enumerating its fields by hand rots. ## The rule has to become conditional too Clearing an error once is not enough if the rule will produce it again on the next validation pass. A rule attached to a hidden path has to be *inapplicable*, not merely unsatisfied: - express the branch in the rule set itself, so the shape validated depends on the discriminating value; - or gate evaluation on registration, so an unregistered path is skipped; - or validate a **projection** of the model — the active shape only — so inactive paths are never visited. The third is the cleanest because it makes the payload and the validated object the same object. ## What the visible branch does not decide Two things commonly get folded in wrongly. First, **rendering is not the model**: a control that is not drawn says nothing about whether its value exists in the model or in the payload. Second, **cross-branch rules still apply**: a rule comparing a field on the active branch with one elsewhere in the model is unaffected by the branch and must not be silently dropped with it. ## Where reactivity models differ A runtime that re-runs the component function will evaluate the branch condition on every pass, so a value cleared *during* render rather than in an update handler produces a loop or a lost keystroke — the clearing belongs in the transition that changed the choice. A fine-grained runtime tears down only the hidden subtree, which makes "the control is gone" easy to observe but leaves the stored verdict exactly as it was. A compile-time runtime may keep the branch's state alive in the component instance even while its markup is out, which makes park the accidental default. Knowing which default your model has is the difference between a chosen policy and an inherited one. ## Interview shape Name the three decisions, give the three value policies with one sentence each on the payload consequence, then describe the invisible-error symptom and say that the rule must be branch-aware. That answer is complete, and it demonstrates the habit interviewers are actually probing: treating the form as a state model whose shape is data, not as markup that appears and disappears.