Memoization Pitfalls
Slap yourself if
You think memoization automatically makes code faster or that using useMemo/useCallback is always a performance win.
Why this exists
Memoization exists to avoid repeating expensive computations or renders when inputs haven’t changed. Pitfalls arise because memoization relies on strict assumptions about identity, immutability, and cost — assumptions that are often violated in real apps.
Mental model
Memoization is a cache keyed by identity. If inputs are referentially equal, cached results are reused. If not, work runs again. Memoization does not reduce total work unless the skipped work is more expensive than the overhead of caching and comparison.
- A memoized function or component stores its previous inputs and result.
- On the next run, inputs are compared (usually by reference).
- If inputs match, the cached result is reused.
- If inputs differ, the computation runs again and cache updates.
- Incorrect assumptions about identity cause cache misses or stale results.
- Memoizing cheap computations and adding unnecessary overhead.
- Recreating dependency objects every render, causing cache misses.
- Mutating dependencies and keeping the same reference, causing stale results.
- Overusing memoization and making code harder to reason about.
- Assuming memoization fixes slow renders caused by layout or effects.
Memoization avoids repeating work when inputs are referentially equal, but it only helps if the skipped work is expensive and identity is stable. Otherwise it adds overhead or causes bugs.
- Memoization always improves performance.
- useMemo prevents re-renders.
- Memoization is free.
Deep dive
Premium deep dives include more internals, more scars.
What memoization actually costs
How memoization creates subtle bugs
Memoization failures are often correctness bugs disguised as performance issues.
When memoization is worth it
Memoization should be a deliberate, measured choice.
Memoization and real performance
Memoization protects against wasted work; it does not fix architectural bottlenecks.
Interview landmines
- Claiming memoization always improves performance
- Not mentioning referential equality
- Ignoring stale closure risks
Related terms
Referential Equality
You think two objects with the same values are equal in JavaScript or that referential equality is an implementation detail you can ignore.
Structural Sharing
You think structural sharing means copying objects less or that immutability always means deep cloning.
Immutable Data Patterns
You think immutability just means using spread syntax or that it’s only about avoiding bugs.
Stale Closure Problem
You think closures automatically update when state changes or that stale closures are just a React Hooks quirk.
Concurrent Rendering
You think concurrent rendering means React renders in parallel threads or it always makes apps faster.