When Not to Memo
Last updated: 2026-11-02
When Not to Memo When Not to Memo
memo, useMemo and useCallback are not free: comparing and caching cost something and the code becomes harder to read. Most components are cheap to render, so re-rendering them is often faster than remembering to skip it. Knowing when not to memoize matters more than sprinkling memo everywhere. The rule of thumb is to measure first: profile the app, find the components that genuinely cost time, and optimize only those.
| Group | Effects & Performance |
|---|---|
| Kind | Pattern |
ℹ️ Info The editor transpiles JSX to JavaScript and renders the real UI in a sandbox; components mount automatically — no manual render call needed.
📝 Syntax
// cases that usually do not need memo:
// 1. the component renders fast enough (plain text, a few nodes)
// 2. the props change every time (object literals, inline functions)
// 3. the state lives in this component, so the parent always re-renders it
<MemoChild style={{ color: 'red' }} onClick={() => go()} />
// ↑ a new object and a new function on every render make memo pointlessReturns：No return value; this entry describes an encoding pattern rather than a function.
▶ Example
The example runs out of the box: it auto-renders when expanded, and edits take effect instantly.
Output：
While you type, the Badge is skipped (the memo wrapper does its job), but clicking +1 re-renders the Badge for sure — count is one of its props. There is no gain here, and removing the wrapper keeps the code simpler.💡 Key Points
🏷️ More Effects & Performance
💡 Related Cases
📚 Related Tutorials
❓ FAQ
