What are common pitfalls with the useEffect dependency array and cleanup?

Question

Accepted Answer

An effect re-runs based on its **dependencies**, and getting that array wrong is the #1 source of React bugs.

## Pitfall 1: missing dependencies → stale values

An effect closes over the values from the render it was created in. If you omit a dependency, it keeps using an old one:

```jsx
useEffect(() => {
  const id = setInterval(() => {
    console.log(count); // ❌ always logs the count from the FIRST render (0)
  }, 1000);
  return () => clearInterval(id);
}, []); // empty deps → effect never re-created → `count` frozen at 0
```

Fix: either add `count` to deps, or use a functional updater that doesn't need it (`setCount(c => c + 1)`).

## Pitfall 2: unstable dependencies → effect runs every render

Objects/arrays/functions are recreated on each render, so they're "new" every time and the effect never settles:

```jsx
const options = { id }; // ❌ new object every render
useEffect(() => { load(options); }, [options]); // runs every render
```

Fix: depend on the primitive (`[id]`), or memoize with `useMemo`/`useCallback`.

## Pitfall 3: forgotten cleanup → leaks & races

```jsx
useEffect(() => {
  const ctrl = new AbortController();
  fetch(url, { signal: ctrl.signal }).then(setData);
  return () => ctrl.abort(); // cancels the old request when `url` changes
}, [url]);
```

Without the cleanup, a slow earlier request could resolve *after* a newer one and overwrite fresh data (a race condition), and subscriptions/timers would pile up. The `react-hooks/exhaustive-deps` ESLint rule catches most missing-dependency cases.