React's Two-Step Update: Render and Commit
React updates the screen in two phases. The "render" phase is React calling your components to calculate the UI. The "commit" phase is when it actually updates the DOM. The footgun is thinking rendering always changes the screen; it's just the prep work.
Why it exists
To provide a predictable and efficient way to translate component state changes into user interface updates. By separating the calculation of the UI (render) from the direct manipulation of the browser's DOM (commit), React can batch changes and avoid unnecessary, slow updates, leading to better performance.
The mental model
Imagine your components are cooks in a kitchen and React is the waiter. A customer's order (an initial load or a state update) is a trigger. The "render" phase is the cooks (your components) preparing the dishes (the UI). The "commit" phase is the waiter (React) comparing the new dishes to what's already on the table and only swapping them out if they're different.
How it works
The process has three steps. First, a render is triggered, either by the app's initial load or a state update. Second, React "renders" by calling your component functions. This is just React executing your code to see what UI it should produce. This process is recursive, moving down the component tree. Third, React "commits" the changes. It takes the output from the render phase, compares it to the current DOM, and applies only the necessary changes. If nothing changed, the commit phase does nothing.
When to use it
This isn't a feature you choose to use; it's the fundamental mechanism of how React works. You trigger this process every time you call a state setter function (like from useState) or when your app first loads. Understanding this process is key to debugging and optimizing your React applications, as it explains why changes aren't always immediate.
When not to use it
You cannot avoid the render and commit phases, but you can get into trouble by misunderstanding them. The most common footgun is assuming that calling a state setter function immediately and synchronously changes the DOM. It does not. It only queues a render. The actual DOM update happens later, after the commit phase, and only if React determines a change is needed.
One canonical example
When an app starts, root.render() triggers the initial render for the entire app. React calls the root component and all its children, building a description of the DOM. It then commits this to the screen. Later, if you click a button that calls setCount(count + 1), you trigger a re-render. React calls your component again, gets the new UI description, sees the count has changed, and during the commit phase, updates only the specific text node in the DOM that displays the count.
Interview question
What is the primary action React takes immediately after a state setter function is called?
- a.It begins the commit phase to apply necessary UI changes.
- b.It directly modifies the browser's DOM to reflect the new state.
- c.It queues a new render pass to calculate the updated UI.Correct
- d.It compares the component's previous output with its new output.
Why? this is the answer
Calling a state setter function does not immediately update the DOM; it only queues a render, which is the first step in the two-phase update process. Option B describes the common 'footgun' misconception, where direct DOM modification happens later in the commit phase, if at all.
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