Startseite / Artikel / Beenden Sie das Synchronisieren des Zustands mit useEffect: Ein sichereres React-Muster

React JavaScript Frontend Hooks Performance

Beenden Sie das Synchronisieren des Zustands mit useEffect: Ein sichereres React-Muster

Erfahren Sie, warum die Verwendung von useEffect zur Synchronisierung des abgeleiteten Zustands zu Wettbewerbsbedingungen und zusätzlichen Render-Vorgängen führt, sowie wie man dies durch Ableitung zum Zeitpunkt des Renders und die key-Eigenschaft ersetzen kann.

2523 Wörter

Wie das Behandeln von useEffect als Mechanismus zur Synchronisierung des Zustands zu Render-Loops, Rennbedingungen und phantomen UI-Fehlern führt.

Ein Support-Ticket landet mit der Kennzeichnung „dringend“ auf Ihrem Schreibtisch. Ein Kunde berichtet, dass beim Wechseln zwischen Konten auf einer Team-Dashboard die Aktivitätsprotokolle manchmal Ereignisse anzeigen, die zum Konto gehören, das er vor dreißig Sekunden angezeigt hat.

Sie untersuchen den Codebase. Hier gibt es nichts Exotisches – weder eine WebSocket-Schicht noch Worker-Threads, nur ein ziemlich typischer Master-Detail-React-Ansicht.

Beim Testen lokal klicken Sie nacheinander durch die Konten. Die ersten neunundneunzig Wechsel funktionieren einwandfrei. Dann bricht beim hundertsten Versuch mit aktivierter Netzwerk-Drosselung visuell etwas zusammen: Für einen kurzen Moment erscheint die Abonnementstufe des zuvor ausgewählten Benutzers innerhalb der Profilkarte des neu ausgewählten Benutzers, bevor sich das wieder korrigiert.

Die Ursache für dieses Problem liegt in einem Muster, das völlig harmlos erscheint:

useEffect(() => {
  if (selectedUserId) {
    fetchUserData(selectedUserId).then((data) => {
      setUserProfile(data);
    });
  }
}, [selectedUserId]);

Diese eine Gewohnheit – das Verwenden von useEffect, um den internen Zustand einer Komponente mit Props oder anderen Zuständen in Einklang zu bringen – verursacht im modernen Frontend-Code mehr subtile Fehler, visuelle Störungen und strukturelle Probleme als fast jedes andere Muster.

1. Die Lebenszyklus-Falle: Warum Entwickler standardmäßig auf useEffect zurückgreifen

Als Hooks in React 16.8 eingeführt wurden, betrachteten Entwickler mit Erfahrung in Klassenkomponenten oft useEffect als Ersatz für componentDidMount, componentDidUpdate und componentWillUnmount zusammengefasst in einer einzigen API.

Diese Annahme führte später zu echtem Verwirrung.

Klassische Komponenten förderten einen imperativen Stil: Wenn sich ein Prop änderte, musste man in componentDidUpdate manuell this.setState() aufrufen, um alles, was daraus abgeleitet wurde, neu zu berechnen.

Beim Übergang zu Funktionskomponenten behielten viele Entwickler diese imperative Gewohnheit bei und gingen im Grunde davon aus, dass es ihre Aufgabe sei, jedes Mal, wenn sich ein Prop änderte, explizit eine entsprechende Aktualisierung in einen lokalen Zustand einzubringen.

Das Problem ist, dass React im Grunde deklarativ und zustandsbasiert arbeitet. Das Schreiben eines useEffect, dessen einziger Zweck darin besteht, einen anderen lokalen Zustandsvariablen zu aktualisieren, zwingt React effektiv dazu, zwei vollständige Render-Schleifen statt nur einer auszuführen.

So verläuft die Abfolge:

React rendernt die Komponente mit den neuen Props zusammen mit dem noch veralteten Zustand.

Diese Darstellung wird dem DOM zugewiesen, und der Browser zeichnet sie aus.

Der Effekt wird ausgelöst und ruft setState() auf.

React stellt eine zweite Darstellung an, die den aktualisierten Zustand widerspiegelt.

Nehmen wir dieses Beispiel:

function UserBillingSummary({
  plan,
  addonCount
}: {
  plan: string;
  addonCount: number;
}) {
  const [totalCost, setTotalCost] = useState(0);

  useEffect(() => {
    const base = plan === 'enterprise' ? 499 : 99;
    setTotalCost(base + addonCount * 25);
  }, [plan, addonCount]);  return <div>Total: ${totalCost} / month</div>;
}

Hier gibt es überhaupt keinen wirklichen Bedarf an einer separaten Zustandsvariable – totalCost kann vollständig aus plan und addonCount abgeleitet werden.

Anders ausgedrückt: Die Komponente erledigt unnötige zusätzliche Arbeit, nur um einen Wert zu erhalten, der bereits bei der initialen Darstellung berechnet werden konnte.

In diesem Zwischenframe können Benutzer kurzzeitig inkonsistente Zahlen auf dem Bildschirm sehen. Falls eine Layout-Logik von diesem berechneten Wert abhängt, muss der Browser möglicherweise auch das Layout neu erstellen und ausmalen, obwohl dies nicht notwendig gewesen wäre.

2. Der Domino-Effekt: Kaskadierende Abhängigkeitsketten

Diese doppelte Renderung kostet erheblich mehr, sobald mehrere Effekte von den Ausgaben der anderen abhängig werden.

Stellen Sie sich ein mehrstufiges Filterungsfenster innerhalb eines Analyse-Dashboards vor:

function AnalyticsFilters({
  organizationId
}: {
  organizationId: string;
}) {
  const [teams, setTeams] = useState<Team[]>([]);
  const [selectedTeamId, setSelectedTeamId] = useState<string>('');
  const [projects, setProjects] = useState<Project[]>([]);
  const [selectedProjectId, setSelectedProjectId] = useState<string>('');

  useEffect(() => {
    fetchTeams(organizationId).then((res) => {
      setTeams(res);
      setSelectedTeamId(res[0]?.id || '');
    });
  }, [organizationId]);  useEffect(() => {
    if (selectedTeamId) {
      fetchProjects(selectedTeamId).then((res) => {
        setProjects(res);
        setSelectedProjectId(res[0]?.id || '');
      });
    }
  }, [selectedTeamId]);  useEffect(() => {
    if (selectedProjectId) {
      logAnalyticsFilterChange(selectedProjectId);
    }
  }, [selectedProjectId]);  return (
    <div className="filter-bar">
      {/* Filter UI */}
    </div>
  );
}

Sehen Sie sich an, was passiert, sobald sich organizationId ändert:

React rendert erneut unter Verwendung der neuen organizationId.
Der erste Effekt lädt die Liste der Teams herunter und aktualisiert anschließend sowohl teams als auch selectedTeamId.
React rendert erneut.
Ein zweiter Effekt bemerkt die aktualisierte selectedTeamId und lädt die damit verbundenen Projekte herunter.
React rendert erneut.
Ein dritter Effekt nimmt die neue selectedProjectId wahr und protokolliert die Änderung.

Was ursprünglich mit einer einzigen Prop-Änderung begann, hat sich nun zu einer Kette von Zustandsänderungen und Effekt-Ausführungen entwickelt.

Sobald eine Anwendung wächst, werden solche Abhängigkeitsketten tatsächlich schwer nachvollziehbar. Wenn Netzwerkantworten aus dem richtigen Order eintreffen oder eine von ihnen aufgrund von Berechtigungsproblemen oder anderen Randfällen leer zurückgegeben wird, kann die Schnittstelle in einen inkonsistenten Zustand geraten, ohne dass ein offensichtlicher Fehler auftritt.

Das eigentliche Problem liegt nicht nur in der erhöhten Anzahl an Rendervorgängen – vielmehr ist die Komponente heimlich zu einer Miniatur-Asynchron-Zustandsmaschine geworden, die niemand absichtlich als solche konzipiert hat.

3. Der Geist der asynchronen Wettbedingungen

Nicht verwaltete asynchrone Aufrufe innerhalb von useEffect sind eine weitere häufige Ursache für sogenannte Phantomdaten in Single-Page-Anwendungen.

Stellen Sie sich einen Support-Mitarbeiter vor, der schnell durch verschiedene Ticketzeilen in einer Tabelle klickt:

function TicketDetailView({
  ticketId
}: {
  ticketId: string;
}) {
  const [ticket, setTicket] = useState<TicketData | null>(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    setLoading(true);    api.getTicket(ticketId).then((data) => {
      setTicket(data);
      setLoading(false);
    });
  }, [ticketId]);  if (loading) return <div>Loading ticket...</div>;  return <TicketDetails ticket={ticket} />;
}

Hier ist die Abfolge der Ereignisse, die diese Komponente zum Versagen bringt:

Der Agent klickt auf Ticket #101. Der Antrag A wird gestartet.
Bevor A abgeschlossen ist, klickt der Agent auf Ticket #102. Der Antrag B wird gestartet.
Antrag B wird zuerst abgeschlossen, wodurch die Benutzeroberfläche nun Ticket #102 anzeigt.
Schließlich wird Antrag A abgeschlossen und ruft setTicket(ticket101) auf.
Die Seitenleiste hebt weiterhin Ticket #102 hervor, doch das Detailfeld zeigt nun stattdessen Ticket #101 an.

React ist hier nicht schuld. Der eigentliche Fehler liegt darin, dass das Komponente es zulässt, dass ein veralteter Antrag den Zustand überschreibt, nachdem der Benutzer bereits woanders navigiert hat.

Falls Sie innerhalb eines Effects ohne Hilfsbibliothek Daten abrufen, müssen Sie dies durch manuelle Bereinigung verhindern:

useEffect(() => {
  let isCurrent = true;

  setLoading(true);  api.getTicket(ticketId)
    .then((data) => {
      if (isCurrent) {
        setTicket(data);
        setLoading(false);
      }
    })
    .catch((err) => {
      if (isCurrent) {
        handleTicketError(err);
      }
    });  return () => {
    isCurrent = false;
  };
}, [ticketId]);

Eine bessere Option, sofern Ihr API-Client dies unterstützt, ist AbortController. Anstatt eine verspätete Antwort einfach zu ignorieren, kann man die laufende Anfrage tatsächlich abbrechen, bevor sie abgeschlossen werden kann.

4. Die saubere Alternative: Abgeleiteter Zustand während der Renderung

Oft ist die einfachste Lösung für Synchronisierungsprobleme, von vornherein eine Synchronisierung des Zustands zu vermeiden.

In vielen Fällen, in denen Entwickler instinktiv zu useState in Kombination mit useEffect greifen, existiert der Wert, den sie speichern möchten, bereits irgendwo in den aktuellen Props oder im Elternzustand.

Anstatt diesen Wert in einen lokalen Zustand zu duplizieren, kann man ihn direkt während der Renderung berechnen.

Hier ist das problematische Muster:

function OrderSummary({
  items,
  discountCode
}: OrderSummaryProps) {
  const [discountPercent, setDiscountPercent] = useState(0);
  const [subtotal, setSubtotal] = useState(0);
  const [finalTotal, setFinalTotal] = useState(0);

  useEffect(() => {
    const rawSum = items.reduce(
      (acc, item) => acc + item.price * item.quantity,
      0
    );    setSubtotal(rawSum);
  }, [items]);  useEffect(() => {
    const discount = calculateDiscount(discountCode);
    setDiscountPercent(discount);
  }, [discountCode]);  useEffect(() => {
    setFinalTotal(
      subtotal - subtotal * (discountPercent / 100)
    );
  }, [subtotal, discountPercent]);  return (
    <SummaryView
      subtotal={subtotal}
      total={finalTotal}
    />
  );
}

Vergleichen Sie das nun mit einer Version, die auf abgeleitetem Zustand basiert:

function OrderSummary({
  items,
  discountCode
}: OrderSummaryProps) {
  const subtotal = items.reduce(
    (acc, item) => acc + item.price * item.quantity,
    0
  );

  const discountPercent = calculateDiscount(discountCode);  const finalTotal =
    subtotal - subtotal * (discountPercent / 100);  return (
    <SummaryView
      subtotal={subtotal}
      total={finalTotal}
    />
  );
}

Der Kontrast ist wichtig. Es gibt keinen doppelten Zustand, keinen Mechanismus, der dafür sorgt, dass die Werte synchron bleiben, und kein Fenster, in dem finalTotal aus der Übereinstimmung mit subtotal und discountPercent geraten könnte.

Die Props selbst bleiben die einzige Quelle der Wahrheit überall.

Wenn eine Berechnung tatsächlich aufwändig ist, ermöglicht useMemo es Ihnen, das Ergebnis über mehrere Renderungen hinweg zu speichern:

const filteredTransactions = useMemo(() => {
  return rawTransactions.filter((tx) => {
    return (
      tx.amount >= minThreshold &&
      tx.category === activeCategory
    );
  });
}, [rawTransactions, minThreshold, activeCategory]);

Der entscheidende Punkt ist, dass useMemo ausschließlich dazu dient, eine Berechnung zu memoisieren – es ist nicht dafür gedacht, zwei separate Zustände miteinander in Einklang zu bringen.

5. Deklaratives Zurücksetzen des Zustands mit der key-Prop

Eine verwandte Falle tritt auf, wenn ein editierbares Formular seine Felder jedes Mal zurücksetzen muss, wenn sich die geänderte Entität ändert.

Der typische Ansatz sieht so aus:

function EditUserModal({
  user
}: {
  user: UserData;
}) {
  const [name, setName] = useState(user.name);
  const [role, setRole] = useState(user.role);

  useEffect(() => {
    setName(user.name);
    setRole(user.role);
  }, [user.id]);  return (
    <form>
      <input
        value={name}
        onChange={(e) => setName(e.target.value)}
      />      <select
        value={role}
        onChange={(e) => setRole(e.target.value)}
      />
    </form>
  );
}

Der Ansatz kann zu einem sichtbaren Flackern führen, bei dem die Daten des vorherigen Eintrags noch eine Zeit lang auf dem Bildschirm angezeigt werden, bevor die Änderung wirkt und die Eingabefelder aktualisiert werden.

Noch schlimmer ist, dass frische Daten mitten in der Eingabe die bisher eingegebenen Inhalte unbemerkt überschreiben können.

React bietet bereits eine eingebaute, deklarative Lösung dafür: die key-Eigenschaft.

In dem Elternteil:

function UserAdminPage() {
  const [selectedUser, setSelectedUser] =
    useState<UserData | null>(null);

  return (
    <div>
      <UserList onSelectUser={setSelectedUser} />      {selectedUser && (
        <EditUserForm
          key={selectedUser.id}
          initialUser={selectedUser}
        />
      )}
    </div>
  );
}

Der lokale Zustand des Kind-Komponenten bleibt dadurch einfach, da es nichts zu synchronisieren gibt:

function EditUserForm({
  initialUser
}: {
  initialUser: UserData;
}) {
  const [name, setName] = useState(initialUser.name);
  const [role, setRole] = useState(initialUser.role);

  return (
    <form>
      <input
        value={name}
        onChange={(e) => setName(e.target.value)}
      />      <select
        value={role}
        onChange={(e) => setRole(e.target.value)}
      />
    </form>
  );
}

Wenn sich die key von user-1 auf user-2 ändert, versucht React nicht, die vorhandene Komponente zu aktualisieren – stattdessen wird sie verworfen und eine völlig neue Instanz mit neu initialisiertem Zustand aus den Daten des neuen Benutzers geladen.

Eine Synchronisierung ist überhaupt nicht notwendig.

6. Wo Code eigentlich hingehört: Event-Handler gegen Effekte

Ein nützliches Denkmodell ist folgendes: Effekte dienen dazu, Ihre Komponente mit etwas außerhalb von React zu synchronisieren, während Event-Handler darauf reagieren, was der Benutzer getan hat.

Stellen Sie sich vor, Sie müssen ein Analyse-Event auslösen und jedes Mal eine Bestätigungsanzeige anzeigen, wenn jemand auf „Bestellung absenden“ klickt.

Eine Möglichkeit, dies umzusetzen:

function CheckoutButton({
  orderId
}: {
  orderId: string;
}) {
  const [submitted, setSubmitted] = useState(false);

  useEffect(() => {
    if (submitted) {
      analytics.track('order_submitted', {
        orderId
      });      showToast('Order placed successfully!');
    }
  }, [submitted, orderId]);  return (
    <button onClick={() => setSubmitted(true)}>
      Place Order
    </button>
  );
}

Das Problem ist, dass dadurch der Auslöser von der eigentlichen Aktion getrennt wird – der Klick setzt ein Flag, und ein Effekt reagiert später auf dieses Flag.

Ein saubererer Ansatz behält alles innerhalb des Handlers selbst:

function CheckoutButton({
  orderId
}: {
  orderId: string;
}) {
  const handlePlaceOrder = async () => {
    await submitOrderApi(orderId);

    analytics.track('order_submitted', {
      orderId
    });    showToast('Order placed successfully!');
  };  return (
    <button onClick={handlePlaceOrder}>
      Place Order
    </button>
  );
}

Nun ist die Kausalität klar: Der Benutzer klickt, der Auftrag wird gesendet, und die anschließenden Aktionen werden unmittelbar als Teil desselben Ereignisses ausgeführt. Es gibt keinen Zwischenzustandswechsel, den man erkennen und darauf reagieren könnte.

7. Wann ist useEffect tatsächlich gerechtfertigt?

Das bedeutet keineswegs, dass useEffect an sich fehlerhaft ist.

Das Problem entsteht, wenn es als Allzweckwerkzeug zur Übertragung von Daten zwischen verschiedenen React-States verwendet wird.

Ihre eigentliche Aufgabe besteht darin, Ihren Component mit etwas in Einklang zu halten, das außerhalb von Reacts eigenem Render-Modell liegt.

Dieses „Etwas außerhalb von React“ fällt in der Regel in Kategorien wie:

Eigene Browser-APIs, wie zum Beispiel window.addEventListener, IntersectionObserver oder matchMedia

Imperative Drittanbieter-Bibliotheken wie Mapbox, Chart.js oder Video-Player-SDKs

Echtzeitverbindungen wie WebSockets oder Server-Sent Events

Direkte DOM-Manipulation, beispielsweise das Aktualisieren von document.title

Das Verfolgen der Breite des Browser-Fensters bei einer Größenanpassung ist ein gutes Beispiel für einen legitimen Effekt:

function useWindowWidth() {
  const [width, setWidth] = useState(
    () => window.innerWidth
  );

  useEffect(() => {
    const handleResize = () => {
      setWidth(window.innerWidth);
    };    window.addEventListener(
      'resize',
      handleResize
    );    return () => {
      window.removeEventListener(
        'resize',
        handleResize
      );
    };
  }, []);  return width;
}

In diesem Fall dient der Effekt dazu, etwas zu bewirken, was allein das Rendering nicht erreichen kann: Es wird eine Abonnierung an ein Browser-Event eingerichtet und bei der Aufräumarbeit wieder aufgehoben.

Genau dafür wurde useEffect konzipiert.

Die architektonischen Regeln, die ich heute befolge

Wenn ein auf React basierendes Dashboard oder eine App langsam, unzuverlässig wird oder von schwer nachzuvollziehenden Zeitproblemen geplagt ist, ist der erste Ort, den man überprüfen sollte, wie useEffect im gesamten Codebase verwendet wird.

Vier Leitprinzipien helfen dabei, die meisten Probleme zu lösen.

1. Werte während der Darstellung berechnen. Alles, was aus Props oder dem vorhandenen Zustand abgeleitet werden kann, sollte direkt im Render-Code berechnet werden. Verwenden Sie useMemo nur dann, wenn die Berechnung tatsächlich aufwändig ist.

2. Benutzerausgelöste Logik in Event-Handlern halten. Wenn etwas aufgrund eines Klicks, einer Tastenbelegung, einer Auswahl oder eines Absendevorgangs geschieht, gehört diese Logik direkt neben dem auslösenden Event und nicht in einen separaten Effect.

3. Zustand mit dem key-Prop sauber zurücksetzen. Beim Wechsel zwischen Entitäten sollte eine völlig neue Komponenteninstanz erstellt werden – lassen Sie React die Komponente neu montieren, anstatt jeden einzelnen Feldwert manuell abzustimmen.

4. Reservieren Sie useEffect für echte externe Synchronisierung. Browser-Events, Abonnements, WebSocket-Verbindungen sowie imperative BibliotheksinTEGRATIONEN sind der richtige Bereich für Effects.

Ziel ist es nicht, useEffect vollständig aus Ihrer Codebasis zu entfernen.

Ziel ist vielmehr, auf ihn nicht mehr als informellen Weg zur Übertragung von Werten zwischen verschiedenen React-States zurückzugreifen.

Sobald abgeleitete Werte als solche behandelt werden, Benutzeraktionen als Events erfasst werden und nur echte externe Systeme über Effects verbunden sind, werden React-Komponenten erheblich leichter verständlich.

Auch ein großer Teil der rätselhaften Fehler, die erst nach Dutzenden Klicks, unter einer langsamen Netzwerkverbindung oder ausschließlich in der Produktion auftauchen, lässt sich viel leichter von vornherein verhindern.