When to use useMemo and useCallback (and when I stopped wrapping everything)

I once opened a pull request where almost every handler was wrapped in useCallback and half the derived values sat inside useMemo. A reviewer left one comment: "what was slow?"

I didn't have an answer. I'd been optimizing vibes.

That PR got merged anyway, because nothing was broken. It also made the file harder to read, and six months later when someone changed a dependency array wrong we spent an afternoon chasing a stale closure that only showed up after a filter toggle. That was the first time I started treating memoization like a tool with a cost, not a house style.

What these hooks actually buy you

useMemo remembers a value between renders. useCallback remembers a function. That's the whole pitch.

React re-creates most things on every render by default. New object, new array, new arrow function. Usually that doesn't matter. It starts to matter when something downstream cares about identity: a child wrapped in React.memo, a dependency array on an effect, a third-party chart that redraws whenever its onZoom prop changes reference.

I used to explain this with diagrams. Now I just say: if nothing is comparing the old reference to the new one, stabilizing the reference does nothing useful. You're paying for a cache entry and a dependency check so that React can hand you back the same function you would've created in two microseconds.

The useCallback mistake I kept repeating

Pattern that showed up in my code for years:

Wrap a list row in React.memo
Pass it an onSelect handler from the parent
Forget that the handler is a new function every render
Wonder why the profiler still lights up every row

React.memo does a shallow compare. A new function is a new prop. The memo wrapper shrugs and re-renders. Adding useCallback fixes that pairing. Leaving the unstable handler in place and blaming React is how I wasted a morning on a dashboard that rendered 400 product rows on every keystroke in a search box.

The flip side is wrapping handlers that never get passed to a memoized child and never appear in a dependency list. I've seen whole app shells where every onClick is memoized "for performance." It's cargo cult. The page didn't get faster. The code got louder.

When useMemo actually earned its keep for me

Sorting and filtering a few dozen items? Not worth it. I've measured this more than once on list UIs that felt "heavy" and the cost was almost never the .sort().

Where it did matter: a reporting view that grouped a few thousand line items, ran a couple of derived totals, and fed a table. Without memoization, typing in a sidebar note field re-ran the whole grouping on every keypress. The input lagged in that specific, embarrassing way where the caret falls behind your fingers. Wrapping the derived dataset in useMemo keyed on the source rows and the active filters fixed it. Moving the note state into a smaller child component also would've fixed it. I did both, eventually.

So my current bar is boring and slightly annoying to follow: profile first, or at least have a reproduction you can feel. If you can't point at the work being repeated, don't memoize it yet.

A small playground if you want to poke at this

Reading about referential equality is one thing. Watching rows flash when a parent updates is another.

I built a rendering playground for exactly that. You can switch between a default render path, React.memo, useMemo, useCallback, and a virtualized list, then bump the item count and complexity and hit Run Benchmark. It's not a lab-grade profiler. It is enough to see why "I wrapped it in memo" sometimes does nothing, and why virtualizing the DOM can beat memoization when the list is huge.

React Compiler, briefly

If you're on a setup with the React Compiler enabled, a lot of this manual wrapping gets less interesting. The compiler can insert memoization where it's safe. I still think it's worth understanding the hooks, the same way I still think it's worth knowing what a bundler does even if you never write a webpack config again. Blind spots exist. Effects that need a stable dependency, libraries that compare props by reference, weird control flow the compiler won't touch. But if your instinct on every new component is still "memoize first," the compiler is a good excuse to retire that instinct.

Questions I get asked about useMemo and useCallback

When should I use useMemo in React?

When you've got an expensive calculation, the inputs don't change every render, and you've seen the cost show up, or when you need a stable value for a dependency array. Not as a default for every derived boolean.

When should I use useCallback?

When you're passing a function to a memoized child, or putting that function in a dependency list, and an unstable reference is causing extra work or extra effect runs. If nothing cares about the function's identity, skip it.

Is useCallback the same as useMemo?

Almost. useCallback(fn, deps) is basically useMemo(() => fn, deps) for functions. People separate them because intent reads clearer, not because the machinery is wildly different.

Do I still need React.memo if I use useCallback?

They're a pair, not substitutes. useCallback keeps the prop stable. React.memo is what decides to skip the child. One without the other is how you get false confidence.

What I do now

Default to plain components. Put state close to where it's used so random parent updates don't thrash a big tree. If a list gets long, I think about virtualization before I think about wrapping every row in three hooks. When something feels slow, I open the profiler instead of sprinkling useMemo until the feeling goes away.

I still use both hooks. Just not as decoration.