Stale useCallback — User A IDs Sent After User B Logs In

Every React developer hits a wall eventually. The app works, the logic is sound, but child components are re-rendering for no apparent reason, expensive calculations are running on every keystroke, and the profiler is showing a wall of orange. The usual suspects? Inline functions and unguarded expensive computations passing straight through to memoized children. useMemo and useCallback are React's built-in escape hatches from this exact problem — but they're also among the most misused hooks in the entire ecosystem.

The core problem both hooks solve is referential instability. In JavaScript, a new function literal or a newly computed object created inside a render cycle gets a brand-new memory address every single time, even if its contents are identical. When you pass that value down as a prop, React.memo and PureComponent see a different reference and trigger a re-render, even though nothing meaningful changed. useMemo caches a computed value between renders. useCallback caches a function definition between renders. Both return the same reference until their dependency array changes.

After reading this article you'll be able to: correctly identify when memoization actually helps versus when it adds overhead with zero gain, confidently explain the difference between useMemo and useCallback at a referential identity level, avoid the three most common production mistakes that turn these hooks into performance liabilities, and write genuinely optimized React component trees that hold up under profiler scrutiny.

Referential Identity — The Root Problem Both Hooks Actually Solve

Before touching either hook, you need a firm grip on why JavaScript's equality model bites React so hard. Primitive values like numbers and strings compare by value. But functions and objects compare by reference — their memory address. Two functions with identical bodies are not equal in JavaScript.

Every time a React component renders, its function body executes top to bottom. Any function or object defined inside that body is born fresh — a new allocation, a new address. That's by design in JavaScript, but it's a silent killer in React's prop-passing model.

React.memo wraps a child component and bails out of re-rendering if its props are shallowly equal to the previous render. Shallow equality means it checks object references, not deep values. So if your parent passes an inline callback or a freshly computed array, React.memo sees a new reference on every parent render and the bail-out never fires. useMemo and useCallback exist specifically to preserve referential identity across renders so that memoized children can actually do their job.

import React, { useState } from 'react';

// This child is wrapped in React.memo — it SHOULD skip re-renders
// if its props haven't changed. But watch what actually happens.
const ProductTag = React.memo(({ label, onRemove }) => {\n  console.log(`ProductTag rendered: \"${label}\"`);\n  return (\n    <span>\n      {label}\n      <button onClick={onRemove}>✕</button>\n    </span>\n  );\n});\n\nexport default function ProductList() {\n  const [cartCount, setCartCount] = useState(0);\n  const [tags] = useState(['React', 'TypeScript', 'Node']);\n\n  // ❌ Problem: this function is recreated on EVERY render of ProductList.\n  // Even though its logic never changes, it gets a fresh memory address\n  // each time cartCount changes. React.memo on ProductTag is useless here.\n  const handleRemove = (tag) => {\n    console.log(`Removing tag: ${tag}`);\n  };\n\n  return (\n    <div>\n      {/* Clicking \"Add to Cart\" triggers a re-render of ProductList.\n          That re-render creates a new handleRemove function.\n          React.memo sees a new prop reference → re-renders ALL ProductTags.\n          Check the console — all three tags log on every cart click. */}\n      <button onClick={() => setCartCount(c => c + 1)}>\n        Add to Cart ({cartCount})\n      </button>\n\n      {tags.map(tag => (\n        <ProductTag\n          key={tag}\n          label={tag}\n          onRemove={() => handleRemove(tag)} // new function on every render\n        />\n      ))}\n    </div>\n  );\n}",
        "output": "// On first render:\nProductTag rendered: \"React\"\nProductTag rendered: \"TypeScript\"\nProductTag rendered: \"Node\"\n\n// After clicking 'Add to Cart':\nProductTag rendered: \"React\"\nProductTag rendered: \"TypeScript\"\nProductTag rendered: \"Node\"\n// ↑ All three re-render even though tags didn't change.\n// React.memo was completely bypassed by the unstable function reference."
      }

useCallback — Stabilising Function References Across Renders

useCallback(fn, deps) returns a memoized version of the function fn. React guarantees it returns the exact same function reference between renders as long as none of the values in the deps array have changed. The moment a dependency changes, useCallback throws away the cached version and stores the new function.

The mental model: useCallback doesn't make your function faster. It makes your function stable. That stability is what lets React.memo on child components actually bail out. Without it, you're memoizing a child but feeding it a moving target.

A critical internal detail: useCallback(fn, deps) is literally identical to useMemo(() => fn, deps). React's source code even shows this — useCallback is just a convenience wrapper. Understanding this equivalence helps you reason about both hooks from first principles rather than memorising two separate mental models.

The dependency array follows the same rules as useEffect. Every value from the component scope that's used inside the callback — props, state, context values, other variables — must be listed. ESLint's exhaustive-deps rule from eslint-plugin-react-hooks is your best friend here; enable it and treat its warnings as errors.

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

const ProductTag = React.memo(({ label, onRemove }) => {\n  // This log will now only fire on initial mount, NOT on cart updates.\n  console.log(`ProductTag rendered: \"${label}\"`);\n  return (\n    <span style={{ marginRight: 8 }}>\n      {label}\n      <button onClick={onRemove}>✕</button>\n    </span>\n  );\n});\n\nexport default function ProductList() {\n  const [cartCount, setCartCount] = useState(0);\n  const [tags, setTags] = useState(['React', 'TypeScript', 'Node']);\n\n  // ✅ useCallback returns the SAME function reference on every render\n  // as long as `tags` (the dependency) hasn't changed.\n  // Now React.memo on ProductTag can actually do its job.\n  const handleRemove = useCallback(\n    (tagToRemove) => {\n      // We reference `setTags` here. The setter from useState is guaranteed\n      // stable by React, so it doesn't need to be in deps.\n      // We use the functional update form to avoid needing `tags` in deps.\n      setTags(currentTags => currentTags.filter(t => t !== tagToRemove));\n    },\n    [] // Empty array: this function never needs to be recreated.\n  );\n\n  return (\n    <div>\n      <button onClick={() => setCartCount(c => c + 1)}>\n        Add to Cart ({cartCount})\n      </button>\n\n      {tags.map(tag => (\n        <ProductTag\n          key={tag}\n          label={tag}\n          // ✅ We still create a new arrow here for the specific tag,\n          // but see the tip below for how to handle this pattern cleanly.\n          onRemove={() => handleRemove(tag)}\n        />\n      ))}\n    </div>\n  );\n}\n\n// ─── Cleaner pattern: pass the raw handler + tag ID as separate props ──────\n// This way React.memo compares (handleRemove === handleRemove) ✅\n// and (tag === tag) ✅ — both stable, no unnecessary renders.\nconst CleanProductTag = React.memo(({ label, tagId, onRemove }) => {\n  console.log(`CleanProductTag rendered: \"${label}\"`);\n  // Bind the tag ID inside the child — the parent stays clean.\n  return (\n    <span>\n      {label}\n      <button onClick={() => onRemove(tagId)}>✕</button>\n    </span>\n  );\n});",
        "output": "// On first render:\nProductTag rendered: \"React\"\nProductTag rendered: \"TypeScript\"\nProductTag rendered: \"Node\"\n\n// After clicking 'Add to Cart' (cartCount changes, tags don't):\n// → Nothing logged. All three ProductTags bailed out. ✅\n\n// After removing 'TypeScript' (tags array changes):\n// → handleRemove is recreated (deps changed)\n// → React.memo re-evaluates remaining tags\nProductTag rendered: \"React\"\nProductTag rendered: \"Node\""
      }

useMemo — Caching Expensive Computed Values Across Renders

useMemo(() => computeValue(), deps) runs the factory function once, stores the result, and returns that same result on every subsequent render until a dependency changes. It's the hook for when the computation is the bottleneck, not the reference.

The two valid use cases for useMemo are: (1) genuinely expensive computations — think filtering or sorting thousands of records, running a heavy algorithmic transformation, or deriving complex state trees; and (2) referentially stable objects and arrays that need to be passed to memoized children or used in other hooks' dependency arrays.

That second use case is subtler but equally important. If you compute an options object inside a component and pass it to a child wrapped in React.memo, or use that object in a useEffect dependency array, every render produces a new reference, triggering unnecessary effects or child renders. useMemo pins that object to a stable reference.

One internal detail worth knowing: React can and does discard the memoized value in some situations — specifically in development mode during Strict Mode double-invocation, and in future concurrent features where React may interrupt and restart renders. Never rely on useMemo as the single source of truth for side effects or critical logic. It's a performance hint to React, not a guarantee.

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

// Simulate a large product catalogue — 50,000 items.
function generateCatalogue(size) {
  return Array.from({ length: size }, (_, index) => ({
    id: index,
    name: `Product ${index}`

Production Patterns, Edge Cases, and the Hidden Costs of Over-Memoizing

Here's the uncomfortable truth: useMemo and useCallback cost something too. Every memoized value consumes memory. Every render still executes the hook, runs the dependency comparison, and decides whether to return the cached value or recompute. For cheap computations and simple primitives, that overhead can easily exceed what you saved.

Over-memoization is a real production pattern that makes codebases harder to read, harder to refactor, and sometimes actually slower. The React core team's recommendation is measured and specific: profile first, memoize where the profiler shows a real problem, and review your memoization regularly as component structures change.

There are three advanced patterns worth knowing. First, memoizing derived context values — if you provide an object through React Context without memoizing it, every context consumer re-renders on every provider re-render even if the values inside the object didn't change. useMemo on the context value object is one of the few cases where memoization pays dividends across a wide component tree. Second, stable refs as an alternative — useRef gives you a stable container for free, and for event handlers that need access to latest state without re-subscribing, combining useRef with useCallback can eliminate deps entirely. Third, the useEvent pattern (RFC stage) — a future hook that aims to give you a stable function reference that always closes over fresh values, solving the deps-vs-stability tension permanently.

import React, { useState, useCallback, useMemo, useContext, createContext } from 'react';

// ─── Context setup ────────────────────────────────────────────────────────────
const ShoppingCartContext = createContext(null);

export function ShoppingCartProvider({ children }) {
  const [cartItems, setCartItems] = useState([]);
  const [promoCode, setPromoCode] = useState('');

  const addItem = useCallback((item) => {
    setCartItems(current => [...current, item]);
  }, []); // stable: only uses the setter, no external deps

  const removeItem = useCallback((itemId) => {\n    setCartItems(current => current.filter(i => i.id !== itemId));
  }, []);

  const applyPromo = useCallback((code) => {
    setPromoCode(code);
  }, []);

  // ✅ Critical pattern: memoize the context VALUE object.
  // Without this, every render of ShoppingCartProvider creates a new
  // context object reference → ALL consumers re-render, even components
  // that only use `addItem` and haven't seen a cart change.
  const contextValue = useMemo(
    () => ({
      cartItems,    // changes when items are added/removed
      promoCode,    // changes when promo is applied
      addItem,      // stable reference from useCallback
      removeItem,   // stable reference from useCallback
      applyPromo,   // stable reference from useCallback
    }),
    [cartItems, promoCode, addItem, removeItem, applyPromo]
  );

  return (
    <ShoppingCartContext.Provider value={contextValue}>
      {children}
    </ShoppingCartContext.Provider>
  );
}

// ─── Consumer that only needs the addItem action ──────────────────────────────
const AddToCartButton = React.memo(({ productId, productName }) => {\n  // This component subscribes to the full context, which is why\n  // the memoized context value above is so important.\n  // If contextValue changes reference on every render, this re-renders too.\n  const { addItem } = useContext(ShoppingCartContext);

  console.log(`AddToCartButton rendered for: ${productName}`);

  return (
    <button onClick={() => addItem({ id: productId

Diagnosing Memoization Failures — A Step-by-Step Debugging Workflow

When memoization doesn't work as expected, it's rarely because the hooks themselves are broken. The cause is almost always one of: an unstable dependency, a missing React.memo on the child, or a stale closure. Here's a systematic way to diagnose which one.

Start with React DevTools – locate the memoized child in the component tree and verify it's actually rendered as memo. If the child re-renders when you expect it not to, record a profile and look at the props panel for the child. The 'changed' markers show exactly which prop reference changed.

Next, if a prop that should be stable is flagged as changed, examine its origin in the parent. If it's an inline function, wrap it with useCallback and check that the dependencies are correct. If the prop is an inline object or array, wrap it with useMemo. If the prop is already in useCallback/useMemo but still changes, the culprit is likely a dependency that itself is unstable – an object defined inline inside the dependency array's scope.

Sometimes you need to debug at a lower level. Use a useEffect with console.log of the dependency array values to see when they actually change. This is especially useful for detecting hidden reference changes.

Finally, the stale closure case is the trickiest. If your callback uses a variable from the enclosing scope but you've deliberately omitted it from deps to keep the function stable, the callback will always see the initial value. Use the ref pattern to hold the latest value without triggering deps changes.

// Utility to log when a useCallback is actually recreated.
// Add this inside the component to debug dep changes.
function useDebugDeps(label, deps) {\n  const prevDepsRef = React.useRef(deps);\n  const depsChanged = prevDepsRef.current !== deps && !deps.every((dep, i) => Object.is(dep, prevDepsRef.current[i]));\n  useEffect(() => {\n    if (depsChanged) {\n      console.log(`${label} deps changed:`, { prev: prevDepsRef.current, current: deps });
    }
    prevDepsRef.current = deps;
  });
}

// Usage in component:
const handleRemove = useCallback(() => {
  doSomething(userId);
}, [userId]);
useDebugDeps('handleRemove', [userId]);

// Now every time handleRemove is recreated, you'll see what dep changed.