Validation Timing & Rules

Validation has two separate questions hiding inside it: **when does the rule run**, and **when may its verdict be shown**. This item is about the first, and about the feel each choice produces. A rule here means any check a framework runs over a field's current value - a required check, a length or format check, a comparison with another field - independent of anything the host platform does on its own. ## The four moments - **On submit.** Every field's rule runs once, when the user tries to send the form. Nothing interrupts typing, and the form never accuses a value the user has not finished entering. The cost is that the whole verdict arrives at once, at the least convenient moment, often as several messages the user must now hunt down. - **On blur (the field loses focus).** The rule for that one field runs when the user leaves it. Leaving a field is the user's own signal that they consider it finished, so the verdict reads as fair. Feedback is scoped to one field at a time, and the user is corrected while the field is still fresh in mind. - **On change (every value change).** The rule runs on each edit. Feedback is instant, which suits values judged progressively - a strength meter, a character counter, a slug preview. It is a poor default for format rules, because a partly typed value is legitimately not yet valid: an email address is invalid at every keystroke until it is not. - **On change only after a failed submit.** Rules run silently, or not at all, until the first submit attempt fails. From then on, the fields that failed re-check on every change, so a standing error can disappear on the keystroke that repairs it. The shorthand is **reward early, punish late**: be quick to clear an error, slow to raise one. | Timing | When the rule runs | How it feels | |---|---|---| | On submit | Once for every field, on the submit attempt | Calm while typing; a pile of errors at the end | | On blur | For one field, when it loses focus | Per-field feedback at a natural pause | | On change | On every value change | Immediate, but nags at half-typed values | | On change after a failed submit | Silently at submit, then per change for failing fields | Forgiving early, precise once something is wrong | ## Running a rule is not the same as showing its verdict A framework may compute a verdict long before it is allowed to display one. A required rule over an empty field is already failing on page load, yet a form that shows that error immediately looks broken - the user has not done anything wrong yet. So forms keep per-field bookkeeping (a visited or touched flag, a changed or dirty flag, a submit-attempted flag) and use it to gate **display**, while the rule itself may run as often as is cheap. Treating the two as one thing is the most common mistake in this area: people avoid running rules early because they think running implies showing. ## Choosing per field, not per form The timing is usually a per-field decision, driven by how expensive the value is to get right: 1. **Free-form text with a format** - blur, then per change once it has failed. Judging mid-word is unfair. 2. **Constrained pickers and toggles** - on change is fine, because every value is complete by construction. 3. **Values a human must compose over several keystrokes** (passwords, card numbers, long codes) - a live indicator may run on change while the hard error still waits for blur or submit. 4. **Rules that cost something** - a check that calls a server, or that walks a large structure, should not run on every keystroke; it needs debouncing and a pending state of its own. ## What each choice costs - Per-change rules run orders of magnitude more often than per-blur rules. On a runtime that re-runs the component function per state write, a rule attached to that path runs on the same cadence; on one with fine-grained tracking, only the subscribers of that value re-run - but the rule itself still executes per change either way. - Submit-only validation makes the form cheap and predictable, and is often the right default on a long form where the user wants to type uninterrupted. - A form that mixes strategies must still produce one coherent story at submit: the submit path re-runs everything, because a field the user never visited has no verdict yet. - Where the host platform performs its own submit-time checking, a form that takes validation over must also take over the moment of refusal, or the two can disagree about whether the submission proceeds. The practical default most design systems land on: validate on blur, re-validate on change once a field has an error, and always re-validate everything at submit.