15 common useEffect mistakes to avoid in your React apps

The React community seems divided on the useEffect Hook. Often you will hear things like “Stop using useEffect!” – as if it’s a bad Hook. But the truth is, the problem is not with the Hook itself, but with how developers use (and overuse) it.

useEffect has been abused so much that it’s now associated with unnecessary re-renders, wasted computations, and slow apps.

So let’s fix that. We’ll break down the confusion, clear up misconceptions, and go over 15 common mistakes I’ve seen repeatedly in React apps I’ve reviewed.

If you’re a dev leader, there’s a good chance your team might be making some of these common useEffect mistakes. There’s a lot of confusion in the React community around when and how to use useEffect, so it’s easy for issues to slip into production code.

A good rule of thumb: useEffect should be the exception, not the default. If you see it popping up often, ask whether it’s really the right tool for the job.

Share this post with your team so that it can help them understand when useEffect is necessary and when it’s being misused.

Understanding useEffect: Unlearning old patterns

One of the biggest sources of confusion comes from comparing React Hooks to the lifecycle method in class components.

But there’s a critical distinction. Many developers mistakenly believe that useEffect equals componentDidMount + componentDidUpdate. This is wrong.

• componentDidMount and componentDidUpdate run synchronously after DOM updates but before browser paint.
• useEffect runs after the browser has painted the screen.

The key distinction is that useEffect is non-blocking and runs asynchronously after paint, while class lifecycle methods run synchronously. This timing difference is crucial. If you use useEffect to run effects that should happen before paint, your effects may run too late, causing visual flickers or layout issues.

In short: useEffect is not the same as componentDidMount/Update.

Three questions to ask before you use useEffect

Every time you consider using useEffect, ask these three fundamental questions:

Q1. Is there an external system?

useEffect is designed to synchronize your React component with external systems. What counts as an external system?

• Network: APIs, WebSockets, Server-Sent Events
• Browser APIs: DOM manipulation, localStorage, geolocation
• Third-party libraries: Analytics, chat widgets, maps
• Subscriptions: Real-time databases, event streams

Rule: If you do not need an external system, you probably don’t need useEffect.

Q2. Who triggers this?

If an external system is involved, you must determine the trigger: what should cause this effect to run?

1. User action: If the user has taken an action, such as clicking an item or typing, you need an event handler, not an effect.
2. Component lifecycle: If the effect should run because the user has landed on a page, or because the page should do an action in the background regardless of user activity, you likely need an effect, but ask the second follow-up.

Q3. How is the value calculated?

1. Derived from props/state: If the value you are computing is derived directly from props or state, you should calculate it directly during the render, not inside an effect.
2. Requires cleanup: If your effect performs an action that allocates a resource or creates a persistent connection, it requires cleanup to prevent resource leaks. If the component unmounts, that resource must be released:

The 15 most common useEffect mistakes

I reviewed several open-source projects, including those created for personal or side projects, as well as community-led initiatives. This helped me identify patterns in how useEffect and other Hooks are used. I’ve noticed some common anti-patterns. Let’s break them down:

Category 1: Dependency mismanagement

Mistake 1: Missing dependency array causing infinite rendering

This occurs when a state update is triggered inside an effect, and that effect is not controlled by a dependency array, causing the component to perpetually re-render. This results in an “infinite render problem.”:

// ❌ DON'T: Causes infinite loop
function Counter() {
  const [count, setCount] = useState(0);


  useEffect(() => {
    setCount(count + 1); // Triggers re-render → runs effect → triggers re-render...
  }); // No dependency array!


  return <div>{count}</div>;
}

The Fix: Add an empty dependency array to run only on mount:

// ✅ DO: Runs only once on mount
function Counter() {
  const [count, setCount] = useState(0);


  useEffect(() => {
    setCount(count + 1);
  }, []); // Empty array = run once on mount


  return <div>{count}</div>;
}

Mistake 2: Stale state values

The Problem: Reading state inside an effect that was just updated causes unnecessary renders and shows stale values.

Example:

// ❌ Mistake: reading stale 'user' right after setting it

function Component() {
  const [user, setUser] = useState(null);


  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then(res => res.json())
      .then(data => {
        setUser(data);
        console.log("Fetched user:", user); // stale value (still null!)
      });


  }, []);
  return <div>{user.name}</div>;
}

✅ The Fix: Use the data directly or react to changes properly

function Component() {
  const [user, setUser] = useState(null);


  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then(res => res.json())
      .then(data => {
        if (!isMounted) return;
                setUser(data);
      });
  }, []);


    // ✅ Log when 'user' actually updates
  useEffect(() => {
    if (user) {
      console.log("Fetched user:", user);
    }
  }, [user]);


  return <div>{user.name}</div>;

Now:

• The console.log runs only after user has updated.
• No stale reads.
• No unnecessary re-renders.

Mistake 3: Stale props

When fetching data based on props, omitting that prop from the dependency array means the effect will only run once on mount, regardless of changes to the prop. This can cause stale data:

// ❌ DON'T DO THIS
function Temp2({ userId }) {
  // ...
  useEffect(() => {
    fetchUser(userId);
  }, []); // Missing userId dependency!
  // ...
}

If the userId prop changes, the effect will not re-run, and the component will be stuck using the stale data fetched with the original userId. The fix is simple: add userId to the dependency array.

The Fix: Add any props you need to the dependency array:

// ✅ DO THIS

 function Temp2({ userId }) {
  // ...
  useEffect(() => {
    fetchUser(userId);
  }, [userId]); // Fixed userId dependency!
  // ...
}

Please note: These errors are easy to avoid by enabling the eslint plugin: eslint-plugin-react-hooks

Mistake 4: using multiple useEffects for chained reactions

If multiple effects react to the same dependency, they should be combined into a single effect:

// ❌ DON'T DO THIS: Multiple useEffects with same dependency
function Temp2({ userId }) {
  // ...
  useEffect(() => {
    fetchUser(userId);
  }, [userId]); 


  useEffect(() => {
    getProfilePicture(userId);
  }, [userId]); 


  useEffect( () => {
  setLoginInfo(userId);
  }, [userId]);




}

Each effect above runs whenever userId changes, meaning React has to schedule and clean up three separate effects for the same trigger.

Instead, combine them into one:

// ✅ DO THIS: Single effect for related dependencies
function Temp2({ userId }) {
  // ...
  useEffect(() => {
    fetchUser(userId);
    getProfilePicture(userId);
    setLoginInfo(userId);
  }, [userId]); 


}

This reduces overhead, makes your code easier to reason about, and ensures all logic responding to userId updates happens together.

Side note: if effects are unrelated (e.g. one updates analytics, another subscribes to a WebSocket), keep them separate for clarity.

Mistake 5: Unstable dependencies of objects and functions

Objects and functions created during render are treated as new references by JavaScript on every render, even if their contents haven’t changed. Including them in the dependency array will cause the effect to re-run unnecessarily, leading to excessive data fetching:

// ❌ DON'T DO THIS: User is an unstable object reference
const user = { userId: 123, profile: {}};

useEffect(() => {
  fetchUser(user.userId);
}, [user]);

To fix this, only pass the stable primitive properties you need, such as user.id. Instead of adding the entire object in your dependency, only add the actual property that you need:

// ✅ DO THIS: Use primitive value
const user = { userId: 123, profile: {}};

useEffect(() => {
  fetchUser(userId);
}, [userId]);

If you do need to add the function, you should memoize it using useCallback:

// Use useCallback for unstable function references
const fetchUserProfileMemoized = useCallback(
  () => {
    // fetch logic
  },
  [
    /* dependencies */
  ],
);

useEffect(() => {
  fetchUserProfileMemoized();
}, [fetchUserProfileMemoized]);

Note: With React Compiler enabled in modern React versions (React 17, 18, 19), the compiler can handle this automatically.

Category 2: Misusing Effects for derived state

Mistake 6: Calculating derived state in useEffect

This is perhaps the most frequent misuse of the Hook. If you need to update one piece of state based on changes to props or another piece of state, you should derive it directly during rendering.

For instance, calculating a fullName from firstName and lastName inside an effect is considered redundant and unnecessary:

// ❌ AVOID: Redundant state and unnecessary effect
function EventTeam({ isOnTeam }) {

const [onTeam, setOnTeam] = useState(isOnTeam);

    useEffect(() => {
        setOnTeam(isOnTeam);
    }, [isOnTeam])
}

The correct approach is to calculate it during rendering:

// ✅ CORRECT: Calculated during rendering. Does not need a useState or useEffect
const onTeam = isOnTeam;

Mistake 7: Unnecessary dependencies

Sometimes, we need a value to be reactive to prop change. It is a common mistake to add an additional dependency on useEffect to ensure it re-runs on prop change:

// ❌ AVOID: Doesn't need a useEffect
function EventTeam({ isOnTeam, isHelping }) {
const [onTeam, setOnTeam] = useState(isOnTeam);

    useEffect(() => {
        setOnTeam(isOnTeam);
    }, [isOnTeam, isHelping])


}); 

Since the component re-renders when prop changes, we do not need a useEffect for this:

// ✅ FIX: Calculate isOnTeam directly from props. 

function EventTeam({ isOnTeam, isHelping }) {
const onTeam = isOnTeam;
});

Mistake 8: Resetting state/cache

A common mistake is to use useEffect to reset state variables when certain props change:

// AVOID: Unnecessary state reset inside effect
function Temp2({ hackathon }) {
  const [judgeDetailsCache, setJudgeDetailsCache] = useState([]);
  const [panelAssignmentsCache, setPanelAssignmentsCache] = useState([])


 // Problem: This causes an extra render and temporary inconsistent state

  useEffect(() => {
    // Clear caches when hackathon changes
    setJudgeDetailsCache([]);
    setPanelAssignmentsCache([]);
  }, [hackathon]);


    // Fetch judge details...
  useEffect(() => {
    fetchJudgeDetails(hackathon.id).then(setJudgeDetailsCache);
  }, [hackathon.id]);

}

Here, the intention is that each hackathon should have its unique judgesDetails and panelAssisgments

Fix: You can use a key to let React know that each hackathon.id is a different and unique component:

<Temp2 key={hackathon.id} hackathon={hackathon} />

React treats different keys as different components. When hackathon.id changes, React unmounts the old Temp2 instance and mounts a new one. New mount means fresh state, therefore useState initializers run again with empty arrays.

With this, you can do:

// ✅ GOOD: Let React handle the reset via key
function Temp2({ hackathon }) {
  const [judgeDetailsCache, setJudgeDetailsCache] = useState([]);
  const [panelAssignmentsCache, setPanelAssignmentsCache] = useState([]);


  // No manual reset needed! State starts fresh when key changes


  useEffect(() => {
    fetchJudgeDetails(hackathon.id).then(setJudgeDetailsCache);
  }, [hackathon.id]);


  return (
    <div>
      {judgeDetailsCache.map(judge => <div key={judge.id}>{judge.name}</div>)}
    </div>
  );
}

⚠️ Caveat:

The key approach remounts the entire component, which means:

• All state resets (not just the caches)
• All effects re-run (including data fetching)
• DOM nodes are destroyed and recreated

This is usually what you want when a prop fundamentally changes the component’s identity. If you only need to reset some state while preserving other state, then useEffect might still be appropriate

Category 3: Failure to clean up

When useEffect is used to subscribe to external systems such as APIs, DBs, and WebSocket connections, failing to properly handle cleanup for external system interactions can lead to memory leaks and unexpected behavior.

Mistake 9: Failing to cancel fetch requests

When performing data fetching, failing to cancel the request if the component unmounts while the request is still pending can lead to stale fetch requests.

To fix this, you must use an AbortController and return a cleanup function that aborts the request:

useEffect(
  () => {
    const controller = new AbortController();
    fetch(URL, { signal: controller.signal });
    // ... then continue with response handling

    return () => {
      controller.abort(); // Cleanup function cancels the request on unmount/re-render
    };
  },
  [
    /* dependencies */
  ],
);

Mistake 10: Setting state after request completion

Even with the AbortController, if you update state upon request completion, such as setting loading to false, you might still risk a memory leak if the component unmounts right before the response is processed.

To fix this, use a mutable flag, like isMounted, managed within the cleanup function:

useEffect(() => {
  let isMounted = true;
  // ... fetch logic ...
    .then(data => {
      if (isMounted) {
        setNewsData(postsData);
        // ... set other states
      }
    });

  return () => {
    isMounted = false; // Set to false on cleanup
    // ... abort controller logic
  };
}, [/* dependencies */]);

This way, you check to make sure that the component is mounted before we call any set state[s].

Mistake 11: Failing to remove event listeners

Suppose your effect adds an external event listener (e.g., to the window or document). In that case, you must remove it in the cleanup function to prevent it from leaking memory and causing unintended side effects across your application:

useEffect(() => {
  window.addEventListener('resize', onResize);

  return () => {
    // Make sure we remove event listener on unmount
    window.removeEventListener('resize', onResize);
  };
}, [onResize]);

Category 4: Using useEffect for things it’s not supposed to be used for

Mistake 12: Using useEffect for event-specific logic

If you use useEffect to watch for a state change that was triggered by a user action (like showing a notification when an item is added to a cart), you’re misapplying the Hook:

// ❌ AVOID: Event-specific logic inside an effect
useEffect(() => {
  if (product.isInCart) {
    showNotification(`Added ${product.name} to the shopping cart!`);
  }
}, [product.isInCart]);

This logic belongs directly in the event handler function that triggered the cart change.

Mistake 13: Overusing effect for initializing libraries

If you initialize an entire third-party library or service that should only run once per application load, putting that logic in every component via useEffect is inefficient:

// ❌ AVOID: Initializing app-level services in component effects. 
useEffect(() => {
  initFacebookPixel();
  mermaid.initialize({...});
}, []);

Instead, this global initialization should be moved to a single high-level component, such as App.tsx, and wrapped with a flag to ensure it only runs once per session:

// ✅ FIX: Initiliaze once at App level after checking if initialized before

//App.tsx
useEffect(() => {

if(!isAppInitialized) { //isAppInitialized should be a singleton
  initFacebookPixel();
  mermaid.initialize({...});
  }
}, []);

Mistake 14: When useEffect is not the right hook for the job

Remember, useEffect runs after the browser paints. If you are dealing with DOM manipulation or measurement, such as calculating a tooltip’s position, you need to run the logic before the visible paint step to avoid flickering.

In these specific scenarios, using useLayoutEffect is the correct approach. useLayoutEffect is a version of useEffect that fires before the browser repaints the screen.

Similarly, Hooks such as useSyncExternalStore, are made specifically meant for working with external stores. This Hook is better than useEffect, because  useSyncExternalStore ensure that the subscription callback is only fired once.

These specialized hooks are often better than useEffect.

Mistake 15: useEffectEvent for non-Reactive logic (React 19.2+)

For complex scenarios like tracking analytics, where you need to read the latest props/state values without forcing the effect to re-run every time those values change, React has introduced useEffectEvent.

The useEffectEvent Hook lets you extract non-reactive logic from your Effects into a reusable function called an Effect Event.

By wrapping the tracking logic in useEffectEvent, you ensure that the event handler function always reads the latest props (like step and enhancedMetadata) without needing to add them to the effect’s dependency array. This prevents needless re-runs while maintaining data integrity.

Conclusion

Fixing these common mistakes will lead to cleaner, faster, and more maintainable React applications. While data fetching libraries offer solutions for many of the cleanup and caching problems associated with useEffect, understanding the core rules of the Hook is essential for mastering React development.

Although useEffect is a commonly misused Hook, helping teams understand its common pitfalls can prevent mistakes and improve existing code. Developer leaders can use these insights to guide their teams, foster better coding practices, and ensure Hooks are used effectively across projects.