React re-renders a component when:

1. Its own state updates (setState).
2. A parent re-renders (cascade).
3. A context it subscribes to changes.
4. A subscribed store value changes (Redux, Zustand).

Unnecessary re-renders are when (2), (3), or (4) fire even though the visible output won't change. They're usually cheap individually, but at scale (long lists, deep trees) they add up to noticeable jank.

Common causes

1. Parent re-render cascades

function Parent() {
  const [open, setOpen] = useState(false);
  return (
    <>
      <button onClick={() => setOpen(o => !o)}>Toggle</button>
      <ExpensiveList items={items} />   {/* re-renders even though items didn't change */}
    </>
  );
}

Toggling open re-renders ExpensiveList even though its props are the same.

Fix A: React.memo so it only re-renders when props change (shallow compare):

const ExpensiveList = React.memo(function ExpensiveList({ items }) { … });

Fix B (often better): lift the open state down so the toggle doesn't live in the parent at all.

2. New literal objects/arrays/functions in JSX

<Child style={{ marginTop: 8 }} onClick={() => doStuff()} />

{ marginTop: 8 } and the arrow function are new references on every render → React.memo doesn't help because shallow compare fails.

Fix: hoist or memoize:

const childStyle = { marginTop: 8 };  // outside component if truly constant
const onClick = useCallback(() => doStuff(), []);
<Child style={childStyle} onClick={onClick} />

3. Context with object value

<ThemeContext.Provider value={{ theme, setTheme }}>

{ theme, setTheme } is a new object every render → every consumer re-renders on every parent render.

Fix: useMemo the value:

const value = useMemo(() => ({ theme, setTheme }), [theme]);
<ThemeContext.Provider value={value}>

Better: split into two contexts — one for the value, one for the setter. Setters rarely change identity, values do.

4. State up too high

If the entire app re-renders whenever a search input updates, search state is too high in the tree. Move it into a smaller component that contains only what depends on it.

5. Subscribing to too-wide a slice

const { user, posts, comments } = useSelector(s => s);  // re-renders on any change

Subscribe narrowly:

const user = useSelector(s => s.user);

For multiple values use shallowEqual or split into multiple selectors.

When to optimize

Don't memoize everything by default. useMemo and useCallback cost CPU + memory; React.memo adds a shallow compare on every render. They pay off when the rendered subtree is expensive, not when it's tiny.

Profile first:

• React DevTools → Profiler → record an interaction → look for components that re-render with no visible change.
• Highlight updates: DevTools → Components → ⚙ → Highlight updates when components render. Flashing borders show you exactly what's re-rendering.

If a component renders 100 times in 5 seconds but each render is 0.1ms, don't bother. If it renders 5 times and each is 50ms, fix it.

Patterns that scale

• Compose with children prop instead of rendering inside Provider:

``jsx <Provider>{children}</Provider> `` Children are stable references from the outer render; Provider state updates don't re-render them.

• Pull state down: any state used by only one subtree belongs in that subtree.

• Split context: separate frequently-changing values from rarely-changing setters.

• React.memo on list items + stable keys + memoized item props for big lists.

• External stores (Zustand, Jotai) for fine-grained subscriptions — components subscribe only to the atoms they use.

Things that won't help

• Wrapping primitives in useMemo (useMemo(() => 5, []) is wasteful).
• Memoizing a callback that's only called once.
• React.memo on a component whose props always change.
• Memoizing inside a list item but creating new props in the parent's map().

Mental model

Re-renders aren't the enemy — expensive re-renders are. Make components fast first; memoize as a targeted fix for measured slowness; design state placement to limit the blast radius of updates. React 19's compiler will auto-memoize a lot of this, which makes the manual work less necessary — but understanding why and where matters now and after.