How do you handle a basic form submission in React?

Tests declarative form handling via controlled state. Nail it with onSubmit on the form, preventDefault to stop native reload, and state as the single source of truth. Red flag: reading values through refs or querySelector.
What's really being asked
Declarative versus imperative UI patterns. The interviewer wants to see that you do not treat React like jQuery. Specifically, they are checking that you know forms should be controlled components where React state is the source of truth, that you understand the synthetic event system including why preventDefault is necessary, and that you access data through state rather than the DOM. Even at a senior level, this question filters for engineers who default to React idioms.
The full answer
First, attach the onSubmit handler to the form tag rather than an onClick on the button, which preserves semantic behavior and accessibility. Second, call event.preventDefault inside the handler to stop the browser's default form submission behavior, which would otherwise trigger a full page reload. Third, use controlled inputs by binding each input's value to a useState variable and updating it via an onChange handler so that React state always mirrors the UI. Fourth, on submission, read the values directly from state, not from the DOM nodes. Fifth, mention handling async submission states such as loading, success, and error to demonstrate state-driven UI thinking.
The mistakes people make
Reaching into the DOM with document.querySelector or useRef to read input values during submission. This signals an imperative mindset and bypasses React's rendering cycle. Another red flag is forgetting to call preventDefault and being unable to explain why the page refreshes. Some candidates attach onClick to the submit button instead of onSubmit to the form, which breaks keyboard submission and accessibility. Finally, treating the event object as if it persists after the handler ends without understanding React's SyntheticEvent pooling can reveal gaps in event handling knowledge.
What usually comes next
How would you handle validation? The interviewer may ask whether you validate on change, on blur, or on submit. They might also ask how to handle uncontrolled forms with useRef and when that pattern is justified, such as integrating with non-React code or handling file inputs. Another common pivot is asking how you would prevent double submissions while an async request is in flight, or how to reset the form after success.
A concrete example
Imagine a login form with email and password fields. You create two useState hooks, email and password. Each input has value={email} and onChange={e => setEmail(e.target.value)}. The form tag has onSubmit={handleSubmit}. Inside handleSubmit, you write e.preventDefault(), then pass email and password to an API call. While the API call is pending, you set an isSubmitting state to true and disable the button. If the API returns an error, you store it in an error state and display it below the form. If it succeeds, you clear the fields by calling setEmail and setPassword with empty strings. This keeps every piece of data in React state and every UI change driven by that state.
Interview question
Which set of practices best represents the idiomatic React approach when building a basic controlled form that submits without reloading the page?
- a.Attach onSubmit to the form, call preventDefault, and read the input values from useRef during submission.
- b.Bind inputs to useState, attach onSubmit to the form, and let the browser's default POST behavior handle the submission.
- c.Attach onSubmit to the form, call preventDefault, bind each input to useState, and read the values from state in the handler.Correct
- d.Attach onClick to the submit button, store values in useState, and call preventDefault in the button's handler.
Why? this is the answer
Option C is correct because it combines semantic onSubmit for accessibility, preventDefault to stop page reload, and controlled state as the single source of truth. Option A is tempting because useRef offers direct DOM access, but that signals an imperative jQuery-like mindset that bypasses React's rendering cycle.
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.
We are hiring for this. Open roles that interview on react — each one lists the topics its interview covers.
See open roles