One of the most unsettling warnings I’ve come across in React development is: “React Hook useEffect has a missing dependency.” At first glance, it felt like a suggestion I could ignore—something optional. But the more I ignored it, the more unpredictable my components became. Effects wouldn’t re-run when I expected them to, state would get stale, and in some cases, bugs would sneak in without warning.
This blog is a reflection of the rabbit hole I went down trying to understand this warning—why it appears, when it matters, and how I learned to respect it without letting it control my entire codebase.
How I Encountered the Warning
The first time I saw this warning was when I had written a simple useEffect that made an API call:
useEffect(() => {
fetchData();
}, []);
The fetchData function was defined outside the effect, and I had no idea why React complained about it. The warning told me to include fetchData in the dependency array. But when I did, the effect started firing in ways I hadn’t anticipated.
That’s when I realized I had stumbled onto something deeper. React wasn’t just pointing out a missing variable. It was warning me about a potential mismatch between the values used inside the effect and the values React was watching to determine when the effect should run.
Why useEffect Cares About Dependencies
Over time, I started thinking of useEffect as a camera that takes a snapshot of variables at a moment in time. When we use values inside the effect but don’t include them in the dependency array, we’re telling React: “Don’t worry, this value won’t change.” And if it does change, the effect won’t re-run—because React was never told to watch it.
This can create subtle bugs. Let’s say fetchData itself relies on some changing state. If the function is updated but not included in the dependencies, useEffect won’t know it should re-run. Instead, it’ll use the old version of fetchData, which might be operating on stale state.
This helped me understand why React’s ESLint rules for Hooks are so strict. It’s not just pedantic—it’s protective. The warning isn’t always about the current behavior being broken. It’s about guarding against future bugs that come from missing reactivity.
What Happened When I Ignored It
For a while, I kept resisting. I didn’t want my dependency array to grow unwieldy. And sometimes, including everything caused the effect to re-run more often than I wanted. So I’d add // eslint-disable-next-line just to silence the linter.
But that didn’t go well. I remember a situation where a value that was supposed to change inside the effect stayed stuck. The useEffect had captured the initial value, and since I’d ignored the warning, it never got updated. I lost hours debugging that issue.
Eventually, I stopped trying to silence the linter and started listening to it. I realized that it wasn’t about fixing the warning—it was about rethinking how I structured the code that needed it.
The Stable Function Trap
One tricky pattern I ran into involved defining functions outside useEffect and using them inside it. ESLint would complain about them missing in the dependency array. But adding them sometimes caused infinite loops, especially when the functions were recreated on each render.
To handle this, I started wrapping such functions with useCallback, which gave me control over when they changed:
const fetchData = useCallback(() => {
// some async logic
}, [id]);
Now, when I used fetchData in useEffect, it didn’t keep triggering because the function was memoized unless its dependencies changed. This simple shift helped me avoid unnecessary re-renders while staying compliant with the linter. It also made my code easier to test, especially when working on isolated logic like React interview questions for freshers or modular components.
When I Intentionally Left Dependencies Out
There were moments when I truly wanted the effect to run only once—like when I was fetching initial data. In these cases, I still needed to be careful. I would define any used functions inside the effect to avoid dependency issues altogether.
useEffect(() => {
const fetchData = async () => {
const response = await fetch('/api/data');
const result = await response.json();
setData(result);
};
fetchData();
}, []);
Because everything the effect needed was defined inside it, there were no dependencies to track. React was happy, and I didn’t need to ignore the linter. This became my go-to pattern when the logic didn’t need external values.
I explored this more deeply while working on React testing library queries, where function purity and effect dependencies became critical for avoiding side effects in unit tests.
The Role of ESLint and the Rules of Hooks
I used to see ESLint’s “Rules of Hooks” as annoyances. But over time, I began to appreciate them as safety nets. These rules are especially important when working on teams or returning to code months later. They make sure every hook behaves in a way that’s predictable.
When the warning shows up, it means there’s a mismatch between what the effect uses and what it’s watching. And even if nothing breaks right away, the future version of me—or my teammate—might unknowingly make a change that leads to bugs.
Following these rules not only prevented bugs but made my code more understandable. It became easier to refactor, test, and extend. When I worked with newer React APIs like useActionState or modern practices for testing, I realized just how foundational this dependency management was. I remember reading through React’s official quiz and seeing this exact issue show up in tricky form—proving it’s not just a beginner mistake but something worth mastering.
Final Thoughts
Understanding and resolving the “React Hook useEffect has a missing dependency” warning took more than just fixing syntax—it required shifting the way I thought about effects, data flow, and reactivity. It’s not a bug to patch but a design pattern to embrace.
React’s model is built on predictability and consistency. And honoring dependencies in useEffect—even when it feels a little strict—has helped me write cleaner, safer, and more maintainable code.
