| name | react-memoization-guide |
| description | Guidelines for proper React memoization (useMemo, useCallback, React.memo) usage. Use when writing React components, reviewing code with useMemo/useCallback, refactoring performance optimizations, or when asked about React performance patterns. Helps identify common misuse patterns and apply the "clarity first, optimize when justified" principle. |
React Memoization Guide
Apply these guidelines when working with useMemo, useCallback, and React.memo in React code.
Core Principle
Clarity comes first. Optimize only when you justify the need.
When reviewing or writing code with memoization hooks, default to questioning whether they're necessary.
Decision Framework
Before adding memoization, ask:
- Is this calculation/work expensive? If no โ skip memoization
- Does reference stability matter here? (React.memo, effect deps) If no โ skip memoization
- Would removing this make code clearer? If yes โ remove it
- Are the dependencies correct? If uncertain โ it's probably wrong
Quick Reference
useMemo
Only use when:
- The calculation is genuinely expensive (not string concatenation or small maps)
- Reference stability is needed for
React.memo optimization
- The value is a dependency in
useEffect or other hooks
Common misuse:
const fullName = useMemo(
() => `${user.firstName} ${user.lastName}`,
[user]
);
const fullName = `${user.firstName} ${user.lastName}`;
useCallback
Only use when:
- Passing callbacks to memoized children (and children are actually expensive)
- The function is a dependency in
useEffect
Common misuse:
const onClick = useCallback(() => setOpen(true), []);
const onSave = useCallback(() => {
api.save(formState);
}, []);
const onSave = () => api.save(formState);
Red flag: Empty dependency array [] often signals incorrect code structure.
React.memo
Only wrap components that:
- Are expensive to render (complex layouts, large lists, heavy calculations)
- Receive stable props (or props wrapped in useMemo/useCallback)
Wrapping cheap components adds overhead without benefit.
Detailed Patterns
For comprehensive examples and anti-patterns, see references/memoization-patterns.md.
Implementation Approach
When writing React code:
- Start without memoization - write clear, straightforward code
- Profile if needed - only if there's an actual performance problem
- Add targeted memoization - only where profiling shows benefit
- Document why - if memoization stays, add a comment explaining the justification
When reviewing code:
- Question every useMemo/useCallback - assume it's not needed until proven otherwise
- Check dependencies - ensure they're correct and complete
- Verify benefit - does the memoization actually prevent expensive work?
- Suggest removal - if the benefit is unclear, remove it