A binding writes a text field into a numeric model field: what coercion runs each way, and what does clearing the field produce?
answer
- controls speak strings, models speak types
- a pair: parse in, format out
- empty string is not zero
- half-typed values have no type yet
- round trip must be the identity
basics
~10 sThe control hands over a string, so the binding parses it into the model's type on the way in and formats it back for display. Clearing the field is where empty silently becomes zero.
solid answer
~50 sA text-like control's value is **always a string**, whatever the field claims to hold, so a binding onto a typed model field owns a **pair of conversions**: parse on the way in, format back out for display. Every hazard lives in that pair. An emptied field hands over an empty string, and a loose numeric conversion maps that to `0`, so absent becomes a real value — model empty as `null` and parse explicitly. Mid-typing states like `-` or `1.` are not numbers yet, so a binding that parses and writes back on every keystroke destroys them. Long digit strings beyond the safe integer range round silently, which is why money stays a string or a decimal type. And because the formatter writes back, a round trip can rewrite what the user typed. Keep the raw string as the edit buffer and coerce at commit.
go deeper
Remember that a text-like control's value is a string, so something must convert it, and that an empty field is not the number zero.
Explain the parse-and-format pair, where each runs, and name the classic failures: empty becoming zero, half-typed values destroyed by writing back, precision lost on long numbers.
Demonstrate the working shape — a raw edit buffer, a separate typed value, a third state for unparseable input — and say which values you refuse to coerce at all, such as money and long identifiers.
Decide who owns coercion across the codebase: a field component that emits typed values or a form layer that parses. State the rule once, because the mixed version is what produces silent zeros.
## Strings in, typed values out A control does not hand a framework the type you wish it had. A text-like control exposes a **string**; a file control exposes a list of file handles; a checkbox exposes a boolean from its checked state, not from its value; a multiple select exposes a list of chosen values; a rich editor exposes a tree of nodes. The model, meanwhile, declares a type: a number, a boolean, a date, a set of selections. So a binding onto a typed field owns a **conversion pair**: 1. **Parse** — turn what the control gave you into the model's type when the source event fires. 2. **Format** — turn the model's value back into what the control can display when the model changes. Almost every surprising form bug in this area is one of those two steps being implicit. ## The hazards, in the order they bite - **Empty is not zero.** An emptied field hands over the empty string. The host language's *loose* numeric conversion maps that to `0`; a strict parse yields a not-a-number sentinel. Neither is what the user meant, which was **nothing**. A quantity that silently becomes `0`, a discount that becomes `0`, an optional score that becomes `0` — all the same defect. Model the field as *value or null* and decide deliberately. - **Half-typed values are not values.** `-`, `1.`, `0.` and `1e` are legitimate intermediate states of someone typing a number and have no numeric meaning. Coerce on every keystroke and the formatter writes the parsed value back, deleting the minus sign or the decimal point the user just pressed. This is why a numeric binding usually keeps the **raw string as the edit buffer** and parses at commit — or parses per keystroke but only formats back when the field is not focused. - **Precision is lost quietly.** A long identifier or an amount in minor units can exceed the safe integer range of a binary floating-point number, and the conversion rounds without complaint. Currency in fractional units cannot be represented exactly at all. Keep such values as strings or a decimal type end to end and let the binding be a string binding. - **A round trip is not the identity.** `format(parse(text))` may differ from `text`: leading zeros gone, a trailing zero added or removed, an exponent form, a grouping separator inserted, a comma decimal separator turned into a dot. Anything the formatter rewrites, the user sees rewritten under the caret. - **Dates carry an implicit zone.** A date control's string is a plain calendar date. Parsing it into an instant attaches a time and a zone, and formatting it back may land a day earlier or later. Bind the calendar date as a date, and convert to an instant once, at the boundary that genuinely needs one. - **Booleans and lists.** A string of `false` is not falsy, a checkbox's submitted value is not its state, and a multi-select hands over a list whose order is the option order, not the click order — coerce to a set if the model declares one. | Control hands over | Model declares | The trap | |---|---|---| | empty string | number | loose conversion yields zero, not absent | | `1.` mid-typing | number | parse-and-write-back eats the separator | | a 19-digit string | number | silent rounding past the safe integer range | | plain calendar date | instant | implicit zone shifts the day | | list of chosen values | set | duplicates and order assumptions | ## The shape that works 1. Give the field an **edit buffer**: the raw string the user is manipulating, which is also what gets rendered while the field has focus. 2. Parse into the typed model value on the source event, and keep a **third state** for *present but not yet parseable* rather than pretending it is zero or throwing. 3. Format back into the control only when the model changes for a reason other than this user's edit, or when the field loses focus — that is what stops the formatter from fighting the typist. 4. Make the pair **round-trippable by design**: `parse(format(value))` must equal `value`, and document the one direction that is allowed to normalise. ## Reactivity models change the pressure, not the rule A runtime that re-asserts the bound value downward on every render formats on every keystroke, so an aggressive formatter is immediately visible as fighting the user. A runtime with fine-grained tracking writes back only when the model value actually changes, which hides the same defect until the parse produces a *different* value from the text — and then it appears as one sudden rewrite. The conversion pair is the fix in both cases; only the symptom differs. Whose job is the conversion is worth settling explicitly: a shared field component that parses internally and emits a typed value is a different contract from one that emits the raw string and leaves parsing to the form. Either is defensible; having both in one codebase is where the silent zeros come from.
- How do you represent a numeric field the user has emptied?As `null` or absent in the model, distinct from `0`, and distinct again from a value that is present but not yet parseable. Coercing empty to zero makes a cleared field indistinguishable from a deliberate zero, which changes what the server stores and what any rule downstream sees.
- Why keep an amount of money as a string in the model even when the field looks numeric?Because a binary floating-point number cannot represent most fractional decimal amounts exactly, and long minor-unit integers can exceed the safe integer range. Binding the string and converting once at a boundary that uses a decimal type keeps the value the user typed intact through the round trip.
- A formatter inserts grouping separators as the user types and the field becomes unusable. What is the minimal fix?Stop writing back into the control while it has focus. Render the raw edit buffer during editing and apply the formatter on commit or on focus loss. The parse can still run per keystroke for anything that needs the typed value; only the downward format has to wait.
saying these in an interview costs you the question
- Says an emptied numeric field arrives as zero and that is fine
- Coerces on every keystroke and wonders why the decimal point vanishes
- Assumes the control exposes a number because the field looks numeric
- Keeps currency as a floating-point number in the model
- Treats format and parse as independent, so the round trip rewrites the input
- Parses a plain calendar date into an instant without deciding the zone