Monthly Archives: May 2026

Why useCallback and useMemo Are Not Silver Bullets

Posted on by

Developer debugging code on laptop

If you’ve spent any real time in React, you know the reflex. You spot a chunky computation, and your fingers type useMemo before your brain finishes the thought. A callback heads to a child component, and useCallback wraps it like shrink-wrap. The docs and a hundred Medium posts told you these hooks stop pointless re-renders. But after profiling real, living applications for years, I’ve hit a less comfortable truth: slapping useMemo and useCallback everywhere often backfires. Hard.

I’m Suki Watanabe. My days are spent inside a large-scale SaaS, hunting actual performance regressions. I used to reach for these hooks like salt at dinner—automatic, no tasting first. The outcome? Codebases that got harder to read, trickier to maintain, and sometimes measurably slower than before. This isn’t a theory piece. It’s a field report on when these hooks earn their keep, and when you should step back and let React breathe.

The Premature Optimization Trap

React’s own docs warn against optimizing too early. Still, a kind of folklore has spread that useCallback and useMemo are always a good idea. They aren’t. These hooks were built for two specific headaches: referential equality and genuinely expensive calculations. If your component doesn’t ache from either one, you’re just adding clutter.

Take a plain presentational component that renders a list. That list array gets defined inside the parent and passed down. A newer developer might wrap it in useMemo, convinced they’re dodging a re-render. Trouble is, if the array changes on every render anyway—because it’s built from props that update constantly—the memoization adds cost with zero benefit. React now has to check the dependency array, diff old and new values, and hold onto the previous result. That work isn’t free.

“The overhead of useMemo and useCallback is real. You’re swapping plain JavaScript computation for memory and comparison work. Be sure you’re coming out ahead.”

I’ve walked into codebases where every single function and object wore a memoization jacket. The team felt productive. The app felt swampy. Why? They skipped the cardinal rule: measure first, optimize later.

Understanding Referential Equality

To use these hooks well, you need a working feel for referential equality in JavaScript. In React, a component re-renders when state or props change. Props get compared with a shallow check. Two objects that look the same but sit at different memory addresses will still spark a re-render. That’s where useMemo and useCallback earn their reputation—they keep the same reference across renders, provided the dependencies hold steady.

Code comparison on screen showing JavaScript objects

But that reference stability only matters if the child is wrapped in React.memo. Without it, the child blithely re-renders no matter what. I’ve debugged too many components where useCallback was applied like sunscreen, yet the child wasn’t memoized. The hooks just sat there, burning memory for nothing.

Here’s a real scenario. Picture a SearchBar that takes an onChange prop. If the parent defines that handler inline, every render of the parent spawns a new function reference. If SearchBar is wrapped in React.memo, it’ll still re-render because that reference changed. useCallback fixes that—provided SearchBar is memoized. Miss that combo, and you’re just adding brackets for exercise.

The Hidden Cost of Dependencies

Every useCallback and useMemo carries a dependency array. Managing those arrays breeds subtle bugs. Omit a dependency and you get a stale closure; pile in too many and the cache invalidates constantly, erasing the point. ESLint’s react-hooks/exhaustive-deps rule nudges you in the right direction, but it’s not a cure-all. I’ve watched developers silence the rule with a comment because they “know better.” They usually don’t.

A stale closure can be nasty. Your callback clings to an old value, and the UI drifts into weird, unreproducible states. This gets especially dangerous inside event handlers or effects that depend on fresh state. The hours you burn chasing stale closures can easily swamp any performance win you thought you were getting.

When useMemo Actually Bites Back

Let’s talk about useMemo for “expensive” calculations. The textbook example is filtering a big list. If the list and filter terms rarely change, memoizing the filtered result makes sense. But what if that list churns on every render? Now the memoization piles on overhead each time, and the cache gets tossed almost instantly. Net loss.

I once profiled a dashboard that ate real-time data. A developer had memoized a derived data structure that leaned on five different state variables. The dependency array was a monster, and the computation itself wasn’t heavy—some sorting, a few maps. Stripping the useMemo shrunk the component’s memory footprint and made interactions snappier. The lesson: don’t guess a calculation is slow. Measure it.

Performance profiling chart on monitor

Another trap is wrapping inline styles or class name strings in useMemo. Building a tiny object or concatenating a few strings is dirt cheap. useMemo just muddies the code and forces the next reader to ask, “Why is this cached?” Usually the answer is: “Because someone thought it looked faster.” If the object’s values come from props, React’s reconciliation already has your back. Trust the framework until it lets you down.

Server-Side Rendering and Hydration

In server-rendered React apps, useMemo and useCallback can tangle hydration. The server renders once, so memoization doesn’t help there. During hydration, React has to match the server output exactly. If your hooks have side effects or touch browser-only APIs, mismatches creep in. I’ve lost evenings to hydration errors that traced back to a useMemo that calculated something differently on the client.

This doesn’t mean you should rip them out of SSR apps. It means you need precision. Understand what runs where. A pure calculation that only touches props is fine. Anything that peeks at window or localStorage belongs in an effect, not a memo hook.

The Readability Factor

Code gets read way more than it gets written. Overdosing on useMemo and useCallback chews up readability. A component laced with these hooks forces you to mentally chase dependencies and guess what’s cached and why. Often the reason is just “the last dev thought it would be faster.”

I stick to a straightforward rule: useCallback only when you pass the function to a memoized child or into a dependency array of an effect. useMemo only when the computation is demonstrably slow (you’ve profiled it) and its inputs change rarely. For everything else, let React’s defaults run. The framework is fast enough for the vast majority of what we build.

Look at this snippet:

const handleClick = useCallback(() => {
  setCount(count + 1);
}, [count]);

If handleClick just sits on a plain button, the useCallback is dead weight. Even when the parent re-renders, creating a fresh function is cheaper than the bookkeeping useCallback adds. The React team has said this out loud, more than once. Yet the pattern still shows up everywhere.

Practical Guidelines from the Trenches

After years of pulling React apps apart and putting them back together, I lean on a few heuristics that keep things fast and sane.

  • Profile before wrapping. Fire up the React DevTools Profiler and find real choke points. Look for components that re-render often and take a long time per render. Then think about memoization.
  • Memoize children, not every prop. If a component is genuinely heavy to render, wrap it in React.memo. Then use useCallback and useMemo for the props that need referential stability.
  • Avoid memoizing primitives. Strings, numbers, booleans—these compare by value. useMemo on them adds zero value.
  • Keep dependency arrays small. If your useCallback depends on five state variables, it’s probably doing too much. Pull out a smaller function or reshape the component.
  • Consider alternative patterns. Sometimes moving state down or lifting content up removes the need for memoization entirely. The upcoming React compiler aims to automate a lot of this, making manual hooks less necessary.

These aren’t rigid laws. They’re starting points. Every app has its own performance fingerprint. Stay curious, stay skeptical. When someone tells you to “just use useMemo everywhere,” ask to see the flame chart.

FAQ: Common Doubts About useCallback and useMemo

Should I wrap every function in useCallback if I use it in a useEffect?

Not automatically. If the function lives inside the component and is used only in that effect, try moving the function into the effect itself. That cuts out the need for memoization and makes the dependency chain obvious. Reach for useCallback only when the function is needed elsewhere—like in a child component or another hook.

Isn’t it always safer to memoize just in case?

No, it’s not safer. Unnecessary memoization adds mental noise, nudges bundle size up slightly, and can introduce stale closure bugs when dependencies slip. React’s default rendering is fast. The “safety” you feel is mostly an illusion that leads to knottier, harder-to-debug code.

How do I know if a calculation is “expensive” enough for useMemo?

Profile it. Wrap the calculation with console.time, or better, use the React Profiler. If it consistently runs above 1ms and the component renders often, useMemo might earn its keep. For most sorting, filtering, or object creation on small datasets, it won’t matter. Always test with realistic data sizes under production-like conditions.

In the end, useCallback and useMemo are tools, not rituals. They fix specific problems in specific spots. The strongest React developers I know deploy them sparingly, deliberately. They trust React’s internals and only step in when the profiler leaves them no choice. Next time you’re about to wrap that function, pause and ask: what am I actually gaining? Your future self—and your teammates—will be glad you did.

How to Use React Context Without Destroying Performance

Posted on by

React Context is a double-edged sword. It solves prop drilling elegantly, but one misplaced useContext call can trigger a cascade of re-renders that tanks your app’s responsiveness. I’ve seen teams rip Context out of production code because they didn’t know how to tame it. This guide shows you the patterns that keep your components fast while still using Context for state that truly belongs there.

Code editor showing React component structure

Why Context Causes Performance Problems

The default behavior of Context is deceiving. When a context value changes, every consumer of that context re-renders—even if the consumer only uses a small slice of the data that hasn’t changed. This isn’t a bug; it’s how React compares context values by reference. If the provider passes a new object literal on every render, all consumers update, regardless of whether their specific piece of state changed.

Consider a typical authentication context. You might store user, token, and logout together. A component that only displays the user’s avatar will re-render when the token refreshes, because the entire context value is a new object. Multiply this across dozens of components, and you’ll see frames drop.

Split Contexts by Update Frequency

The simplest fix is to stop putting unrelated state into one big context. Separate values that change at different rates into distinct contexts.

Theme vs. User State

A theme toggle rarely changes. A user object might update after every API call. By separating these into ThemeContext and UserContext, a profile component that consumes only UserContext won’t re-render when someone switches to dark mode.

State vs. Dispatch

If you’re using useReducer, the dispatch function is stable—it never changes between renders. Yet many developers pass { state, dispatch } as the context value. This forces every consumer to re-render when any state changes, even components that only call dispatch. Instead, create two contexts: StateContext and DispatchContext. The dispatch provider value stays constant, so components that only dispatch actions never re-render due to context changes.

const StateContext = createContext();
const DispatchContext = createContext();

function AppProvider({ children }) {
  const [state, dispatch] = useReducer(reducer, initialState);
  return (
    
      
        {children}
      
    
  );
}

Now a button component that only dispatches an action can use useContext(DispatchContext) without subscribing to state updates.

Split React component tree with separate contexts

Memoize Context Values Correctly

Passing object literals or inline functions directly to the value prop creates a new reference on every render of the provider. This means all consumers re-render on every provider render, even if the underlying data hasn’t changed.

Wrap your context value in useMemo with explicit dependencies. This ensures the object reference only updates when the actual data changes.

const value = useMemo(() => ({ user, logout }), [user, logout]);

return (
  
    {children}
  
);

For useReducer, the state object itself is already stable between renders if the reducer doesn’t return new objects unnecessarily. But the combination { state, dispatch } still needs memoization unless you split the contexts as described above.

Component Composition Over Context Prop Drilling

Sometimes the best way to avoid context-induced re-renders is to not use context at all for components that are expensive to render. Instead, use component composition to pass data via props or children.

If you have a heavy chart component that needs a color palette, passing the palette as a prop isolates the chart’s re-render scope. The parent might subscribe to context, but it re-renders cheaply because it’s just a wrapper. The chart itself stays memoized with React.memo.

const ExpensiveChart = React.memo(({ palette }) => {
  // heavy rendering logic
});

function ChartWrapper() {
  const { palette } = useContext(ThemeContext);
  return ;
}

Use Selectors with External Libraries (or Build Your Own)

Context doesn’t natively support selectors—the ability to subscribe to only part of the context value. Redux and Zustand do. If your state is complex and updates frequently, consider a library like Zustand for that specific slice of state. Zustand’s hooks accept a selector function, so components re-render only when the selected value changes.

You can achieve a similar pattern with Context by combining useSyncExternalStore or by splitting contexts down to the individual value level. For a small number of values, this manual approach works well. For larger state trees, an external store is a practical choice.

Context + useMemo: A Fine-Grained Control Pattern

When you can’t avoid a large context, you can wrap consumers in a component that selects the needed value and passes it to a memoized child. This technique is sometimes called the “context selector” pattern.

function Avatar() {
  const { user } = useContext(AppContext);
  return useMemo(() => , [user]);
}

Here, ExpensiveAvatar only re-renders when user changes. Other context updates—like a new notification count—won’t trigger a re-render of the avatar because the Avatar component’s useMemo prevents it. This pattern pushes the performance concern to the leaf component level and keeps the provider simple.

Performance dashboard showing React render times

When Context Isn’t the Right Tool

Context is a dependency injection mechanism, not a state management solution. If you find yourself fighting re-renders, ask whether the data truly needs to be global or if it can be lifted to a common parent and passed as props. Often, the simplest solution is to keep state local and pass it explicitly.

For data that changes every frame (like scroll position or mouse coordinates), context is a poor choice. Use a ref with a subscription model, or a library built for high-frequency updates. Context’s immutability model works against you here—every update creates a new object, triggering re-renders across the entire subtree.

FAQ

Does React.memo prevent re-renders from context changes?

No. React.memo only prevents re-renders when props haven’t changed. Context changes bypass React.memo entirely. A memoized component will still re-render if it consumes a context whose value has changed, regardless of whether the props are identical.

How many context providers is too many?

There’s no hard limit, but nesting dozens of providers becomes a readability and maintenance headache. As a rule of thumb, group related state into a provider only when the values update at similar frequencies. If you have more than five or six providers wrapping your app, consider consolidating rarely-changing ones or moving fast-changing state to a solution with native selector support.

Can I use Context with server-side rendering without performance hits?

Yes. The same rules apply: split by update frequency, memoize values, and avoid unnecessary re-renders. On the server, re-renders are less of a concern because they don’t block the main thread, but excessive work still increases Time to First Byte. Keep context values stable between requests to let React’s streaming SSR do its job efficiently.

Why does my component re-render even though the context value looks the same?

React compares context values using Object.is. If the provider creates a new object or array literal on every render—even with identical contents—the reference changes, and all consumers re-render. Always memoize objects and arrays passed to the value prop, or use separate contexts for primitives that don’t require reference stability.

Beyond these patterns, profile your app with React DevTools. The “Highlight updates when components render” option reveals exactly where context is causing unnecessary work. Fix the hotspots, leave the rest alone. Performance optimization is about removing bottlenecks, not chasing theoretical purity. Context can be fast—you just need to know which levers to pull.

For further reading, check the React docs on useContext and the patterns Kent C. Dodds outlines. If you’re dealing with server components, our guide on mixing Context with RSC covers the sharp edges.