State Management in React

State Management in React

0:00 Zustandsverwaltung ist das Thema, an dem sich in React-Projekten entscheidet, ob eine Anwendung nach einem halben Jahr noch wartbar ist. Nicht die Komponenten, nicht das Styling — der Zustand. Denn er ist das Einzige, was sich ständig ändert, und je unklarer ist, wo er lebt und wer ihn ändern darf, desto zäher wird die Arbeit.

0:19 Die gute Nachricht: React bringt alles mit, was man für den weitaus größten Teil der Fälle braucht. Heute geht es darum, Zustand gezielt zu platzieren, zu teilen und synchron zu halten — und zu wissen, wann man ihn besser in Ruhe lässt.

State Management in React

0:33 Wir gehen in vier Blöcken vor. Zuerst die beiden zentralen Hooks — Zustand und Effekte. Dann zwei sehr praktische Themen: Formulare mit vielen Feldern und die Kommunikation zwischen Komponenten. Im dritten Block geht es ums Teilen: Zustand hochziehen und die Context-Schnittstelle. Und zum Schluss der wichtigste Teil, auch wenn er am wenigsten nach Technik klingt — Entscheidungshilfen und Muster.

0:56 Ich setze voraus, dass Komponenten, Props und einfacher Zustand aus dem Grundlagenmodul sitzen. Drei Fragen zum Einstieg, und diesmal sind sie sehr konkret. Wie verwalten Sie Zustand heute in Ihren Projekten? Sind Sie schon einmal an unübersichtlichem Zustand gescheitert — an einer Anwendung, bei der niemand mehr sagen konnte, wer was ändert?

1:16 Und kennen Sie Effekte oder die Context-Schnittstelle bereits? Die mittlere Frage ist mir die liebste, weil die Schmerzerfahrung der beste Lehrmeister ist. Wenn Sie ein solches Projekt kennen, behalten Sie es heute im Kopf — wir werden mehrfach an Stellen kommen, an denen genau das seinen Anfang nimmt.

State mit useState

1:34 Beginnen wir mit einer kurzen Auffrischung — und mit einem Detail, das im Grundlagenmodul absichtlich offengeblieben ist und in der Praxis erstaunlich viel Ärger macht. Der Zustands-Hook gibt einer Komponente lokalen Zustand: einen Wert, der die Durchläufe überlebt, und eine Funktion, die ihn ändert und damit einen neuen Durchlauf auslöst.

1:53 Wichtig ist der letzte Satz: Jeder Aufruf verwaltet genau ein Stück Zustand. Sie können also mehrere davon nebeneinander verwenden, und das ist oft besser als ein großes Objekt. Denken Sie an einzelne Schalter statt an eine Zentraleinheit — jeder schaltet unabhängig, und man muss nicht überlegen, was man beim Umlegen versehentlich mit verändert.

2:14 Drei Punkte zur Einordnung. Zustand ist die Grundlage jeder interaktiven Oberfläche — ohne ihn haben Sie eine Anzeige, keine Anwendung. Die Setzfunktion ist das Signal an React, neu zu rendern; nur was durch sie hindurchgeht, wird bemerkt. Und der dritte Punkt ist ein Gestaltungshinweis: Mehrere getrennte Zustände halten unabhängige Werte auch tatsächlich unabhängig.

2:35 Wenn Sie merken, dass Sie beim Ändern eines Werts jedes Mal auch andere mitkopieren müssen, ist das ein Zeichen, dass da eigentlich zwei Dinge in einem Topf liegen. Und hier das Detail, das ich angekündigt habe. Oben die naheliegende Schreibweise: den aktuellen Wert nehmen und eins draufrechnen. Die funktioniert — meistens.

2:55 Sie bricht, sobald im selben Durchgang mehrfach gesetzt wird, denn der abgelesene Wert ist dann noch der alte. Zwei Erhöhungen ergeben eine. Unten die robuste Form: Statt eines Werts übergeben Sie eine Funktion, die den jeweils letzten Stand bekommt und den nächsten liefert. React ruft sie der Reihe nach auf. Worauf es ankommt: Gewöhnen Sie sich diese Form grundsätzlich an, wenn der neue Wert vom alten abhängt. Sie kostet nichts und erspart eine ganze Fehlerklasse.

3:24 Zeigen Sie sich das Problem einmal selbst. Bauen Sie einen Zähler, bei dem ein Klick zweimal erhöht — einmal in der naiven, einmal in der abgeleiteten Schreibweise. Sie werden sehen, dass die erste Variante nur um eins hochzählt. Erfolgskriterium ist genau das: Zwei schnelle Klicks erhöhen zuverlässig um zwei. Wer weitermachen will, baut einen zweiten Zustand für die Schrittweite ein — und merkt dabei, wie angenehm es ist, dass die beiden Werte sich gegenseitig nicht ins Gehege kommen.

3:53 Der erste Punkt ist der grundlegendste: Den Wert direkt zu verändern, löst keinen neuen Durchlauf aus. Das ist tückisch, weil der Wert tatsächlich anders ist — nur die Anzeige bleibt stehen. Zweitens der eben gezeigte Fall mit mehreren Änderungen im selben Ereignis, für den es die abgeleitete Form gibt. Und drittens der Punkt, der in React-Projekten wohl die meiste Zeit kostet: Objekte und Listen im Zustand müssen neu erzeugt werden.

4:18 React vergleicht auf Identität, nicht auf Inhalt — ein verändertes, aber identisches Objekt gilt schlicht als unverändert.

Side Effects mit useEffect

4:26 Kommen wir zum Hook mit dem schlechtesten Ruf. Effekte werden häufiger falsch eingesetzt als jedes andere React-Werkzeug — meist, weil man sie für einen Alleskönner hält. Schauen wir uns an, wofür sie wirklich da sind. Ein Effekt führt Code nach dem Rendern aus, um die Komponente mit etwas außerhalb von React abzugleichen — Daten laden, einen Timer setzen, ein Abonnement verwalten.

4:49 Das Stichwort ist Synchronisation, nicht Reaktion. Denken Sie an eine Uhr, die sich regelmäßig mit dem Zeitzeichen abgleicht: Sie läuft selbstständig, aber sie hält sich mit der Außenwelt im Einklang. Die Abhängigkeitsliste steuert, wann dieser Abgleich wiederholt wird. Und der wichtigste Satz zur Abgrenzung: Alles, was sich aus vorhandenem Zustand berechnen lässt, gehört nicht in einen Effekt, sondern einfach in den Rendervorgang.

5:14 Drei Gründe für diese Trennung. Nebenwirkungen gehören nicht in den Rendervorgang selbst — der soll berechenbar bleiben und darf beliebig oft laufen, ohne Schaden anzurichten. Die Abhängigkeitsliste bündelt an einer Stelle, wovon der Effekt abhängt; sie ist ein Vertrag, den React für Sie überwacht. Und die Aufräumfunktion — für mich der unterschätzteste Teil — sorgt dafür, dass Timer und Abonnements zuverlässig verschwinden.

5:39 In der Welt vor den Hooks war das ein Dauerthema; hier steht es direkt neben dem, was aufgeräumt werden muss. Vier Schritte. Die Logik kommt in den Effekt, die Abhängigkeiten in die Liste, bei Bedarf geben Sie eine Aufräumfunktion zurück. Und der vierte Punkt ist eigentlich eine Merkregel: Eine leere Liste bedeutet, dass der Effekt nur einmal nach dem ersten Rendern läuft.

6:01 Dazu die Fußzeile, die den dritten Fall nennt — gar keine Liste heißt: nach jedem Rendern. Das ist fast nie gewollt und die häufigste Ursache für Endlosschleifen. Merken Sie sich die drei Fälle einmal richtig; sie erklären neun von zehn seltsamen Effekt-Verhalten. Ein kompaktes, aber vollständiges Beispiel. Beim ersten Rendern startet ein Intervall.

6:22 Zurückgegeben wird eine Funktion, die es wieder abräumt — und genau die ruft React auf, wenn die Komponente verschwindet oder bevor der Effekt erneut läuft. Worauf es ankommt: Ohne diese Aufräumzeile liefe der Timer weiter, auch wenn die Komponente längst nicht mehr angezeigt wird. Bei einer Uhr merkt man das kaum, bei einem Datenabruf im Sekundentakt sehr wohl. Die Faustregel lautet: Wer im Effekt etwas anlegt, das weiterläuft, muss es auch wieder wegräumen.

6:50 Bauen Sie eine Uhr, die sekündlich tickt. Das ist schnell erledigt — der interessante Teil kommt danach: Bauen Sie eine Schaltfläche, die die Uhr aus der Anzeige nimmt, und prüfen Sie in den Entwicklerwerkzeugen, ob der Timer wirklich gestoppt ist. Lassen Sie die Aufräumfunktion einmal absichtlich weg und schauen Sie, was passiert, wenn Sie die Uhr mehrfach ein- und ausblenden.

7:10 Diese weiterlaufenden Geister sind eine der häufigsten Ursachen für Anwendungen, die mit der Zeit langsam werden. Drei klassische Fallen. Fehlende Abhängigkeiten führen dazu, dass der Effekt mit veralteten Werten arbeitet — er sieht dann einen Zustand von vor drei Durchläufen. Das Linter-Regelwerk warnt davor, und diese Warnung sollte man ernst nehmen statt sie stillzulegen. Zweitens das vergessene Aufräumen, das Sie eben selbst gesehen haben.

7:37 Und drittens der Klassiker schlechthin: Zustand im Effekt ändern, der wiederum den Effekt auslöst. Das Ergebnis ist eine Endlosschleife, die den Browser lahmlegt. Wenn Ihr Rechner beim Speichern plötzlich laut wird — schauen Sie hier zuerst.

Formulare verwalten

7:51 Im Grundlagenmodul hatten wir ein einzelnes Eingabefeld. In der Praxis haben Formulare zehn oder zwanzig. Dafür braucht es ein Muster, das nicht mit jedem Feld mitwächst. Die Idee ist einfach: Statt für jedes Feld einen eigenen Zustand und eine eigene Behandlungsfunktion zu bauen, halten Sie den gesamten Formularzustand in einem Objekt — und schreiben eine einzige Funktion, die anhand des Feldnamens den richtigen Eintrag aktualisiert.

8:18 Der Feldname steht ohnehin im Markup; man nutzt ihn nur zusätzlich als Schlüssel. Das Ergebnis: Ein Formular mit zwanzig Feldern braucht denselben Code wie eines mit zweien. Genau solche Muster machen den Unterschied zwischen Code, der mitwächst, und Code, der explodiert. Drei Vorteile. Ein Handler statt einer Funktion je Feld — das ist der offensichtliche und größte.

8:40 Der gesamte Formularzustand liegt an einer Stelle, was das Absenden trivial macht: Sie schicken einfach das Objekt. Und Validierung wird angenehm, weil Sie alle Werte gemeinsam prüfen können, auch die Abhängigkeiten zwischen ihnen — etwa ob zwei Passwortfelder übereinstimmen. Das wäre mit verstreuten Einzelwerten deutlich mühsamer. Für sehr große Formulare gibt es später spezialisierte Bibliotheken, aber dieses Muster trägt erstaunlich weit.

9:07 Der Kern steckt in der Zeile mit den eckigen Klammern. Was dort steht, ist ein berechneter Schlüssel: Der Name kommt zur Laufzeit aus dem Feld und bestimmt, welcher Eintrag im Objekt überschrieben wird. Darum herum das inzwischen vertraute Muster — vom vorigen Stand ableiten und mit dem Spread-Operator eine Kopie erzeugen, in der ein Feld anders ist.

9:27 Worauf es ankommt: Das Feld muss sein Namensattribut tragen, sonst greift der Schlüssel ins Leere und Sie schreiben eine Eigenschaft namens „undefined". Ein Fehler, den man leicht übersieht, weil nichts abstürzt. Bauen Sie ein Formular mit mindestens zwei Feldern, die über einen gemeinsamen Objektzustand laufen. Erfolgskriterium ist bewusst negativ formuliert: Es darf keine zweite Behandlungsfunktion geben.

9:51 Wenn Sie fertig sind, fügen Sie testweise ein drittes Feld hinzu — und stellen Sie fest, dass Sie am JavaScript-Code gar nichts ändern müssen. Genau dieses Gefühl ist der Punkt der Übung. Lassen Sie außerdem einmal absichtlich das Namensattribut weg und schauen Sie sich das Zustandsobjekt in den React-Entwicklerwerkzeugen an.

10:11 Das vergessene Namensattribut steht zu Recht ganz oben — es ist der häufigste Fehler bei diesem Muster und äußert sich still. Zweitens: das Zustandsobjekt zu verändern statt es neu zu erzeugen. Wir hatten das schon, aber hier tritt es besonders oft auf, weil Objekte im Spiel sind und die direkte Zuweisung so naheliegt. Und drittens der Punkt aus dem Grundlagenmodul, der hier wiederkommt: Auch Zahlenfelder liefern Text.

10:35 Wenn Sie später rechnen wollen, wandeln Sie um — und zwar am besten beim Absenden, nicht bei jedem Tastendruck.

Komponentenkommunikation

10:42 Bisher lebte der Zustand immer in der Komponente, die ihn braucht. Jetzt wird es interessant: Was tun, wenn ein Kind etwas auslöst, das ein anderer wissen muss? Die Regel lautet: Daten runter, Ereignisse hoch. Eltern reichen Werte über Props nach unten. Kinder melden Ereignisse nach oben, indem die Eltern ihnen eine Funktion mitgeben, die das Kind aufrufen kann. Der Datenfluss bleibt damit eine Einbahnstraße.

11:08 Stellen Sie sich eine Firma vor: Anweisungen gehen nach unten, Meldungen nach oben — niemand greift quer in eine andere Abteilung hinein. Das klingt nach Bürokratie, hat aber einen großen praktischen Vorteil: Wenn ein Wert falsch ist, gibt es genau einen Weg, auf dem er dorthin gekommen sein kann. Drei Punkte. Der vorhersehbare Datenfluss ist der wichtigste — Fehlersuche wird zur Rückverfolgung statt zur Detektivarbeit.

11:33 Zweitens bleiben Kinder wiederverwendbar und entkoppelt: Eine Komponente, die nur eine Funktion aufruft, weiß nichts von der Anwendung drumherum und funktioniert deshalb auch woanders. Und drittens: Der Zustand lebt bei den Eltern, an einer definierten Stelle, statt verteilt. Wer schon einmal in einer Anwendung gesucht hat, in der drei Komponenten dieselbe Information unabhängig voneinander halten, weiß, warum das zählt.

11:59 Klein, aber es zeigt das ganze Prinzip. Oben die Elternkomponente mit dem Zustand. Sie gibt dem Kind eine Funktion mit — hier direkt die Setzfunktion, oft ist es eine eigene. Unten das Kind: Es nimmt diese Funktion als Eigenschaft entgegen und ruft sie beim Klick auf. Worauf es ankommt, steht in der Fußzeile: Das Kind kennt den Zustand der Eltern nicht.

12:21 Es weiß nur, dass es etwas melden kann. Genau diese Unwissenheit macht es wiederverwendbar — man kann es an anderer Stelle einsetzen, wo etwas ganz anderes passiert. Bauen Sie dieses Paar selbst: Ein Klick im Kind ändert sichtbar einen Zustand, der in der Elternkomponente liegt. Achten Sie dabei besonders auf die Benennung Ihrer Rückruf-Eigenschaft. Nennen Sie sie nach dem Ereignis aus Sicht des Kindes, nicht nach der Aktion der Eltern.

12:47 Das ist ein feiner, aber wichtiger Unterschied: Das Kind meldet, dass etwas ausgewählt wurde — was daraufhin passiert, ist nicht seine Sache. Wenn Sie das konsequent machen, bleiben Ihre Komponenten fast automatisch wiederverwendbar. Erstens: Kinder sollen den Zustand der Eltern nicht direkt verändern — auch wenn man ihnen technisch ein Objekt mitgeben könnte, in das sie hineinschreiben.

13:10 Das bricht die Einbahnstraße und damit die Nachvollziehbarkeit. Zweitens die Benennung, die ich eben angesprochen habe. Und drittens ein Punkt, der uns direkt ins nächste Kapitel führt: Wenn Sie Eigenschaften durch mehrere Ebenen durchreichen, die sie selbst gar nicht brauchen, wird es mühsam. Das hat einen Namen — Prop Drilling — und zwei Lösungen, die wir uns nacheinander anschauen.

Gemeinsamer State

13:32 Die erste Lösung ist die einfachere und in den meisten Fällen die richtige. Sie klingt fast zu banal, um ein eigenes Kapitel zu bekommen — und ist trotzdem die wichtigste Entscheidung, die Sie beim Zustand treffen. Wenn zwei Komponenten denselben Zustand brauchen, verschiebt man ihn in ihre nächste gemeinsame Elternkomponente. Von dort fließt er als Eigenschaft zu beiden Kindern.

13:54 Die englische Bezeichnung dafür — den Zustand hochheben — beschreibt es recht bildlich. Der Gewinn ist eine einzige Quelle der Wahrheit. Die Alternative wäre, den Wert in beiden Kindern zu halten und irgendwie synchron zu halten — und genau da beginnt der Ärger, den viele von uns kennen: Zwei Werte, die eigentlich gleich sein sollten und es nach ein paar Interaktionen nicht mehr sind.

14:16 Drei Punkte, die zusammengehören. Eine Quelle der Wahrheit statt duplizierter Zustände, die auseinanderdriften — das ist der Kern. Geschwister bleiben synchron, weil sie schlicht denselben Wert lesen; es gibt gar keinen Mechanismus, der schiefgehen könnte. Und drittens, oft unterschätzt: Es ist klar geregelt, wer den Zustand besitzt und ändern darf.

14:37 Diese Frage schriftlich beantworten zu können, ist in einem Team mehr wert als jede Bibliothek. Wenn niemand sie beantworten kann, hat man ein Architekturproblem, kein Werkzeugproblem. Vier Schritte, und der erste ist der eigentliche Denkschritt: Erkennen, welcher Zustand tatsächlich gemeinsam genutzt wird. Danach heben Sie ihn in den nächsten gemeinsamen Vorfahren, geben den Wert als Eigenschaft nach unten und lassen Änderungen über Rückruffunktionen zurückmelden.

15:05 Beachten Sie das Wörtchen „nächsten" — und die Fußzeile dazu: nicht höher heben als nötig. Der Reflex, den Zustand gleich ganz nach oben zu legen, ist verständlich und führt geradewegs zu dem Durchreichen, das wir vermeiden wollen. Hier sehen Sie das Muster in seiner Reinform. Der Zustand liegt in der Elternkomponente. Das eine Kind bekommt Wert und Änderungsfunktion, das andere nur den Wert — es liest ja bloß.

15:29 Diese Asymmetrie ist typisch und aufschlussreich: Man sieht auf einen Blick, wer schreiben darf und wer nur schaut. Worauf es ankommt: Beide Kinder lesen denselben Wert, sie können also gar nicht auseinanderlaufen. Es gibt keine Synchronisation, weil es nichts zu synchronisieren gibt — und das ist die eleganteste Art, ein Problem zu lösen.

15:50 Bauen Sie zwei Geschwisterkomponenten, bei denen die Eingabe in der einen sofort in der anderen erscheint. Klassiker wäre ein Eingabefeld und eine Vorschau. Machen Sie vorher bewusst den Fehler: Halten Sie den Zustand zunächst in beiden Kindern und versuchen Sie, sie synchron zu bekommen. Sie werden merken, dass es entweder gar nicht geht oder hässlich wird. Danach heben Sie den Zustand hoch — und das Problem verschwindet einfach.

16:15 Dieser Kontrast ist die Übung; die Lösung allein wäre in zwei Minuten geschrieben. Der erste Punkt ist der eben nachgebaute Fehler: denselben Zustand doppelt halten. Er entsteht selten absichtlich, sondern schleichend — jemand braucht den Wert schnell auch hier und legt ihn eben lokal an. Der zweite ist das Gegenteil und mindestens so häufig: den Zustand zu weit oben ansiedeln, was zu unnötigem Durchreichen führt.

16:39 Zwischen diesen beiden Polen liegt die richtige Ebene. Und der dritte Punkt ist ein handwerklicher: den Rückruf zu vergessen, mit dem das Kind seine Änderung meldet. Dann fließt der Wert nur nach unten und nichts mehr zurück.

Einführung in Context API

16:53 Und damit zur zweiten Lösung für das Durchreichen. Sie ist mächtiger und wird deshalb regelmäßig übernutzt — deshalb steht am Ende dieses Kapitels ein ausdrücklicher Hinweis dazu. Die Context-Schnittstelle stellt einen Wert für einen ganzen Teilbaum bereit, ohne ihn Ebene für Ebene durchzureichen. Ein Provider setzt den Wert weit oben, und jede Komponente darunter kann ihn direkt lesen — egal wie tief sie liegt.

17:17 Denken Sie an das Radioprogramm in einem Gebäude: Es wird an einer Stelle eingespeist und ist in jedem Raum zu hören, ohne dass jemand Kabel von Zimmer zu Zimmer legt. Und der wichtige Zusatz, der schon in der Notiz steht: Context löst das Durchreichen. Es ist keine Zustandsverwaltung — es ist ein Transportweg. Drei Punkte. Context löst das Durchreichen durch viele Zwischenkomponenten, die den Wert selbst gar nicht brauchen — das ist der eigentliche Zweck.

17:44 Es eignet sich ideal für globale, selten wechselnde Werte: das Erscheinungsbild, die Sprache, der angemeldete Nutzer. Diese Aufzählung ist übrigens keine zufällige Beispielliste, sondern ziemlich genau der Bereich, für den Context gedacht ist. Und drittens: Jede Komponente im Teilbaum liest den Wert direkt, was die Zwischenebenen völlig unbeteiligt lässt — sie müssen nicht einmal wissen, dass es ihn gibt.

18:09 Vier Schritte: Kontext anlegen, Teilbaum in den Provider hüllen, Wert auslesen, und — falls er sich ändern soll — eine Setzfunktion gleich mitgeben. Genau dieser vierte Punkt wird oft vergessen: Der Kontext transportiert nur; wenn jemand den Wert ändern können soll, muss die Möglichkeit dazu mit im Paket liegen. Und dann die Fußzeile, die den wichtigsten Nachteil nennt: Ändert sich der Wert im Provider, rendern alle Leser neu.

18:33 Bei einem Erscheinungsbild ist das folgenlos, bei einem Wert, der sich zehnmal pro Sekunde ändert, nicht. Drei Zeilen genügen für das Prinzip. Oben wird der Kontext angelegt, mit einem Standardwert. In der Mitte hüllt der Provider einen Teilbaum ein und setzt den Wert für alles darunter. Und ganz unten, angedeutet: Irgendwo tief im Baum liest eine Komponente ihn aus — ohne dass eine einzige Zwischenkomponente davon etwas mitbekommt.

18:59 Worauf es ankommt, steht in der Fußzeile: Gelesen wird immer der nächste Provider oberhalb. Man kann Kontexte also verschachteln und in einem Teilbaum etwas anderes gelten lassen. Das ist selten nötig, aber gelegentlich sehr elegant. Bauen Sie ein Erscheinungsbild über Kontext: eine tief verschachtelte Komponente soll den Wert lesen, ohne dass die Ebenen dazwischen etwas durchreichen.

19:22 Bauen Sie die Verschachtelung ruhig unnötig tief — drei, vier Ebenen —, damit der Effekt spürbar wird. Wer weiter will, legt einen Umschalter mit in den Kontextwert, sodass die tiefe Komponente das Erscheinungsbild auch ändern kann. Damit haben Sie den vierten Schritt aus dem Vorgehen praktisch umgesetzt und sehen zugleich, warum Kontextwerte oft Objekte aus Wert und Funktion sind.

19:44 Der erste Punkt ist der wichtigste und der Grund für meinen Vorbehalt vorhin: Bei häufig wechselnden Werten rendern sehr viele Komponenten neu, auch solche, die den geänderten Teil gar nicht nutzen. Kontext ist für Stabiles gedacht. Zweitens: Nicht jeder globale Wert braucht Kontext — zwei Ebenen durchzureichen ist völlig in Ordnung und oft klarer.

20:04 Und drittens eine praktische Falle: Ohne umschließenden Provider gilt stillschweigend der Standardwert. Die Komponente stürzt nicht ab, sie zeigt einfach etwas anderes — und man sucht lange.

Wann lokaler State ausreicht

20:15 Jetzt kommt das Kapitel, das aus meiner Sicht das wichtigste des Tages ist. Sie kennen inzwischen alle Werkzeuge. Die eigentliche Kunst liegt darin, das kleinste zu wählen, das ausreicht. Die Faustregel ist schlicht: Zustand so lokal wie möglich halten. Erst hochziehen oder global machen, wenn mehrere Komponenten ihn nachweislich brauchen.

20:36 Das Wort „nachweislich" ist ernst gemeint — nicht, wenn sie ihn vielleicht mal brauchen könnten. Bei Architekturentscheidungen ist der Reflex verbreitet, für die Zukunft vorzubauen. Bei Zustand rächt sich das besonders schnell, weil jede Verallgemeinerung Kopplung erzeugt. Und Kopplung ist genau das, was später beim Umbauen weh tut. Es ist deutlich leichter, Zustand später hochzuziehen, als ihn wieder herunterzuholen.

21:02 Drei Argumente. Lokaler Zustand ist am einfachsten zu verstehen und zu testen — er hat keinen Kontext, den man mitdenken muss. Vorzeitiges Teilen erzeugt Kopplung und Komplexität, die niemand bestellt hat. Und der dritte Punkt ist eine Beobachtung aus der Praxis, die viele überrascht: Die meisten Zustände bleiben tatsächlich lokal.

21:22 In einer typischen Anwendung ist der Anteil des wirklich globalen Zustands klein — ein angemeldeter Nutzer, ein Erscheinungsbild, vielleicht ein Warenkorb. Der ganze Rest gehört dorthin, wo er benutzt wird. Diese Tabelle ist bewusst als Leiter gebaut, und die Reihenfolge ist die Botschaft: Man steigt sie von oben nach unten, und zwar nur so weit, wie man muss.

21:43 Interessant ist vor allem die letzte Zeile. Serverdaten sind kein klassischer Oberflächenzustand — sie haben ganz andere Eigenschaften: Sie können veralten, müssen zwischengespeichert und nachgeladen werden, gehören eigentlich jemand anderem. Dafür gibt es spezialisierte Werkzeuge, und der wichtigste Rat dazu lautet: Bauen Sie das nicht selbst nach.

22:03 Erstaunlich viel selbstgeschriebene Zustandsverwaltung ist in Wahrheit ein handgestrickter Cache. Diese Übung ist eine Denkaufgabe ohne Code. Sie bekommen vier Beispielzustände und ordnen jeden einer Ebene zu — lokal, gehoben oder Kontext — und begründen es. Die Begründung ist der eigentliche Punkt: Wer den Zustand braucht und wer ihn ändern darf.

22:24 Diskutieren Sie ruhig in kleinen Gruppen, denn genau diese Diskussion führen Sie später in echten Projekten. Und Sie werden merken, dass es bei ein, zwei Fällen keine eindeutige Antwort gibt — auch das ist eine wichtige Erkenntnis. Dann entscheidet man sich bewusst und schreibt auf, warum. Drei Muster, die in gewachsenen Projekten immer wieder auftauchen.

22:45 Alles in globalen Zustand zu legen macht die Anwendung unübersichtlich — man sieht dann nirgends mehr, wer eigentlich woran hängt. Kontext als Ersatz für jede Prop-Übergabe zu missbrauchen ist die feinere Variante desselben Fehlers; das Ergebnis sind Komponenten, die man nicht mehr isoliert verwenden kann. Und drittens der Punkt von eben, weil er so wichtig ist: Serverdaten brauchen eigene Werkzeuge.

23:08 Wer sie wie Oberflächenzustand behandelt, baut irgendwann eine schlechtere Version einer vorhandenen Bibliothek.

Typische React-Patterns

23:15 Zum Abschluss ein Kapitel, das weniger neue Technik bringt als neue Namen. Denn für das meiste, was wir heute gebaut haben, gibt es etablierte Bezeichnungen — und die sind im Team mehr wert, als man denkt. Über die Hooks hinaus haben sich wiederkehrende Muster etabliert, die typische Probleme lösen: Zustand teilen, Verhalten kapseln, Komponenten flexibel zusammensetzen.

23:37 Das Wichtigste dabei sind eigene Hooks, mit denen Sie wiederverwendbare Logik bündeln. Der Wert solcher Muster liegt weniger in der Technik — die kennen Sie längst — als in der gemeinsamen Sprache. Wenn jemand im Team sagt, wir heben den Zustand hoch, ist ein ganzer Absatz Erklärung gespart. So funktionieren Entwurfsmuster generell: Sie sind Vokabular, kein Regelwerk.

23:59 Drei Punkte. Das gemeinsame Vokabular erleichtert die Verständigung im Team, gerade in Codebesprechungen. Bewährte Lösungen ersparen es, das Rad jedes Mal neu zu erfinden — und, was wichtiger ist, sie ersparen die Fehler, die beim Neuerfinden entstehen. Und der dritte Punkt betrifft eigene Hooks besonders: Sie trennen Logik sauber von der Darstellung.

24:20 Damit lässt sich Logik testen, ohne eine Komponente zu rendern, und dieselbe Logik in ganz unterschiedlich aussehenden Komponenten verwenden. Das ist einer der elegantesten Aspekte des Hook-Modells. Schauen Sie sich diese Tabelle einmal in Ruhe an — und dann stellen Sie fest, dass Sie heute jedes dieser Muster bereits gebaut haben. Den Zustand hochziehen: Kapitel fünf.

24:43 Kontrollierte Komponenten: das Formularkapitel. Komposition über Kinder: aus dem Grundlagenmodul. Und der eigene Hook kommt gleich. Genau das ist die Botschaft der Fußzeile — diese Muster ergeben sich aus den Grundlagen, man muss sie nicht lernen, sondern nur wiedererkennen. Wenn Ihnen beim Lesen fremden Codes auffällt „ah, hier wird Zustand gehoben", haben Sie den Nutzen schon.

25:06 Ein eigener Hook ist einfach eine Funktion, die andere Hooks benutzt — mehr steckt nicht dahinter. Diese hier verwaltet einen Ein-Aus-Zustand und gibt den Wert zusammen mit einer Umschaltfunktion zurück. Beachten Sie das Rückgabeformat: ein Paar, genau wie beim eingebauten Zustands-Hook. Das ist Absicht — es fühlt sich beim Benutzen an wie ein React-Hook, weil es einer ist.

25:29 Worauf es ankommt, steht in der Fußzeile: Der Name muss mit „use" beginnen. Das ist keine Kosmetik, daran erkennen die Werkzeuge, dass hier die Hook-Regeln gelten. Bauen Sie einen solchen Hook und setzen Sie ihn in zwei verschiedenen Komponenten ein. Das Entscheidende, das Sie dabei beobachten sollen: Beide Komponenten haben ihren eigenen, unabhängigen Zustand.

25:51 Der Hook teilt Logik, nicht Daten — das ist eine der häufigsten Verwechslungen bei Einsteigern, die annehmen, ein gemeinsamer Hook bedeute einen gemeinsamen Wert. Probieren Sie es aus, klicken Sie in beiden Komponenten und sehen Sie, dass sie sich nicht beeinflussen. Danach wird das nie wieder unklar sein. Der Namenspräfix steht zu Recht oben — ohne ihn greifen die Hook-Regeln nicht, und die Werkzeuge können Sie nicht mehr vor Fehlern warnen.

26:17 Zweitens ein grundsätzlicher Ratschlag: Muster nicht erzwingen. Ein Muster einzusetzen, weil man es kennt, statt weil man es braucht, ist eine der häufigsten Ursachen für überkonstruierten Code. Und drittens eine Abgrenzung, die anfangs verwirrt: Ein Hook kapselt Logik, kein Markup. Wenn Sie in einem Hook JSX zurückgeben wollen, haben Sie in Wahrheit eine Komponente vor sich.

26:39 Fassen wir zusammen. Sie haben die beiden zentralen Hooks im Griff — den einen für lokalen Zustand, den anderen für den Abgleich mit der Außenwelt. Sie wissen, wie Sie Zustand gezielt teilen: hochziehen, wenn zwei Komponenten ihn brauchen, Kontext, wenn ein ganzer Teilbaum ihn braucht. Und Sie haben eine Reihenfolge im Kopf, die Sie vor überkonstruierten Lösungen bewahrt: erst lokal denken, dann teilen.

27:03 Der nächste Schritt ist, diese Ebenen in einer echten Anwendung bewusst zu wählen — und dazu gehört auch, wie man ein Projekt sinnvoll strukturiert.

Danke!

27:12 Damit ist das Zustandsmodul abgeschlossen. Alle Materialien liegen in der Freigabe. Wenn Sie nur eine Sache aus diesem Modul mitnehmen, dann bitte die Reihenfolge: lokal, gehoben, Kontext — und Serverdaten haben eigene Werkzeuge. Bei Fragen erreichen Sie uns unter der angegebenen Adresse. Im nächsten Modul geht es um Projektstruktur und Best Practices: wie man Komponenten schneidet, Ordner organisiert und Logik von Darstellung trennt. Vielen Dank fürs Mitmachen.