In a component framework, what does a two-way binding on a child component's value actually expand to?

**Two-way binding** is the shorthand a framework offers for the most common wiring in any form: a value the caller owns, displayed by a child, edited by the user, written back. Written out longhand it is two ordinary channels and one line of glue. The sugar hides the glue, and every interesting question about it is a question about what the glue was doing. ## What the longhand looks like 1. The caller passes the current value down as an input. The child renders it and treats it as read-only. 2. The user edits. The child does **not** change the value it was given - it raises an output carrying the value it would like instead. 3. The caller's handler receives that value and assigns it to the state it owns. The new value flows back down as the input, and the child re-renders from it. Step 3 is the whole of what the sugar generates. The binding declares "whatever the child asks for, assign it here", and the framework synthesises the handler. ## Ownership does not move The most common misreading is that a two-way binding gives the child write access to the caller's state. It does not. The child still only asks; there is still exactly one writer, and it is still the owner. That is why the loop is stable: the value the child shows always came back down the input, never from its own local edit. A child that keeps its own private copy *and* raises the output has two sources of truth and will eventually show a value the owner rejected. ## The seam you give up | Concern | Explicit input plus handler | Two-way binding | |---|---|---| | Reject or clamp a value | trivial - the handler decides | no handler exists to decide in | | Normalise on the way up | in the handler | must move into the child or a derived layer | | Debounce or batch writes | in the handler | the generated write is immediate | | Write to a derived value | possible via custom logic | the target must be assignable | | Read the wiring | visible at the usage site | implied by a convention | | Boilerplate | one handler per value | one declaration | The seam is worth naming as a design point, not a flaw. Most bound fields genuinely need no vetting, and the sugar removes noise that hides the fields that do. The failure mode is reaching for it uniformly and then discovering that the one field needing a maximum is the one with nowhere to enforce it. ## How reactivity models change the sugar Frameworks differ here, and the difference is worth stating out loud. A runtime that re-invokes the component body on each update usually keeps the pair literal: a value in, an event out, and the write-back is generated glue. A runtime with fine-grained tracking may instead pass a *writable reference* - a single object carrying both read and write - so the child writes through it rather than emitting. A compile-time runtime can recognise the binding in the source and generate either form. The vocabulary and the ergonomics differ; the contract does not. In all three the caller still owns the value, and the child still triggers rather than performs the change. ## When to unfold it - **The value needs validating before it is accepted.** Unfold; the handler is the validation site. - **The caller wants to know the value changed, not just that it is different.** An explicit handler can log, mark dirty or start a save. - **The target is computed.** If the owner's state is derived from something else, there is nothing to assign into. - **Two children bind the same value.** Explicit handlers make the write order and any reconciliation visible. - **The value is expensive to commit.** An immediate generated write can fire per keystroke; a handler can debounce. Conversely, keep the sugar for the dozen plain fields where the write is unconditional - unfolding those buys nothing but volume. ## Interview signal A strong answer names the pair within a sentence, states that ownership stays with the caller, and then reaches for the tradeoff unprompted: the sugar removes the handler, and the handler was where conditions lived. A weak answer describes two-way binding as "the child and parent share the value", which is the mental model that produces flickering fields and values that snap back after being rejected.