memo

The problem

A parent re-render re-renders every child. The clock ticks, so the heavy chart redraws even though nothing it shows has changed.

The pattern that fixes it

memo skips a child when its props are shallow-equal to last time. The parent can still tick; the chart only renders when its own props change. MUI memoizes many leaf components the same way.

In plain words

When a component runs again, React also runs every component inside it, even the ones whose inputs did not change. memo is a doorman for one component: "did my props change? No? Then I skip this round."

A manager reprints the whole report whenever any single number changes. memo tells one clerk: only redo your page if your own page changed.

Terms

render

React calls your component function to find out what the screen should look like. It is not the same as painting pixels.

props

The inputs a parent hands to a child, like title="Sales".

shallow compare

React checks each prop with Object.is: same number or text, or the very same object in memory.

Going deeper

How does memo decide?

Before running the child, React compares each new prop to the previous prop with Object.is. All equal means it reuses the last result and skips the function call. One different prop means a normal render. The check is cheap but not free, so it pays off only for components that are expensive to render or render very often.

When memo silently does nothing

A new object, array or function is never Object.is-equal to the old one, even if it holds the same data. <Chart options={{ a: 1 }} /> creates a fresh object on every parent render, so the memo check always fails. Fix it with useMemo for values (next chapter) and useCallback for functions (the one after).

When not to use it

Skip memo on cheap components, on components whose props change almost every time, and when the React Compiler is on, because the compiler adds this kind of memoization automatically. Measure first with the React DevTools Profiler.

Keep learning

• Previous: Keep mounted / exit transition
• Next: useMemo
• Related: useMemo
• Related: useCallback
• Related: Custom hooks
• Related: useEffectEvent
• Related: useTransition
• Related: useDeferredValue

More courses

• Jobs, linked to lessons — Browse jobs where every requirement links to the chapter that teaches it. See how ready you are, how long the gap takes to close, and which listings look stale.
• Match a job post to courses — Paste a job post. Each skill is matched to a track here and put in learning order, foundations first.
• Database in depth — How a query becomes work. Indexes, isolation, locks, and the plans that explain why a page is slow — not an ORM tour.
• System Design — Eight interview case studies, from a flash sale and Tatkal to a live final and a chat model, plus JWT in separate chapters.
• Microservices — Microservice patterns one diagram at a time: how to split a monolith, how services talk, and how data stays consistent without distributed transactions.
• Kafka — A beginner-to-senior path through event logs, reliable delivery, production operations, and disaster recovery.
• Frontend system design — How a UI is sliced when it is a product, not a page: ownership of state, cache, routes, and what happens when the network lies.
• CSS in depth — See the box, then the page. Visual chapters from the box model through Flexbox surprises, Grid, selectors, and units, then backgrounds, shapes, and visual effects, each with a playground.
• Accessibility — HTML labs first, then a full pass of WAI-ARIA 1.3: naming, every state, widget and structure roles, live regions, ariaNotify, and relationships.
• Docker — What an image is, why layers cache, and how containers find each other on a network.
• Redis — Fifteen Redis patterns, one picture each: cache, session, lock, counter, rate limiter, queue, and when Redis is the wrong tool.