How do you approach Frontend: When to Memoize (useMemo / useCallback / React.memo)?

Apply rules in order: compute cost first, then size, then referential dep.

What are common mistakes on Frontend: When to Memoize (useMemo / useCallback / React.memo)?

An incomplete dependency array, which pins the effect to a stale closure. Mutating state in place instead of replacing it, so no re-render is scheduled. Never cleaning up the timer, listener or subscription on unmount.

gitGood.dev

← Back to problems

Frontend: When to Memoize (useMemo / useCallback / React.memo)

MediumTypeScript

Description

This problem is paper-only - see explanation for the canonical React reasoning.

Premature memoization is one of the most common mistakes in React code reviews. The auto-grader validates the decision rules.

Given a function call shaped { computeCostMs, callsPerRender, isReferentialDep, sourceRowsLargerThan10k }, return one of:

"useMemo" if the value should be memoized (significant compute OR a referential dep, OR working over a large input).
"useCallback" if it's a function passed as a prop AND the recipient is React.memo-wrapped (model: isReferentialDep === true).
"none" otherwise.

Decision tree implemented by the grader:

computeCostMs > 5 → "useMemo".
sourceRowsLargerThan10k → "useMemo".
isReferentialDep → "useCallback".
Otherwise → "none".

(If both #1 and #3 hold, useMemo wins - the value itself needs caching.)

For the auto-grader: implement memoizationAdvice(input).

Example 1

Input: input = {computeCostMs:0,callsPerRender:1,isReferentialDep:false,sourceRowsLargerThan10k:false}

Output: "none"

Explanation: Cheap value, no referential deps, small data - skip the cache and the deps array overhead.

Example 2

Input: input = {computeCostMs:30,callsPerRender:1,isReferentialDep:false,sourceRowsLargerThan10k:false}

Output: "useMemo"

Example 3

Input: input = {computeCostMs:0,callsPerRender:1,isReferentialDep:true,sourceRowsLargerThan10k:false}

Output: "useCallback"

Constraints

- computeCostMs >= 0 - callsPerRender >= 1 - booleans are booleans.

Frontend: When to Memoize (useMemo / useCallback / React.memo): approach, complexity and pitfalls

A medium frontend problem, graded against 5 test cases (2 of them hidden).

The pattern: Frontend

React and browser-platform problems - hooks, event handling, and rendering behaviour.

Reach for it when you see: A component, hook, or DOM-behaviour question rather than an algorithm.

If you are stuck

Show the 2-step hint ladder

Apply rules in order: compute cost first, then size, then referential dep.
Don't memoize cheap pure values - the deps comparison itself isn't free.

The optimal approach

Show the approach: The actual decision tree (real-world version):

1. Profile first. React DevTools Profiler tells you what's slow. Don't memoize speculatively; you usually trade one allocation for another and add complexity.

2. Use `useMemo` when:

- The computation is genuinely expensive (>~5ms is a useful rule of thumb; below that the deps comparison costs more than the recompute).

- The value is a non-primitive used as a dep elsewhere (e.g. a derived array fed into another `useMemo` or `useEffect`) - reference stability avoids cascading recomputation.

3. Use `useCallback` when:

- You're passing a function to a `React.memo`-wrapped child - without stable refs, memo is defeated.

- You're passing a function as a dep to `useEffect` and want to avoid re-running.

4. Use `React.memo` when:

- A component re-renders frequently due to parent updates and its own work is non-trivial.

- Its props are mostly stable.

The React 19 caveat: the React Compiler (formerly "Forget") auto-memoizes provably-pure values, making manual memoization mostly unnecessary in compiler-enabled codebases. Until then, profile-driven memoization is the right approach.

Anti-pattern: wrapping every callback in `useCallback` "just in case". This adds deps-array overhead, complicates code, and rarely helps - unless the callback flows into a `React.memo` boundary, the stable ref doesn't save anything because the child re-renders for other reasons.

The full reference solution in every supported language stays in the editor above - reveal it there once you have had a real attempt.

Common Frontend mistakes

These apply to the pattern as a whole, not just this problem.

An incomplete dependency array, which pins the effect to a stale closure.
Mutating state in place instead of replacing it, so no re-render is scheduled.
Never cleaning up the timer, listener or subscription on unmount.