React applications feel simple because React hides much of the work required to update the user interface. Behind a button click or a state change, React decides which components need to render, compares the new result with the previous result, and commits only the necessary DOM changes. Understanding this process is extremely important for debugging performance problems and for senior React interviews.
What does rendering mean in React?
Rendering means React calls a component and calculates what the user interface should look like for the current props and state. Rendering does not automatically mean that React will change the browser DOM. React first calculates the next UI representation.
flowchart TD
A[State or props change] --> B[React schedules update]
B --> C[Component renders]
C --> D[React creates next element tree]
D --> E[Reconciliation]
E --> F[Commit required DOM changes]Initial render
When an application starts, React creates the initial component tree. The root component is rendered, its children are evaluated, and React creates the required DOM nodes. This is the first render.
import { createRoot } from "react-dom/client";
import App from "./App";
const root = createRoot(document.getElementById("root"));
root.render(<App />);What causes a re-render?
A component can render again when its state changes, when its parent renders and React evaluates the child again, or when the component receives changed props. Context updates can also cause consumers to render again.
function Counter() {
const [count, setCount] = useState(0);
return (
<button onClick={() => setCount(count + 1)}>
Count: {count}
</button>
);
}Calling setCount schedules an update. React then renders the component again using the new state value.
Render does not mean DOM update
This distinction is one of the most important React concepts. A render is a calculation. During reconciliation React compares the new result with the previous result. If the actual DOM does not need to change, React can leave it untouched.
function Message({ name }) {
return <h2>Hello {name}</h2>;
}If the component renders again with the same resulting element and properties, React may have no DOM work to perform.
Parent and child rendering
When a parent renders, its child components are normally evaluated again as part of that render tree. This does not mean every child necessarily causes a DOM update. React still reconciles the result.
function Parent() {
const [count, setCount] = useState(0);
return (
<>
<button onClick={() => setCount(count + 1)}>
{count}
</button>
<Child />
</>
);
}
function Child() {
console.log("Child rendered");
return <p>Child</p>;
}Here the child can be rendered again when the parent renders. If the child is expensive, techniques such as React.memo may be useful when its props remain unchanged.
Props and object identity
JavaScript objects and functions are compared by reference. Creating a new object during every parent render can therefore make a memoized child appear to have changed props.
const settings = { theme: "dark" };
return <Profile settings={settings} />;If that object is created inside the parent component, a new object reference is created on every render. This becomes important when using memoization.
Reconciliation
Reconciliation is React's process of comparing the previous element tree with the next element tree. React uses the element type, position, props, and keys to determine what can be reused and what needs to change.
flowchart LR
A[Previous tree] --> C[Compare]
B[Next tree] --> C
C --> D[Reuse existing work]
C --> E[Update DOM]
C --> F[Create or remove nodes]Keys and reconciliation
Keys give React a stable identity for items in a list. A good key helps React understand which item was inserted, removed, or moved. Database IDs are generally better keys than array indexes when items can be reordered.
users.map(user => (
<UserRow key={user.id} user={user} />
));A common key mistake
items.map((item, index) => (
<Row key={index} item={item} />
));An index can be acceptable for a truly static list that never changes order. It can cause incorrect state association when items are inserted, deleted, or reordered.
State updates are scheduled
React does not promise that a state setter immediately changes the current variable inside the same render. State values belong to a render. When an update is scheduled, React creates another render with the updated state.
setCount(count + 1);
console.log(count); // still the value from this renderBatching updates
React can batch multiple state updates so that several changes are processed together rather than causing separate visible updates for every setter call. When several updates depend on the previous state, the functional updater form is safer.
setCount(value => value + 1);
setCount(value => value + 1);
setCount(value => value + 1);How to investigate unnecessary rendering
Do not guess about performance. Use React DevTools Profiler and browser performance tools. Look for expensive components, frequent updates, unstable object or function props, and unnecessary state located too high in the component tree.
Common mistakes
- Assuming every render means a DOM update.
- Putting rapidly changing state in a very high parent.
- Using unstable keys for dynamic lists.
- Adding memoization everywhere without measuring.
- Creating new objects and functions unnecessarily when memoized children depend on stable references.
Interview questions
- What is the difference between render and DOM update?
- What causes a React component to render again?
- What is reconciliation?
- Why are keys important?
- Does a parent re-render always mean the DOM changes?
- How would you find unnecessary re-renders?
Key takeaways
- Rendering calculates the next UI.
- Reconciliation compares previous and next element trees.
- DOM updates happen only when React determines they are required.
- Stable keys help React preserve item identity.
- Performance problems should be measured before optimizing.