How do you decide which source event each field in a shared component library binds on, and what breaks when that policy is inconsistent?

## The decision is a policy, not a per-field taste Every bound field answers one question: *at which moment does the model become the truth about this control?* Answer it separately in twenty components and the form as a whole has no answer. So the artefact you actually owe the team is a **policy**: a default source event, an enumerated list of exceptions with reasons, and an explicit way to override. ## What each source buys and costs | Dimension | Per-edit source | Commit source | |---|---|---| | Model freshness | matches the screen continuously | lags while the field has focus | | Per-keystroke features | counters, live filters, as-you-type formatting | impossible without a second listener | | Conversion safety | must tolerate half-typed input | parses only deliberate values | | Display formatting | fights the typist unless write-back is held | applies naturally at commit | | Write cost | one write per character | one write per edit session | | Submit path | reads the model safely | must flush the focused field or read the controls | ## How to choose per field 1. **Does anything on screen derive from the value while typing?** A remaining-characters count, a live result list, a strength meter, a submit button that enables on the first character — if yes, per-edit, and the debate is over. 2. **Is the displayed value reformatted from the model?** Amounts with separators, masked identifiers, normalised casing — prefer commit, or per-edit parsing with the downward write held until focus leaves. 3. **Is the conversion lossy on intermediate input?** Anything where `-` or `1.` is a legal thing to be halfway through typing argues for commit, or for keeping the raw string as the edit buffer. 4. **What does one write cost here?** A write that triggers a large recompute or an outbound request per character is a reason to commit, not a reason to add a timer inside a field component. 5. **Does this field feed submission directly?** Then either bind per-edit or make the submit path responsible for flushing it — and say which, in writing. What is *not* part of this decision: **when a rule judges the value**, which is a separate timing question, and **who owns the value** at all. Conflating the three is how a field component ends up with a single option that secretly changes all three behaviours. ## What inconsistency actually costs - **No single truthful moment.** Some fields are current and some are one edit behind, and which is which depends on where focus happens to be. Every reader of the model inherits that uncertainty. - **A submit path full of special cases.** Flush this field, read that control, trust the third — and the rule is carried in someone's head rather than in the code. - **The same bug, re-fixed.** The last-edit-missing defect gets a local patch per form instead of one policy change. - **Cross-field derived values that disagree.** Two inputs of one computed total commit at different moments, so the total is briefly wrong in a way that is reproducible but never quite the same twice. - **Test and automation cost.** Anything driving a field has to know which event that field listens to, so a helper that works for one component silently does nothing for another. (How a test drives a binding belongs to the testing topic; the point here is that an inconsistent policy is what makes it hard.) - **Analytics and undo granularity** differ per field for no product reason. ## Making submission safe regardless of the policy Whatever the policy, submission should not depend on remembering it: 1. **Flush before read** — commit the focused field explicitly as the first step of the submit handler. 2. **Or read the controls** — assemble the payload from the live form (`FormData` over the form element) so the model's lag cannot matter, accepting that coercion moves to that layer. 3. **Or require per-edit binding** for every field whose value is submitted, and make the exceptions the fields that are *not* submitted. All three are defensible; what is not defensible is having no stated answer, because then each form gets whichever one its author remembered. ## Cost is model-dependent, so do not import someone else's rule In a runtime that **re-runs the component function** on each state write, a per-keystroke binding re-runs that function and reconciles its subtree per character, so teams there develop strong habits about commit sources and memoisation. In a runtime with **fine-grained tracking**, the same keystroke updates the one dependency that reads the value, and the habit looks like superstition. A **compile-time** runtime generates direct updates and lands nearer the second. Take the reasoning, not the rule: measure a realistic field count on a realistic device before declaring per-keystroke binding too expensive. ## What to say when asked Lead with the policy framing: a declared default, exceptions with reasons, an explicit override, and a documented owner for conversion. Then name the failure the policy prevents — a form with no single moment when the model is true — and the submission guarantee that makes the choice safe either way. That is the difference between an opinion about keystrokes and a contract a team can hold.