{"id":165,"date":"2026-10-19T04:56:23","date_gmt":"2026-10-19T04:56:23","guid":{"rendered":"https:\/\/webdevpuneet.com\/blog\/?p=165"},"modified":"2026-10-19T04:56:38","modified_gmt":"2026-10-19T04:56:38","slug":"useeffect-explained-8-common-mistakes-and-how-to-fix-them","status":"publish","type":"post","link":"https:\/\/webdevpuneet.com\/blog\/useeffect-explained-8-common-mistakes-and-how-to-fix-them\/","title":{"rendered":"useEffect Explained: 8 Common Mistakes and How to Fix Them"},"content":{"rendered":"

<\/p>\n\n\n

Almost every confusing useEffect<\/code> bug comes from the same handful of misunderstandings, repeated in different clothes: treating the dependency array as optional, closing over a value that’s already gone stale, forgetting that objects are compared by reference, or reaching for an effect when the answer was a plain calculation or an event handler all along. None of these are edge cases \u2014 they’re the ones nearly every React developer hits in their first few months, and several of them ship into production because nothing crashes when they’re wrong; the UI just quietly does the incorrect thing.<\/p>\n\n\n\n

The 8 demos below are all live and interactive, and every one that has a “broken” side keeps it running right next to the fix so you can watch the actual difference in behavior, not just read about it. Every embed also has a Fork & Edit<\/strong> button that opens the exact snippet, already running, in My Code<\/a> \u2014 webdevpuneet’s free in-browser editor. Change a dependency array, delete a cleanup function, see what breaks \u2014 that’s a faster way to build real intuition than any explanation.<\/p>\n\n\n\n

The one-sentence rule<\/h2>\n\n\n\n
useEffect(function () {\n  \/\/ runs after React commits this render to the screen\n  doSomething(value);\n\n  return function () {\n    \/\/ runs before the NEXT effect run, and once more on unmount\n    undoSomething();\n  };\n}, [value]); \/\/ React re-runs the effect only when something in THIS array changed<\/code><\/pre>\n\n\n\n
useEffect<\/code> is a way to say “after the screen updates, synchronize something outside React with what just changed” \u2014 a subscription, a timer, the document title, a network request. The dependency array is not a performance knob you can skip; it’s the actual list of values the effect closes over, and it’s how React decides whether to re-run. Get it wrong in either direction \u2014 too few values, or a value that changes identity every render even though its contents don’t \u2014 and the effect runs at the wrong time, not just too often or too rarely. Every demo below is one specific way that goes wrong, and the one-line fix for it.<\/p>\n\n\n\n
When should you actually use useEffect?<\/h2>\n\n\n\n
Half of the mistakes below aren’t really about dependency arrays or cleanup functions \u2014 they’re about reaching for an effect when nothing outside React was involved in the first place. Before writing one, it’s worth checking which category the logic actually falls into.<\/p>\n\n\n\n
Use an Effect for:<\/strong><\/p>\n\n\n\n
    \n
  • Synchronizing with an external system (a non-React widget, a map instance, a chart library)<\/li>\n\n\n\n
  • Subscriptions (WebSockets, event emitters, external stores)<\/li>\n\n\n\n
  • Timers (setInterval<\/code>, setTimeout<\/code> that needs to persist across renders)<\/li>\n\n\n\n
  • Browser APIs (document.title<\/code>, focus management, IntersectionObserver<\/code>)<\/li>\n\n\n\n
  • Network synchronization (fetching data that depends on props or state)<\/li>\n<\/ul>\n\n\n\n
    Don’t use an Effect for:<\/strong><\/p>\n\n\n\n
      \n
    • Calculating derived values (demo #6 below \u2014 just compute it during render)<\/li>\n\n\n\n
    • Handling user events (demo #7 below \u2014 put the logic in the handler that caused it)<\/li>\n\n\n\n
    • Transforming data for rendering (filtering, sorting, formatting \u2014 do it inline or with useMemo<\/code>)<\/li>\n\n\n\n
    • Updating state simply because another state changed (a giveaway that the “derived” state should be a calculation instead)<\/li>\n<\/ul>\n\n\n\n
      The syntax of useEffect<\/code> is genuinely small \u2014 a function and a dependency array. Most of the pain people associate with it actually comes from using it in the second list above, where no dependency array or cleanup function would have fixed the real problem: the effect shouldn’t have existed. Keep that distinction in mind as you go through the 8 demos \u2014 #1 through #5 are genuine effect mistakes (timing, closures, cleanup, race conditions), while #6, #7, and #8 are really about recognizing when an effect was the wrong tool to begin with.<\/p>\n\n\n\n
      1. No Dependency Array Runs After Every Single Render<\/h2>\n\n\n\n
      Both counters share one unrelated “tick” button. Watch the effect-run count on each side as you click it.<\/p>\n\n\n\n