React Devs Overuse useCallback and useMemo: Optimization Tools Not Defaults

⚡ Hot take: Most React devs over-use useCallback and useMemo. They're optimization tools — not default patterns. UseCallback: Memoizes a function reference. UseMemo: Memoizes a computed value. ✅ USE them when: • Passing callbacks to child components wrapped in React.memo • Expensive calculations (filtering 10k+ items) • Dependency arrays in useEffect ❌ AVOID them when: • The component re-renders anyway • The computation is cheap • You're just adding complexity for no gain Every memoization has a cost — memory + comparison overhead. Profile first. Optimize second. Always. #React #ReactJS #Frontend #JavaScript #WebDevelopment

  • text

I’ve seen components wrapped in layers of useCallback and useMemo where the optimization cost more mental energy than the re-render ever would. Memoization is a trade-off, not a badge of seniority. If a component re-renders in 0.3ms, adding complexity to “fix” it is just noise. Measure first, understand what’s actually slow, then optimize with intent instead of habit.

Ive seen custom hooks be custom hooks to return a single function wrapped in a use callback with the statement - it uses useCallback so it has to be a hook, with a function that fetched something. I mean… come on, really? Oh yeah, to make matters worse it was wrapped in 2 layers of custom hooks to be exported and used in a single place … why not just write the function co-located next to where it was used instead of abstracting the hell out of it? This post states solid facts about people trying to do “best practice” without even RTFM 😑 So thanks for this statement, it can’t be stressed enough!

Like
Reply

Also worth mentioning that excessive memoization can actually make components harder to reason about. Sometimes removing useMemo/useCallback makes the code both faster and cleaner.

Like
Reply

You need to be a bit more specific when you say the computation is cheap. If we assume re-render as roughly O(1) operation in relation to the node itself, then any logN and higher operation is already expensive, including filtering single-digit number of items

I’ve seen this happen a lot in real projects. Well explained!

Like
Reply
See more comments

To view or add a comment, sign in

Explore content categories