A React sign-up form has grown to a dozen inputs, each with its own useState call. What do you gain and what do you give up by collapsing them into a single state object updated by one generic change handler?

## The two shapes A form's values can live as one `useState` per field, or as one `useState` holding an object: ```jsx // per-field const [email, setEmail] = useState(''); const [password, setPassword] = useState(''); // one object const [values, setValues] = useState({ email: '', password: '' }); ``` Both are idiomatic React. The choice is about how much of the form you need to move around as a single thing, not about which one React prefers. ## What the object shape buys The first win is the generic handler. Give every input a `name` that matches a key, and one function serves the whole form: ```jsx function handleChange(e) { const { name, value, type, checked } = e.target; setValues(prev => ({ ...prev, [name]: type === 'checkbox' ? checked : value })); } ``` Adding a field becomes adding one input and one key, not one `useState`, one handler and one prop. The second win is unit operations. Resetting is `setValues(initialValues)`. Prefilling from a fetched profile is one `setValues(profile)` instead of a dozen setters that must not drift out of step. Submitting is `JSON.stringify(values)` rather than assembling an object by hand at the call site. Anything that treats the form as one value — a draft saved to storage, a dirty check against the initial object, a validator that needs cross-field rules like "password must match confirmation" — gets simpler, because there is one value to pass. ## What it costs The classic bug is assuming the setter merges. In a class component `this.setState({ email })` shallow-merges into existing state. The `useState` setter does not: whatever you pass **becomes** the state. So `setValues({ email: next })` does not update the email field — it replaces the entire object, and every other key is now `undefined`, which typically shows up as React's controlled-to-uncontrolled warning as inputs receive `undefined`. The spread is mandatory, and it must be inside a functional update (`prev => ...`) if several updates can be queued in the same batch. The spread is also shallow. If the shape nests — `{ address: { city, zip } }` — then `{ ...prev, address: { ...prev.address, city } }` is required at every level, and that nesting is exactly where hand-rolled forms start to feel painful. ## The re-render claim, corrected Candidates often say the object shape "re-renders the whole form on every keystroke" as if the per-field shape did not. If all the state lives in the same component, both shapes re-render that component on any change, and React re-runs its whole JSX either way. The shapes are equivalent here. What genuinely reduces rendering work is *where* the state lives, not how it is packed: state owned by a child field component only re-renders that child. That is a state-placement decision, and it is orthogonal to the object-versus-per-field question. There is one real render difference. React can skip re-rendering when the next state is `Object.is`-equal to the current one, so `setEmail('ada')` when email is already `'ada'` bails out. A spread always produces a fresh object reference, which is never `Object.is`-equal, so the equivalent object update always renders. In a change handler the value has usually changed anyway, so this matters mostly for programmatic writes — restoring a draft, echoing a server response — where you may want to compare before setting. ## Choosing Under about four or five independent fields, per-field state usually reads better: each piece of state is named, its type is obvious, and there is no indirection between an input and its value. Reach for one object when the field count makes the boilerplate the dominant cost, when the form needs reset/prefill/dirty-check as a unit, or when validation is cross-field and wants the whole shape in one place. A third position exists between the two: keep the object, but stop driving it with `useState` and derive the next shape from a reducer, so field updates become named actions. That is the point at which many teams also start asking whether a form library should own the shape entirely — the same forces (many fields, shared validation rules, dirty and touched tracking) push in that direction. ## The tell in an interview Saying "one object, one handler, and remember the setter replaces instead of merging" already puts you ahead of most answers. Adding "and it does not actually change how much re-renders" shows you know why the popular version of the tradeoff is wrong.