Render, commit and why components re-render
🎯You'll be able to
Explain when and why a component re-renders, and tell a render from a commit using React Developer Tools.
🏠The everyday picture
A shop updates its price board each morning. The shopkeeper first writes the new prices on a notepad, compares them with the board, then changes only the prices that differ. Nobody repaints the whole board for one changed price.
📘What it really is
-
A render is React calling your component function to work out what the screen should look like. It returns JSX; nothing on screen changes yet.
-
React compares the new result with the previous one, then commits: it changes only the parts of the page (the DOM) that differ.
-
A component re-renders when:
- its own state changes (
setCount,setItems); - its parent re-renders (children re-render by default, even if their props look the same);
-
a context it reads changes.
-
Rendering should be pure: same props and state, same output, no side effects such as fetching data or changing variables outside the component. Side effects belong in event handlers or effects (Lesson 3).
-
In development, React's Strict Mode deliberately renders components twice to help you spot impure code. That double render doesn't happen in production.
📝A worked example
Kirana Express, a grocery ordering app for a neighbourhood store chain in Pune, has this screen:
function ShopPage() {
const [search, setSearch] = useState('');
const [cart, setCart] = useState([]);
return (
<>
<SearchBox value={search} onChange={setSearch} />
<ProductList products={PRODUCTS} search={search} onAdd={p => setCart([...cart, p])} />
<CartBadge count={cart.length} />
</>
);
}
Typing one letter in the search box changes search, so ShopPage re-renders, and so do SearchBox, ProductList and
CartBadge. The React DevTools Profiler shows CartBadge re-rendering on every keystroke, although its count didn't change.
That's normal and cheap here. It only matters if a component is slow, which Lesson 4 deals with.
🌍Where it's used
- Debugging: "why did this update?" is answered with the Profiler's "why did this render" information.
- Design: deciding where state lives decides what re-renders.
- Performance work: finding slow components that re-render too often.
📝Case scenario
A developer adds analytics.track('viewed product') directly in a product card's function body. The dashboard shows each product
"viewed" three or four times per visit. Rendering can happen many times, so tracking inside render counts renders, not views. Moving
the call into an effect takes it out of render, so re-renders stop adding events. An effect still runs again when the card
remounts, and twice on purpose in development under Strict Mode, so decide what counts as one "view" (for example, a product id
once per page visit) and let the tracking code ignore repeats of the same view.
🖱️Try it
Create the Kirana Express product page above with 200 sample products. Open the React DevTools Profiler, record while typing three letters, and write down which components rendered and how long each took.
⚠️Common mistakes
- Thinking a re-render means the page was redrawn. Sign: worrying about every render. Fix: check what the commit changed; most renders change nothing on screen.
- Expecting a changed variable to update the screen. Sign: a counter in a plain variable stays at 0. Fix: keep values that should update the screen in state.
🛠️For your project
Open the starter Kirana Express app with React Developer Tools, add a product to the cart and note which components re-render. You'll use this when building the cart in Project 2.
✅Quick check
Name three things that make a component re-render.
Show the answer
A change in its own state, its parent re-rendering, or a change in a context it reads.
Why should a component's render be pure?
Show the answer
Because React may render it many times, so side effects inside render would repeat unpredictably.