Skip to content
tezvyn:

Explain controlled vs uncontrolled React form inputs and trade-offs

Source: react.devEasyHow cards are made

Explain controlled vs uncontrolled React form inputs and trade-offs

Tests state versus DOM ownership. Controlled inputs bind to React state via onChange; uncontrolled inputs read from DOM via refs. Trade-offs: reactivity, validation, complexity. Red flag: saying uncontrolled is easier while ignoring lost live validation.

What's really being asked

Whether you understand React's core philosophy of declarative UI driven by state versus imperative DOM manipulation. The interviewer wants to see that you recognize React re-renders based on state changes, so an input whose value lives only in the DOM is invisible to React's rendering logic until you explicitly pull it out.

The full answer

Four things in order. First, the definition of a controlled component: the input value is bound to a React state variable via the value prop, and every keystroke flows through an onChange handler that calls a state setter, making React the single source of truth. Second, the definition of an uncontrolled component: the input manages its own value internally using the DOM, and you access it only when needed via a ref or a form submit event, similar to traditional HTML forms. Third, the trade-offs in concrete terms: controlled gives you instant validation, the ability to transform input, and conditional UI that reacts to every character, but it costs extra state variables and re-renders; uncontrolled minimizes boilerplate for simple forms but breaks real-time reactivity, makes cross-field validation harder, and can create stale UI because React does not know the value changed. Fourth, when to pick each: controlled for dynamic forms, wizards, or any input that drives other UI; uncontrolled for file inputs, integrating non-React widgets, or truly static simple forms.

The mistakes people make

Saying uncontrolled is always easier or more performant because it avoids re-renders. This misses that React re-renders are cheap and that losing synchronization with the DOM causes more debugging pain than the extra state overhead. Another red flag is claiming controlled components require useState for every input; a great candidate mentions batching, form libraries, or reducers for scaling. Finally, do not say refs are forbidden in React; they are a valid escape hatch, just not the default for form data.

What usually comes next

How would you handle a form with fifty controlled inputs without fifty useState calls? The expected direction is using a single state object, a reducer, or a form library like React Hook Form. Another follow-up: how do you reset an uncontrolled input? The answer is manipulating the DOM node directly through a ref, which highlights why React prefers state. They may also ask about file inputs, which must be uncontrolled because their value property is read-only, making them a canonical exception.

A concrete example

Imagine a credit-card entry form. Controlled: you store cardNumber in state, onChange strips spaces and validates length in real time, and a disabled prop on the submit button reads state to enforce the form is complete. Uncontrolled: you add a ref to the input, the user types freely, and on submit you read ref.current.value once; you cannot disable the submit button based on partial input because React has no visibility into the keystrokes.

Interview question

Which statement correctly describes a trade-off of uncontrolled React inputs?

  • a.They require useState for every field but simplify cross-field validation
  • b.They avoid re-renders but hide the value from React until explicitly readCorrect
  • c.They bind to state via onChange to keep React in sync with the DOM
  • d.They read from the DOM via refs and enable live validation and reactive UI
Why?

Uncontrolled inputs store value in the DOM, so React cannot react to changes until the value is explicitly read from a ref, which sacrifices live validation for less boilerplate. Distractor B is tempting because refs are indeed used with uncontrolled inputs, but live validation is impossible because React has no visibility into the keystrokes.

Just read this? Test yourself on what you have been reading.

Read the original → react.dev

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on react — each one lists the topics its interview covers.

See open roles