Wat zijn veel voorkomende valkuilen met de useEffect dependency array en cleanup?

Question

Accepted Answer

Een effect wordt opnieuw uitgevoerd op basis van zijn **dependencies**, en een fout in die array is bron #1 van React-bugs.

## Waarom het belangrijk is

### Valkuil 1: ontbrekende dependencies → verouderde waarden

Een effect sluit af over de waarden van de render waarin het werd gemaakt. Als je een dependency weglaat, blijft het een oude gebruiken:

```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: voeg `count` toe aan deps, of gebruik een functional updater die het niet nodig heeft (`setCount(c => c + 1)`).

### Valkuil 2: instabiele dependencies → effect draait elke render

Objecten/arrays/functies worden bij elke render opnieuw aangemaakt, dus ze zijn elke keer "nieuw" en het effect stabiliseert zich nooit:

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

Fix: hang af van de primitive (`[id]`), of gebruik memoization met `useMemo`/`useCallback`.

### Valkuil 3: vergeten 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]);
```

Zonder cleanup kon een traag eerder verzoek oplossen *na* een nieuwer verzoek en verse gegevens overschrijven (een race condition), en subscriptions/timers zouden zich opstapelen. De `react-hooks/exhaustive-deps` ESLint-regel vangt de meeste ontbrekende dependency-gevallen.