🧠 Memoization with React.memo

Why Re-renders Add Up

React follows one simple rule: when a component re-renders — because its state changed or it received new props — all of its children re-render too, by default, whether or not their own data changed. This keeps the UI predictable and correct. React then diffs the result against the previous virtual DOM and only touches the real DOM where something actually differs, so a re-render is not the same as a DOM update.

That distinction matters: rendering (calling your component function) is usually cheap, and React's DOM reconciliation is fast. Problems appear only when the render work itself is expensive or repeated at scale:

• Deep component trees where one top-level state change cascades to hundreds of nodes
• Long lists where changing one item re-runs every item's render function
• Components that do real work while rendering — formatting large datasets, building charts
• High-frequency updates: a counter, a controlled input, an animation loop

In the tree above, a single state change in App asks every descendant to render again — even a product card whose data has not moved. That is exactly the wasted work React.memo is designed to skip.

What Memoization Means

Memoization is a general optimization technique — not React-specific — that caches the result of a function for a given set of inputs, and returns the cached result when the same inputs appear again instead of recomputing. The name comes from "memo," short for memoize, meaning "to remember a result," not "memo" as in a note.

Here is the classic example in plain JavaScript. Computing Fibonacci naively recomputes the same subproblems over and over; a cache remembers each answer:

// Slow: recomputes the same subproblems repeatedly
function fibonacci(n) {
  if (n <= 1) return n;
  return fibonacci(n - 1) + fibonacci(n - 2);
}

// Memoized: each result is computed once, then reused
function makeFib() {
  const cache = new Map();

  function fib(n) {
    if (cache.has(n)) return cache.get(n);       // cache hit
    const value = n <= 1 ? n : fib(n - 1) + fib(n - 2);
    cache.set(n, value);                          // remember it
    return value;
  }
  return fib;
}

const fib = makeFib();
console.log(fib(40)); // computed once
console.log(fib(40)); // instant — served from the cache

React applies the same idea to components. When a component is memoized, React remembers the output it produced for a given set of props. If the next render passes the same props, React reuses the remembered output and skips calling the component function at all.

Introducing React.memo

React.memo is a higher-order component: you pass it a component, and it returns a new memoized component. On each render React compares the new props against the previous props; if they are equal, the memoized component is skipped.

In modern React you usually import memo directly rather than reaching through the React namespace:

import { memo } from 'react';

function Greeting({ name }) {
  console.log('Greeting rendered');
  return <h2>Hello, {name}!</h2>;
}

// Memoized version — skips rendering when `name` is unchanged
const MemoGreeting = memo(Greeting);

export default MemoGreeting;

The memoized component is used exactly like the original. The payoff shows up when a parent re-renders for reasons unrelated to the child. Here a counter re-renders Dashboard constantly, but the expensive chart is spared because its props never change:

import { memo, useState } from 'react';

const ExpensiveChart = memo(function ExpensiveChart({ data, width, height }) {
  console.log('Rendering expensive chart');
  // ...imagine heavy layout/measurement work here...
  return <canvas width={width} height={height} />;
});

function Dashboard({ chartData }) {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>Counter: {count}</p>
      <button onClick={() => setCount(c => c + 1)}>Increment</button>

      {/* Skips re-rendering when only `count` changes */}
      <ExpensiveChart data={chartData} width={800} height={400} />
    </div>
  );
}

When to Reach for It

React.memo is a targeted tool, not a default wrapper for every component. It pays off in a few recognizable situations.

Pure components in long lists

List items are the sweet spot: when one row changes, memoization keeps the other rows from re-rendering. This is where memoization delivers the most measurable win.

const ProductCard = memo(function ProductCard({ product, onAddToCart }) {
  return (
    <div className="product-card">
      <img src={product.image} alt={product.name} />
      <h3>{product.name}</h3>
      <p>${product.price.toFixed(2)}</p>
      <button onClick={() => onAddToCart(product.id)}>Add to Cart</button>
    </div>
  );
});

function ProductList({ products, onAddToCart }) {
  return (
    <div className="product-list">
      {products.map(product => (
        <ProductCard key={product.id} product={product} onAddToCart={onAddToCart} />
      ))}
    </div>
  );
}

Expensive components with stable props

A chart, a map, or a rich editor that sits inside a frequently-updating parent but whose own inputs rarely change is a strong candidate — as we saw with ExpensiveChart above.

When NOT to use it

Memoization is not free — React still has to run the prop comparison on every render. Skip it when:

• The component receives different props nearly every render (e.g. a live clock). The comparison always fails, so you pay the cost with no benefit.
• The component is trivially cheap — a one-line <p>. Re-rendering is cheaper than comparing.
• The component reads context that changes often — it re-renders on context change regardless of memo.

The Shallow-Comparison Trap

By default React.memo does a shallow comparison of props: for each prop it checks Object.is(prev, next). For primitives (strings, numbers, booleans) that works intuitively. For objects, arrays, and functions it compares references, not contents — and this is where most memoization bugs live.

The problem: creating an object, array, or arrow function inside a parent's render produces a brand-new reference every time. To the shallow check, a new reference always looks like a changed prop, so the memoized child re-renders anyway.

Here is the trap in code, and the fix. The parent creates a fresh data object each render, so MemoChild never gets to skip:

import { memo, useMemo, useState } from 'react';

const MemoChild = memo(function Child({ data }) {
  console.log('Child rendered');
  return <p>Value: {data.value}</p>;
});

function BrokenParent() {
  const [count, setCount] = useState(0);
  const data = { value: 42 };            // ❌ new reference every render

  return (
    <>
      <button onClick={() => setCount(c => c + 1)}>Count: {count}</button>
      <MemoChild data={data} />           {/* re-renders on every click */}
    </>
  );
}

function FixedParent() {
  const [count, setCount] = useState(0);
  const data = useMemo(() => ({ value: 42 }), []); // ✅ stable reference

  return (
    <>
      <button onClick={() => setCount(c => c + 1)}>Count: {count}</button>
      <MemoChild data={data} />           {/* now correctly skipped */}
    </>
  );
}

Function props have the same problem: an inline onClick={() => ...} is a new function every render. The fix is useCallback — which is the subject of the next lesson. For now, the key insight is: React.memo only helps if every object, array, and function prop keeps a stable reference between renders.

Custom Comparison Functions

React.memo accepts an optional second argument: a comparison function areEqual(prevProps, nextProps). Return true to skip the render (props considered equal), false to re-render. This lets you compare only the props that actually affect the output.

const UserBadge = memo(
  function UserBadge({ user, lastSeen, theme }) {
    return <span>{user.name}</span>;
  },
  (prev, next) => {
    // Only re-render when the visible identity changes.
    // `lastSeen` and `theme` don't affect this output, so ignore them.
    return prev.user.id === next.user.id && prev.user.name === next.user.name;
  }
);

// ❌ JSON.stringify on every render is slow and fragile
(prev, next) => JSON.stringify(prev) === JSON.stringify(next)

A realistic use is a data-visualization component with many props where only a few are visually relevant:

const DataChart = memo(
  function DataChart({ data, dimensions, options, onPointClick }) {
    return (
      <div style={{ width: dimensions.width, height: dimensions.height }}>
        {/* chart rendering */}
      </div>
    );
  },
  (prev, next) => {
    if (prev.dimensions.width !== next.dimensions.width) return false;
    if (prev.dimensions.height !== next.dimensions.height) return false;
    if (prev.data.length !== next.data.length) return false;
    if (prev.options.color !== next.options.color) return false;
    // onPointClick reference is ignored on purpose (stabilize it with useCallback in the parent)
    return true;
  }
);

Measuring Before Optimizing

Never guess about performance — measure. The React DevTools Profiler records every render, shows why each component rendered, and highlights how long each took. Add memoization only where the Profiler shows a component rendering often and costing real time.

A quick, no-tooling way to see re-renders while developing is a console.log at the top of a component. For finding which prop triggered a render, a small custom hook is invaluable:

import { useRef, useEffect } from 'react';

// Logs exactly which props changed between renders.
function useWhyDidYouUpdate(name, props) {
  const previous = useRef();

  useEffect(() => {
    if (previous.current) {
      const changed = {};
      for (const key of Object.keys({ ...previous.current, ...props })) {
        if (previous.current[key] !== props[key]) {
          changed[key] = { from: previous.current[key], to: props[key] };
        }
      }
      if (Object.keys(changed).length) {
        console.log('[why-did-you-update]', name, changed);
      }
    }
    previous.current = props;
  });
}

function ProfileCard(props) {
  useWhyDidYouUpdate('ProfileCard', props);
  return <div>{/* ... */}</div>;
}

The workflow is always the same loop: profile → find the hotspot → confirm the cause → apply the smallest fix → profile again to verify it worked.

Hands-on Exercise

import { memo, useState } from 'react';

const ProductCard = memo(function ProductCard({ product, onAddToCart }) {
  console.log('Rendering', product.name); // fires for EVERY card on each keystroke
  return (
    <div className="card">
      <h3>{product.name}</h3>
      <button onClick={onAddToCart}>Add to Cart</button>
    </div>
  );
});

function ProductPage({ products }) {
  const [search, setSearch] = useState('');

  const visible = products.filter(p =>
    p.name.toLowerCase().includes(search.toLowerCase())
  );

  return (
    <div>
      <input value={search} onChange={e => setSearch(e.target.value)} />
      {visible.map(product => (
        <ProductCard
          key={product.id}
          product={product}
          onAddToCart={() => console.log('add', product.name)}
        />
      ))}
    </div>
  );
}

import { memo, useCallback, useState } from 'react';

const ProductCard = memo(function ProductCard({ product, onAddToCart }) {
  console.log('Rendering', product.name);
  return (
    <div className="card">
      <h3>{product.name}</h3>
      <button onClick={() => onAddToCart(product.id)}>Add to Cart</button>
    </div>
  );
});

function ProductPage({ products }) {
  const [search, setSearch] = useState('');

  // Stable reference — created once, never changes.
  const handleAddToCart = useCallback((id) => {
    console.log('add', id);
  }, []);

  const visible = products.filter(p =>
    p.name.toLowerCase().includes(search.toLowerCase())
  );

  return (
    <div>
      <input value={search} onChange={e => setSearch(e.target.value)} />
      {visible.map(product => (
        <ProductCard key={product.id} product={product} onAddToCart={handleAddToCart} />
      ))}
    </div>
  );
}

Summary & Quiz

📚 Further Reading

• React docs — memo
• React docs — Render and Commit
• React docs — PureComponent (legacy classes)
• Kent C. Dodds — When to useMemo and useCallback

🚀 What's Next?

You've seen that React.memo is only as good as the stability of the props you feed it. Next we'll dig into the two hooks that provide that stability — useMemo for cached values and useCallback for cached functions.