Topic

Reacting to input with state

Definition

Controlled inputs receive their displayed value from React state and report edits through event handlers.

In simpler words

State owns the field value, so typing updates state and state updates the input.

Controlled inputs, change events, and form submission.

Open official example (opens in new tab)

After this you can

Build predictable text fields and selects.
Explain the trade-off to a teammate using a small example.
Name at least one common bug pattern for this topic.

Understand Reacting to input with state

Controlled inputs, change events, and form submission.

Start by identifying which value or browser behavior changes. Then describe the UI from that current input instead of editing the DOM as a separate source of truth.

Reacting to input with state in code

const [name, setName] = useState("");
const [error, setError] = useState<string | null>(null);
<input
  value={name}
  onChange={e => setName(e.target.value)}
  onBlur={() => setError(name.trim() ? null : "Required")}
  onFocus={() => setError(null)}
/>;

Read the example from data and control flow to the resulting UI. Keep the component boundary small.

Apply Reacting to input with state

Keep rendering as a calculation. Put user-triggered changes in event handlers, preserve UI memory in state, and reserve external synchronization for Effects or the server-state layer.

Name values by their UI meaning, test the loading and error path when data is remote, and avoid keeping two editable copies of the same value.

Ask before adding code: is this local UI memory, shared client state, or Nest-owned server state?

Where bugs hide

Definition

High-bug areas are places where a small API misuse looks correct but produces stale UI, duplicate work, or silent failures.

In simpler words

Each mistake below shows Wrong vs Right code — compare them side by side.

When something misbehaves, match the symptom to a pattern below before rewriting the feature.

Prefer fixing the ownership or update path over adding another Effect or sync step.

Mistake: value without onChange

// Wrong
<input value={name} />

// Right
<input value={name} onChange={e => setName(e.target.value)} />

Controlled inputs need both value and onChange.

Mistake: Validate email on every keystroke only

// Wrong
onChange={e => {
  setEmail(e.target.value);
  setError(valid(e.target.value) ? null : "bad");
}}

// Right
onChange={e => setEmail(e.target.value)}
onBlur={() => setError(valid(email) ? null : "bad")}

Blur validates the finished edit; change keeps the value.

Mistake: Submit only via button onClick

// Wrong
<form>
  <button type="button" onClick={save}>Save</button>
</form>

// Right
<form onSubmit={e => { e.preventDefault(); save(); }}>
  <button type="submit">Save</button>
</form>

Enter key users need onSubmit.

Live playground

Reacting to input with state sandbox

Change one input at a time and predict the next render.

const [count, setCount] = useState(0);
setCount(c => c + 1);

Keep in mind

Keep the formal definition in mind; it explains which tool belongs where.
Prefer one source of truth over synchronized copies of the same value.
When behavior surprises you, trace: input → update → render → committed UI.
Study the Wrong vs Right examples in “Where bugs hide” before you merge.

Test

Check your understanding

At least 10 questions — mix of concept, syntax, practical, and logic. Score ≥80% (enforced by the API) to save progress.

Checking your session…

15 questions · concept 5 · syntax 3 · practical 4 · logic 3

1. How should a text input usually work in React?

Concept

Read the DOM value only during render with querySelectorSend every keystroke to Nest before renderingStore the value in state and update it from onChangeUse a ref as the only source of truth for controlled display text

2. What is a controlled input?

Syntax

Its value prop is driven by React stateIts defaultValue seeds it once and React ignores later changesIt keeps its value in a ref that React reads during renderIt pushes its value to the server on every keystroke

3. Unchecked checkbox pattern?

Practical

checked={on} onChange={() => setOn(!on)}checked={on} onClick={() => setOn(!on)}defaultChecked={on} onChange={() => setOn(!on)}value={on} onChange={() => setOn(!on)}

4. Why not read input.value in render via DOM?

Logic

The DOM node is not mounted during render, so the read returns nullBreaks declarative flow; use state/refs intentionallyIt is fine as long as you wrap the read in useMemo firstReact clears input.value after every render to enforce purity

5. Debouncing search typing belongs where?

Concept

In the render body, wrapping the fetch in useMemoIn the change handler / effect with cleanup — not Nest on every key necessarilyIn a Nest interceptor that throttles each keystroke server-sideIn a ref updated during render so it never re-runs

6. Submitting a form in React?

Practical

An onClick on the submit button that reads the DOM inputs directlyonSubmit handler calling preventDefault and reading stateA form action attribute pointing at the Nest endpointAn onSubmit handler that returns false instead of calling preventDefault

7. Multiple fields state shape?

Syntax

One object draft or several useStates — keep a single source of truthStore every field in a single ref object and read it during renderMirror each field into both a useState and the URL query stringKeep one useState per field plus a combined object synced by an Effect

8. Disabled save until valid?

Logic

Derive disabled from state validationStore an isDisabled boolean in state and update it in an EffectToggle the disabled attribute directly on the DOM node with a refLet Nest reject invalid submits and skip client-side disabling

9. Uncontrolled input when OK?

Concept

Integrating non-React widgets or one-shot file inputs with refsWhenever you want fewer re-renders on a normal text fieldFor any input whose value must appear elsewhere in the UI liveAs the default for every form field to simplify state

10. Which is wrong for reacting to input?

Practical

Updating local component state in the onChange handlerPutting every keystroke into Nest before the UI can updateDriving the input from a controlled value propRunning validation when the form is submitted

11. Why can’t the user type into this input?

Conceptintermediate

function NameField() {
  const [name, setName] = useState('');
  return <input value={name} />;
}

React inputs are read-only by defaultIt must use useRef instead of useStatevalue is controlled but there is no onChange to update stateThe input needs a name attribute to accept typing

12. What does clicking this checkbox do?

Syntaxintermediate

<input
  type="checkbox"
  checked={on}
  onChange={() => setOn(!on)}
/>

Toggles the on boolean in state and re-rendersNothing — checkboxes ignore onChangeSends the value to Nest automaticallyMutates the DOM without React knowing

13. Why might total become a string like "22"?

Practicaladvanced

<input
  type="number"
  value={qty}
  onChange={(e) => setQty(e.target.value)}
/>
// later: const total = qty * price;

e.target.value is a string; convert with Number() before doing mathnumber inputs already return numbersReact coerces the value automaticallyprice must also be a string

14. What does e.preventDefault() accomplish here?

Logicintermediate

function Form() {
  function onSubmit(e) {
    e.preventDefault();
    create(text);
  }
  return <form onSubmit={onSubmit}>...</form>;
}

Prevents state updatesStops the browser’s full-page form submission so React handles itCancels the create() callDisables validation

15. What bug does this onChange introduce?

Conceptadvanced

const [form, setForm] = useState({ name: '', email: '' });
function onChange(e) {
  setForm({ [e.target.name]: e.target.value });
}

It drops the other fields; spread with ...form firstIt cannot read e.target.nameIt re-renders too rarelyComputed keys are invalid in React

Checking your session…