React useEffect richtig nutzen: Dependencies, Closures und Cleanup ohne Endlosschleifen

Einleitung

useEffect ist das Verbindungsglied zwischen React-Komponenten und der Außenwelt: Events abonnieren, Daten laden, Timer starten, DOM- oder API-Integrationen koordinieren. Gleichzeitig ist es die häufigste Fehlerquelle in Hooks-basierten Apps. Dieses Tutorial fasst die praxiserprobten Muster aus der offiziellen Dokumentation zusammen und zeigt, wie du Dependencies richtig setzt, stale closures vermeidest, Cleanups robust implementierst, StrictMode-Doppelaufrufe in Development einordnest, Fetches mit AbortController sauber abbrichst und typische Endlosschleifen entschärfst.

Voraussetzungen und Kontext

• React 18+ oder 19 im Client, Development i. d. R. mit <StrictMode> aktiviert.
• Grundkenntnisse: Hooks (useState, useEffect, useRef), Promises/fetch.
• Linter-Konfiguration mit eslint-plugin-react-hooks empfohlen.

Siehe auch die offiziellen Referenzen weiter unten für tiefergehende Details zu useEffect, <StrictMode>, useCallback, useMemo und AbortController.

Grundlagen: Semantik von useEffect und das Dependency-Modell

useEffect(setup, deps?) synchronisiert eine Komponente mit einem externen System. React führt die Setup-Funktion nach dem Commit aus. Optional kann sie eine Cleanup-Funktion zurückgeben, die vor dem nächsten Setup und beim Unmount aufgerufen wird. Details: React useEffect Referenz.

Wichtiges zum Dependency-Array:

• Liste aller reaktiven Werte, die im Effekt verwendet werden (Props, State, lokale Variablen/Funktionen aus dem Component-Body).
• React vergleicht Dependencies via Object.is. Ändert sich eine, läuft der Effekt erneut.
• Auslassen des Arrays => Effekt nach jedem Commit; leeres Array => nur beim Mount (plus StrictMode-Sonderfall im Development).

Tipp: Das Lint-Rule-Set „exhaustive-deps“ des offiziellen Plugins markiert fehlende Abhängigkeiten und hilft, subtile Bugs früh zu vermeiden: eslint-plugin-react-hooks/exhaustive-deps.

Bevor du überhaupt einen Effekt schreibst, prüfe: Geht es wirklich um Synchronisation mit etwas Externem? Pure Datenableitungen gehören oft in Renderlogik oder useMemo, nicht in useEffect.

Stale closures: Ursachen, typische Symptome und sichere Muster

Stale closures entstehen, wenn ein in einem Effekt definiertes Callback (Timer, Event-Handler, Promise-Callback) alte Werte eingefangen hat. Typisches Symptom: Eine setInterval-Funktion loggt dauerhaft einen veralteten Zählerstand.

Fehlerhaftes Beispiel (stale closure):

import { useEffect, useState } from 'react';

export function CounterBroken() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const id = setInterval(() => {
      // count ist aus der Initial-Render-Closure und bleibt „alt"
      console.log('Count (broken):', count);
    }, 2000);
    return () => clearInterval(id);
  }, []); // fälschlich leer

  return (
    <button onClick={() => setCount(c => c + 1)}>+1</button>
  );
}

Korrekte Lösung: Dependencies angeben, damit das Callback die aktuellen Werte sieht und der Timer sauber neugestartet wird.

export function CounterFixed() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const id = setInterval(() => {
      console.log('Count (fixed):', count);
    }, 2000);
    return () => clearInterval(id);
  }, [count]);

  return (
    <button onClick={() => setCount(c => c + 1)}>+1</button>
  );
}

Weitere sichere Muster gegen stale closures:

• Funktionale State-Updates: setX(prev => compute(prev)) stellen sicher, dass du den jüngsten State verwendest, auch in verzögerten Callbacks.
• useRef für mutable Werte, die nicht re-rendern sollen: ref.current ist immer aktuell und vermeidet stale closures für „letzte bekannte Werte“.
• Dependencies korrekt pflegen und das Linting ernst nehmen.

Ein praktischer Timer-Vergleich:

// Ohne stale closure, da der nächste Wert aus prev berechnet wird
import { useEffect, useState } from 'react';

export function TickEverySecond() {
  const [sec, setSec] = useState(0);
  useEffect(() => {
    const id = setInterval(() => setSec(s => s + 1), 1000);
    return () => clearInterval(id);
  }, []);
  return <span>{sec}s</span>;
}

Cleanup-Funktionen richtig implementieren und testen

Cleanup macht Effekte reversibel: Verbindungen schließen, Listener entfernen, Timer/Requests abbrechen. Best Practices:

• Immer einen Cleanup zurückgeben, wenn der Effekt externe Ressourcen anlegt.
• Idempotent schreiben: Ein doppelter Aufruf darf keinen Fehler verursachen.
• Alle Pfade abdecken, inkl. Fehler- oder Abbruchpfade.

Beispiel: Event-Listener und WebSocket-Verbindung.

import { useEffect } from 'react';

export function ChatClient({ url }: { url: string }) {
  useEffect(() => {
    const socket = new WebSocket(url);
    const onMessage = (e: MessageEvent) => {
      console.log('msg', e.data);
    };

    socket.addEventListener('message', onMessage);

    return () => {
      socket.removeEventListener('message', onMessage);
      // idempotent implementieren: mehrfaches close() sollte keine Fehler verursachen
      try { socket.close(); } catch {}
    };
  }, [url]);

  return null;
}

Teste Cleanups im Development mit StrictMode-Doppelaufrufen (siehe unten). Wenn Setup/Cleanup dort robust sind, bist du in der Regel auch für Produktionswechsel gerüstet.

Fetching in useEffect: AbortController und Race-Conditions vermeiden

Bei Prop- oder State-Änderungen können mehrere gleichzeitige Requests starten. Ohne Abbruch drohen:

• unnötige Arbeit und potenzieller unnötiger Ressourcenverbrauch,
• vertauschte Antworten (Race-Conditions),
• State-Updates nach Unmount oder für veraltete Requests.

Lösung: AbortController einsetzen, signal an fetch übergeben und im Cleanup abort() aufrufen. Grundlagen siehe MDN: AbortController.

Robustes Muster mit Lade-/Fehlerzustand (angepasst, damit bei abgebrochenen Requests loading nicht fälschlich zurückgesetzt wird):

import { useEffect, useState } from 'react';

type User = { id: string; name: string };

export function UserView({ id }: { id: string }) {
  const [data, setData] = useState<User | null>(null);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    const ctrl = new AbortController();
    setLoading(true);
    setError(null);

    fetch(`/api/users/${id}`, { signal: ctrl.signal })
      .then(async (res) => {
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        return (await res.json()) as User;
      })
      .then((user) => {
        // Nur wenn der Request nicht abgebrochen wurde, State setzen
        if (!ctrl.signal.aborted) setData(user);
      })
      .catch((err: unknown) => {
        // Abbruch über das Signal erkennen: keine Fehlerbehandlung nötig
        if (ctrl.signal.aborted) return;
        // Sonst echten Fehler melden
        setError((err as Error).message || 'Unknown error');
      })
      .finally(() => {
        // Nur loading zurücksetzen, wenn dieser Request nicht abgebrochen wurde
        if (!ctrl.signal.aborted) setLoading(false);
      });

    return () => ctrl.abort();
  }, [id]);

  if (loading) return <p>Lädt…</p>;
  if (error) return <p>Fehler: {error}</p>;
  if (!data) return null;
  return <p>{data.name}</p>;
}

Damit reduzierst du das Risiko von State-Updates für veraltete oder abgebrochene Requests und verhinderst, dass ein abgebrochener alter Request den Ladezustand einer neu gestarteten Anfrage überschreibt.

StrictMode in Development: Doppelaufrufe verstehen und idempotente Effekte schreiben

<StrictMode> aktiviert im Development Extratests: Unter anderem führt React Effekte einmal zusätzlich mit sofortigem Cleanup aus, um fehlende Aufräumlogik aufzudecken. Das passiert nur in Development und nicht im Produktionsbuild. Details: React <StrictMode>.

Konsequenz: Du siehst ggf. doppeltes Verbinden/Trennen, doppeltes fetch, doppelte Subscriptions. Korrigiere Effekt-Implementierungen so, dass Setup und Cleanup sich sauber spiegeln und mehrfaches Ausführen keine Seiteneffekte zurücklässt. Danach verschwindet das auffällige Verhalten automatisch im Produktionsbuild.

Debugging-Tipp: Logge innerhalb von Setup und Cleanup, um Reihenfolge und Idempotenz zu überprüfen. Häufige Fehler (z. B. fehlendes removeEventListener) werden so schnell sichtbar.

Wann useCallback / useMemo wirklich helfen — und wann nicht

useCallback und useMemo sind Performance-Optimierungen. Sie stabilisieren Funktions- und Objektidentitäten oder cachen teure Berechnungen. Sie sind kein Ersatz für korrekt gesetzte Dependencies und sollten sparsam eingesetzt werden. Siehe Referenzen: useCallback, useMemo.

Wann sie helfen:

• Wenn ein Effekt von einem Options-Objekt abhängt, das bei jedem Render neu erzeugt wird. Mit useMemo kannst du dieses Objekt stabilisieren.
• Wenn ein Effekt von einer Callback-Referenz abhängt, die sich unnötig ändert. useCallback kann die Identität stabilisieren.

Wann besseres Refactoring hilft:

• Wenn die Funktion nur im Effekt gebraucht wird, definiere sie im Effekt statt als Dependency.
• Wenn der Effekt eigentlich nur eine Reaktion auf konkrete Primitive sein soll, reduziere Abhängigkeiten auf diese Werte statt auf Collections/Objekte.

Beispiel: Objekt stabilisieren vs. Funktion in den Effekt legen.

import { useEffect, useMemo } from 'react';

// Variante A: Objekt stabilisieren
export function SearchWithMemo({ term, limit }: { term: string; limit: number }) {
  const options = useMemo(() => ({ q: term.trim(), limit }), [term, limit]);

  useEffect(() => {
    // nutzt options; Effekt läuft nur, wenn sich q/limit wirklich ändern
    // ...
  }, [options]);
  return null;
}

// Variante B: Abhängigkeiten reduzieren, Funktion in Effekt verschieben
import { useEffect as useEffect2 } from 'react';

export function SearchLean({ term, limit }: { term: string; limit: number }) {
  useEffect2(() => {
    const q = term.trim();
    // ... nutze q und limit direkt
  }, [term, limit]);
  return null;
}

Faustregeln:

• Stabilisiere nur, wenn Instabilität realen Schaden anrichtet (unnötige Re-Runs, teure Re-Renders) und die Lesbarkeit nicht leidet.
• Nutze funktionale State-Updates statt useCallback, wenn du nur den letzten State brauchst.

Typische Endlosschleifen und wie man sie auflöst

Häufige Ursachen:

• Im Effekt erzeugst du bei jedem Run ein neues Objekt/eine neue Funktion und setzt es in den State, der wiederum als Dependency eingetragen ist.
• Du führst im Effekt ein unguarded setState aus, das direkt wieder dieselben Dependencies ändert.
• Abhängigkeiten sind unvollständig oder zu breit (z. B. gesamtes Objekt statt einzelner Werte).

Beispiel (endlose Re-Runs):

export function LoopingEffect() {
  const [opts, setOpts] = useState({ dark: false });

  useEffect(() => {
    // erzeugt jedes Mal ein neues Objekt -> setState -> neuer Render -> Effekt neu …
    setOpts({ dark: window.matchMedia('(prefers-color-scheme: dark)').matches });
  }, [opts]);

  return <pre>{JSON.stringify(opts)}</pre>;
}

Refactoring mit Guard oder ohne Selbstabhängigkeit:

export function FixedEffect() {
  const [opts, setOpts] = useState({ dark: false });

  useEffect(() => {
    const next = { dark: window.matchMedia('(prefers-color-scheme: dark)').matches };
    // Nur updaten, wenn sich der Inhalt wirklich ändert
    setOpts(prev => (prev.dark === next.dark ? prev : next));
  }, []); // läuft nur beim Mount, weil im Effekt keine sich ändernden reaktiven Werte aus dem Component-Body verwendet werden

  return <pre>{JSON.stringify(opts)}</pre>;
}

Hinweis: Das leere Dependency-Array ist hier gerechtfertigt, weil der Effekt keine sich ändernden reaktiven Werte aus dem Component-Body liest. Der setOpts-Setter selbst ist stabil (React garantiert die Stabilität von Dispatch-Funktionen aus useState) und muss nicht als Dependency aufgeführt werden.

Weitere Strategien:

• Dependencies präzisieren (statt data das tatsächlich relevante data.id).
• Stabilisierung mit useMemo/useCallback, wenn zwingend nötig.
• Effekte idempotent machen und interne Berechnungen in den Render oder useMemo verlagern.

Praktische Checkliste für den Einsatz von useEffect in Projekten

• Gehört die Logik wirklich in einen Effekt oder ist es abgeleitete UI-Logik für Render/useMemo?
• Dependencies: Sind alle reaktiven Werte enthalten und so spezifisch wie möglich?
• Stale closures ausgeschlossen? Bei asynchronen Updates funktionale State-Updates verwenden.
• Cleanup vorhanden, vollständig und idempotent? Abos/Timer/DOM-Listener/WS-Verbindungen werden entfernt.
• Fetch-Pattern mit AbortController umgesetzt (Abbruch im Cleanup, Abbrüche nicht als Fehler zählen)?
• StrictMode im Development aktiv und Cleanups auf Doppelaufrufe getestet?
• Werden Objekte/Funktionen nur stabilisiert, wenn es wirklich nötig ist? Alternativ Logik in den Effekt/Render ziehen.
• Keine selbstinduzierten Loops: Effekte setzen keinen State, der ihre eigenen Dependencies ohne Guard wieder ändert.

Fazit und weiterführende Links

Richtig eingesetzte Effekte synchronisieren Komponenten zuverlässig mit externen Systemen. Schlüssel dazu sind präzise Dependencies, frische Closures, robuste Cleanups und bewusstes Fetch-Handling mit AbortController. StrictMode hilft, Probleme frühzeitig zu erkennen. useCallback/useMemo sind dabei nützliche, aber optionale Optimierungswerkzeuge.

Weiterführende Links:

• React-Referenz: useEffect — React: useEffect
• React-Referenz: <StrictMode> — React: StrictMode
• MDN: AbortController — MDN: AbortController
• React-Referenz: useCallback — React: useCallback
• React-Referenz: useMemo — React: useMemo
• Lint-Regel: eslint-plugin-react-hooks/exhaustive-deps — exhaustive-deps lint rule