React’s useEffect hook is one of the most powerful — yet misunderstood — tools in the developer toolkit. While it simplifies side effects in function components, it also opens the door to subtle bugs and performance issues when used carelessly. In my journey building multiple React apps, I’ve stumbled upon a few common mistakes that caused unnecessary rerenders, stale data issues, and even infinite loops. Understanding these missteps helped me write cleaner, more stable code. Here are the top five mistakes I believe every developer should avoid when working with useEffect.
Ignoring the Dependency Array
One of the earliest mistakes I made was either forgetting the dependency array or misusing it. Leaving it out entirely means useEffect runs after every render, which may not be what you want. On the flip side, providing an incomplete array can lead to stale props or state being referenced inside the effect.
There was a time when I thought, “Well, I don’t want it to rerun, so I’ll just pass an empty array.” But then I found myself debugging why updated props weren’t triggering the effect. Eventually, I realized that understanding dependency tracking is critical — and tools like the React Hook ESLint plugin are not suggestions, they’re life-savers.
While debugging a component recently, I ran into a subtle issue caused by an overlooked variable inside the dependency list. It didn’t crash anything, but the component silently behaved incorrectly — a classic example of how even a small missing dependency can lead to inconsistent behavior.
Making the Effect Function Async
At some point, I needed to fetch data inside useEffect, and I instinctively wrote useEffect(async () => { ... }). It looked fine. It even worked — sometimes. But I soon discovered React doesn’t support async functions directly inside useEffect because the function should return either undefined or a cleanup function — not a Promise.
The more reliable approach is defining an inner function and invoking it right away. That small refactor eliminates the subtle problems and makes the logic much easier to follow. Especially when working with APIs or loading screens, I’ve found that this style of async handling in useEffect results in more stable UI logic and helps prevent unhandled promise warnings that used to pop up during early testing. It becomes even more important in cases involving chained data loads or when introducing async/await logic that might depend on external inputs.
Overusing useEffect for State Derivation
There were times when I derived a piece of state from props or another state variable — and immediately reached for useEffect. For example, syncing a filtered array from a list of users and a search term. It worked, but it was messy. It added unnecessary complexity and an extra render cycle.
Eventually, I learned that if a value can be derived from the render scope, it shouldn’t live in an effect. Instead, pure functions or memoization tools like useMemo usually make more sense. This small adjustment brings the component closer to React’s core philosophy — declarative logic and predictable updates. That mindset shift helped reduce overengineering, especially in scenarios where I previously used useEffect almost out of habit. It’s also part of what makes React such a preferred framework for developers — this balance of power and predictability is a big part of why it’s so widely adopted.
Not Cleaning Up Side Effects
One of the most overlooked issues is forgetting to return a cleanup function. I remember when I added a setInterval inside useEffect to update a countdown timer and didn’t think to clear it. The result? Memory leaks and unexpected behavior when navigating between components.
React expects effects to clean up after themselves — especially when dealing with timers, subscriptions, or event listeners. Forgetting cleanup can result in effects stacking on top of each other, firing multiple times, or consuming memory over time.
Now, whenever I use anything async or long-living inside useEffect, the first thing I ask myself is, “Does this need to be cleaned up?” If yes, I return a cleanup function and test unmount scenarios thoroughly.
Triggering Unnecessary Re-renders
Another mistake I’ve made — and seen others make — is triggering state updates inside useEffect that themselves cause the same useEffect to rerun. This creates a loop that is hard to spot at first but quickly spirals into performance issues.
One example was setting state using data fetched inside the effect, but accidentally including the same state in the dependency array. The effect would run, fetch data, set state, re-trigger, and so on. Once I learned to decouple these flows — and to carefully evaluate the dependencies — I avoided these cycles.
Sometimes, the problem isn’t even a direct loop — just a stale closure or an unnecessary dependency on a new function that changes every render. These are subtle mistakes, but they tend to creep into real-world code, especially under pressure. Many interview questions now include these scenarios because they test more than syntax — they reveal whether you’ve truly built and debugged real components, much like the ones covered in React interview assessments that focus on effect performance and state management.
Final Thoughts
Learning to use useEffect properly has been one of the biggest mindset shifts for me as a React developer. It’s tempting to use it like a Swiss army knife for all logic outside rendering, but it pays off to be more intentional. Whenever I reach for useEffect, I pause and ask: is this a side effect or just derivation? Am I tracking dependencies correctly? Can I break this into smaller effects?
For anyone looking to reinforce their knowledge, quick self-assessments can go a long way. I often revisit short quizzes or debugging scenarios to keep the core ideas fresh — especially as React continues to evolve. One great way to do that is with this interactive React quiz that focuses on patterns we often miss in daily coding.
Thoughtful useEffect usage doesn’t just improve code quality — it dramatically boosts confidence in how your components behave, scale, and perform.
