In a component framework, what makes a text field's value framework-held rather than element-held?

## 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.