React useEffect Common Mistakes

In the last lesson you learned about React Fetching Data with useEffect. Now this lesson is a practical checklist of the common useEffect bugs, with the wrong way and the quick fix for each.

🔁 Mistake 1: the infinite loop

This is the scary one. Your effect sets state, and that state change re-runs the effect, which sets state again, forever.

• The effect calls setCount, which causes a re-render.
• After the render React checks the dependency array. With no array, it runs the effect on every render.
• So it sets state, re-renders, runs again, sets state again. The loop never stops and the page freezes.

The trap is leaving the dependency array out while setting state inside. That’s an infinite loop.

Here’s the broken version and the fix side by side.

// ❌ Wrong - no dependency array, so it sets state and re-runs forever
useEffect(() => {
  setCount(count + 1);
});

// ✅ Right - run once with [], or compute the value during render instead
useEffect(() => {
  setCount(1);
}, []);

So the fix is to give the effect the right dependencies.

• If something should happen only once, use an empty array.
• And honestly, if you’re just calculating a value from other state, you usually don’t need an effect at all. We’ll come back to that idea in the next lesson.

📭 Mistake 2: missing dependencies

You already met this one in the deps lesson. You leave a value out of the array, and the effect keeps using an old, frozen copy of it.

• The effect reads userId, but the array is empty.
• An empty array means run once, so the effect never re-runs when userId changes.
• It keeps fetching for the very first userId, even after the user switches accounts. That’s a stale value.

Look at the broken version next to the fix. The only change is what’s inside the array.

// ❌ Wrong - effect uses userId, but it's not in the array
useEffect(() => {
  fetchProfile(userId);
}, []); // keeps fetching the first userId forever

// ✅ Right - list userId, so it re-fetches when the user changes
useEffect(() => {
  fetchProfile(userId);
}, [userId]);

So the rule from the React useEffect Dependencies lesson still holds.

• If the effect uses a value, list it.
• Let the exhaustive-deps lint rule catch the ones you miss.

🧹 Mistake 3: forgetting cleanup

This is the one from the cleanup lesson. Your effect starts something that keeps running, but nothing stops it.

• You start a timer with setInterval, but you never clear it.
• When the effect runs again, it starts a second timer on top of the first.
• Old timers keep firing, so you get double and triple updates, plus a memory leak.

Here’s the version with no cleanup next to the version that returns one.

// ❌ Wrong - no cleanup, so timers pile up and never stop
useEffect(() => {
  setInterval(() => setSeconds((s) => s + 1), 1000);
}, []);

// ✅ Right - return a cleanup that clears the timer
useEffect(() => {
  const id = setInterval(() => setSeconds((s) => s + 1), 1000);
  return () => clearInterval(id);
}, []);

So anything you start in an effect, you stop in the cleanup. Timers, event listeners, subscriptions, all of them. The full pattern is back in the React useEffect Cleanup Function lesson.

🆕 Mistake 4: deps that change every render

This one is sneaky because the dependency looks correct. You put an object, an array, or a function in the array, but it’s brand new on every render.

• Objects, arrays, and functions created inside the component are made fresh each render.
• Even if the contents look the same, it’s a new value in memory, so React’s check sees it as changed.
• So the effect re-runs on every single render, just like the infinite-loop case. That’s an unstable dependency.

Here’s the object rebuilt each render, then a simple fix.

// ❌ Wrong - a new object every render, so the effect runs every render
const options = { sort: "asc" };
useEffect(() => {
  runSearch(options);
}, [options]);

// ✅ Right - depend on the plain value inside, not the whole object
const sort = "asc";
useEffect(() => {
  runSearch({ sort });
}, [sort]);

So the quick fix here is small.

• Depend on the simple value inside, like a string or a number, instead of the whole object.
• For objects and functions you really do need to keep stable, React has useMemo and useCallback, which come later in the course.

⏳ Mistake 5: making the effect callback async

You want to fetch data, so you reach for async and put it right on the effect function. That looks natural, but it breaks the rules of useEffect.

• The effect is supposed to return either nothing or a cleanup function.
• An async function always returns a promise, not a cleanup function. So React gets the wrong thing back.
• React can’t use that promise to clean up, and you get a warning.

The fix is to put an async function inside the effect and call it, instead of making the effect itself async.

// ❌ Wrong - the effect callback itself is async
useEffect(async () => {
  const data = await fetchUser(id);
  setUser(data);
}, [id]);

// ✅ Right - define an async function inside, then call it
useEffect(() => {
  async function loadUser() {
    const data = await fetchUser(id);
    setUser(data);
  }
  loadUser();
}, [id]);

So the effect callback stays normal, and the async work lives in a function inside it. Now the effect can still return a real cleanup if it needs one, and React stays happy.

🧩 What You’ve Learned

• ✅ Setting state in an effect with no dependency array creates an infinite loop, so give it the right deps or run it once with []
• ✅ Leaving a value out of the array gives you a stale value, so list everything the effect uses
• ✅ Forgetting cleanup leaves timers, listeners, and subscriptions running, so return a cleanup that stops them
• ✅ An object, array, or function created in the component is new every render, so depend on the plain value inside instead
• ✅ Never make the effect callback async directly, define an async function inside and call it
• ✅ Most of these bugs trace back to the dependency array and cleanup, so trust the exhaustive-deps lint rule

🚀 What’s Next?

Now you can spot the common useEffect mistakes and fix each one fast. But the biggest lesson hiding behind all of them is this: a lot of effects shouldn’t be effects at all. Next you’ll learn when to skip useEffect completely.

React When Not to Use useEffect