In a component framework, what makes a text field's value framework-held rather than element-held?
answer
- one value, two possible owners
- who is the authority between keystrokes
- state renders it, edits write it back
- element-held is read only when asked
- seeding is a separate one-time channel
basics
~20 sA field is framework-held when the component renders its text from state and every edit writes state back, so state is the authority. Element-held means the host element keeps the text and the framework reads it only when needed.
solid answer
~50 sEvery field has one current value, and exactly one side should be its authority. Framework-held (often called *controlled*): the component renders the element with the text held in state, and the change handler writes each edit back into state, so code can read the current value at any moment. Element-held (*uncontrolled*): the framework gives the element an optional starting text, never writes to it again, and reads it back later through a host reference or from the field set gathered at submit. The trade is knowability against cost — a framework-held field pays a state write and an update per keystroke but is always readable; an element-held field costs nothing per keystroke but is opaque until asked. Seeding a starting text does not make the framework the authority; that is a separate channel applied once at creation.
go deeper
Recall the two shapes and their names: value rendered from state plus a change handler that writes it back, versus an element that keeps its own text and is read later. Say which side is the authority.
Explain the per-keystroke round trip and what it costs, and separate the value channel from the one-time initial-value channel. Be able to say what breaks when both sides think they own the value.
Show judgment about which fields on a real screen need per-keystroke knowability and which do not, and describe how you keep prefill, reset and read-back consistent when a codebase contains both kinds.
Frame it as an interface contract for the whole codebase: one default ownership, an explicit exception rule, and a component boundary that keeps the per-keystroke update small enough that the cheap option is rarely needed.
## Two candidate authorities An editable field always has a **current value**, and in a component framework there are only two places that value can really live: in the **component's state**, or in the **host element** the framework created to draw the field. Whichever of the two the rest of the system trusts is the field's **authority**, and naming the authority is the whole of this question. When state is the authority — the *controlled* field — the component renders the element with the text state holds, and the element is re-rendered from state after every edit. When the element is the authority — the *uncontrolled* field — the framework hands it an optional starting text, never writes to it again, and reads the text back later: through a host reference, or from the field set the host collects when the form is submitted. ## The round trip of a single keystroke With a framework-held value, one keystroke is a loop: 1. The user types; the host element updates its own text and reports an input event. 2. The component's handler writes the reported text into state. 3. The state change schedules an update, and the framework renders the element with the new text. 4. The element's text is reconciled against what state says — normally already equal, so nothing visibly moves. That loop is what makes the value **knowable**: at any instant something can read state and know what the field says, so a character counter, a dependent control or a live rule has something to read. It is also what makes the value **fragile**: break step 2 and step 3 writes the old text back over what the user typed. With an element-held value there is no loop. The user types, the element remembers, and nothing else happens until something asks. ## What each choice buys | | Framework-held | Element-held | |---|---|---| | Current value known between keystrokes | yes, it is in state | only by asking the element | | Cost per keystroke | a state write plus an update | none | | Live formatting, counters, dependent fields | natural | needs an extra read | | Ways to fall out of sync | several | few | | Reset and prefill | write state | re-create the field, or write the element | ## Seeding an initial value is not owning it Most frameworks expose two distinct channels: a **value** channel consulted on every render, and an **initial value** channel applied once when the element is created. Feeding the first makes the framework the authority; feeding the second seeds the element and leaves it the authority. Mixing them — seeding *and* rendering a value, or feeding the value channel only when data happens to be present — produces a field with no clear authority, and that ambiguity is behind most reports of a field that will not type or a field that resets on its own. ## One question in four vocabularies The same decision arrives dressed differently depending on the framework: an explicit value plus a change handler; a declarative two-way binding; a form-control object the framework creates and owns; or a plain element the framework never binds to. The first three all make the framework the authority and differ only in how much of the write-back you type yourself; the fourth leaves the element in charge. Engineers who learned one vocabulary often read the others as different features. They are the same two choices, and seeing that is most of the answer. ## Where reactivity models differ The ownership question is identical everywhere; its price is not. A runtime that re-runs a component function on each state write re-runs that component and diffs its output for every character. A runtime with fine-grained tracking updates only the one binding that reads the value. A compile-time runtime generates the write-back from a declaration, so the loop is invisible in the source but still runs. That is why "framework-held fields are expensive" is measurable in some codebases and unnoticeable in others. ## How to choose Ask one question: does anything need this value **before** submit — a live counter, a dependent control, formatting as typed? If yes, the framework should own it. If no, leaving the element in charge is less code, fewer moving parts and no per-keystroke work. Large forms often mix the two deliberately, and that is a design decision rather than a shortcut.
- Does an element-held field mean the framework cannot know the value at all?No — it means the framework does not track it continuously. It can read the element on demand through a host reference, or take the whole field set when the form is submitted. What it loses is knowing the value between those reads, so nothing can react to typing.
- If state is the authority, why does the host element still keep a value of its own?Because the element is what the user actually edits; the host normally maintains its own text. A framework-held field simply overwrites that text from state on each update, so the element's copy is a display rather than a source. That overwrite is exactly what breaks a field whose handler never updates state.
- Is a two-way binding a third option beyond framework-held and element-held?No. A two-way binding is a framework-held field with the write-back generated for you: the declaration expands into rendering the value and updating it on input. The authority is still the state behind the binding, which is why a binding fed a value only sometimes shows the same ambiguity bugs.
Two people keeping the same shopping list on their own sheets: nobody can say what is really on it. Declare one sheet the real list and let the other be a display of it.
saying these in an interview costs you the question
- Thinks the host element stops holding any value once the framework owns it
- Says an element-held field cannot be given an initial value
- Believes rendering a value from state is enough, without writing edits back
- Treats framework-held as the only correct choice for every field
- Calls a two-way binding a third kind of ownership rather than a generated write-back
- Thinks reading the value only at submit is a hack rather than a real ownership choice