Senior React devs do this all the time. I did it too. useCallback + React.memo → Child won't re-render. Right? Not always. And when it's wrong, it's silently wrong. Here's the trap: You wrap a handler in useCallback with a dependency say, count hoping to memoize it. You wrap Child in React.memo thinking it's now protected. But every time count changes, useCallback creates a new function reference. And React.memo compares props by reference. New reference = Child re-renders anyway. useCallback didn't help. React.memo didn't help. You just added complexity with zero gain. This is the most common performance anti-pattern I've seen in React codebases at scale engineers reaching for useCallback as a reflex, without understanding the actual memoization contract: → useCallback only skips recreation if deps don't change → React.memo only skips re-render if props references are stable → Both need to work together and deps must actually be stable The real fix here - 1. Either remove count from deps and use a functional updater: setCount(c => c + 1) 2. Or accept the re-render not every render is a problem Premature memoization is just as bad as no memoization. Measure first. Optimize after. #ReactJS #JavaScript #Frontend #WebPerformance #UIEngineering #SeniorDeveloper #UI #UX #WebDeveloper
useCallback doesn’t prevent re-renders - it only stabilizes references if deps don’t change. I’ve seen many cases where removing memoizationactually made code simpler with zero perf impact.
I wouldn't even consider using React.memo for a simple button component. Not every re-render is bad. After all, React depends on this. It's what you run during each re-render that's the issue.