React v19 - Zustand

React v19+ — Zustand

0:00 Zustandsverwaltung hat in der React-Welt eine bewegte Geschichte. Jahrelang galt ein bestimmter Ansatz als Standard, und mit ihm eine Menge Zeremonie: Typen für Aktionen, Reduzierfunktionen, eine Hülle um die gesamte Anwendung. Das hatte gute Gründe, war aber für die meisten Fälle deutlich mehr, als nötig gewesen wäre. Die Bibliothek, um die es heute geht, geht den entgegengesetzten Weg — sie kommt mit etwa eineinhalb Kilobyte aus und braucht weder eine Hülle noch eine Zeremonie. Ein Hook genügt.

0:29 Ob das trägt, wenn ein Projekt wächst, schauen wir uns heute genau an.

Client-State mit Zustand

0:34 Der rote Faden führt vom einfachsten denkbaren Beispiel bis zu einem Speicher, den man in Produktion nehmen kann — mit dauerhafter Ablage im Browser und ohne Probleme beim Rendern auf dem Server. Der interessanteste Teil liegt dabei in der Mitte: Wie sorgt man dafür, dass eine Änderung nur die Komponenten neu zeichnet, die sie tatsächlich betrifft?

0:52 Genau daran scheitern die meisten Umsetzungen, und es ist erfreulich einfach zu beheben. Die zweite Frage nennt die beiden Enden eines Spektrums, zwischen denen sich Zustandsverwaltung bewegt. Auf der einen Seite steht der Zeremonienaufwand — viel Code für eine Änderung an einem Wert. Auf der anderen die unnötigen Neuzeichnungen — besonders bei der eingebauten Kontextlösung, wo jede Änderung alle Verbraucher erreicht.

1:16 Wenn Sie mit einem der beiden Ihre Erfahrungen gemacht haben, sagen Sie es ruhig; beide Enden kommen heute vor.

Einführung & Grundlagen

1:23 Fangen wir mit der Einordnung und dem Grundgerüst an. Zwei Dinge sind wichtig: was diese Bibliothek überhaupt verwaltet — und was ausdrücklich nicht. Diese zweite Frage wird oft übersprungen und ist die Ursache für die meisten Probleme, die später auftauchen. Nehmen Sie diese Abgrenzung ernst — sie ist der Unterschied zwischen einem schlanken Werkzeug und einem, das man überfordert.

1:46 Der Vergleich, der hier hilft: Denken Sie an eine Pinnwand im Büro. Jeder kann hinsehen, jeder kann etwas anheften, es braucht keine Anmeldung und keinen Verteiler. Der Speicher ist genau das — ein Ort, an dem Werte liegen und den jede Komponente direkt erreicht. Bemerkenswert ist die Zusammenlegung: Die Werte und die Funktionen, die sie ändern, wohnen gemeinsam an einem Ort.

2:08 Bei anderen Ansätzen sind das zwei getrennte Welten, und man springt beim Lesen ständig zwischen ihnen hin und her. Der letzte Punkt ist der wichtigste des ganzen Tages, und ich möchte ihn ausdrücklich betonen. Daten, die von einem Server kommen, gehören nicht hierher. Das ist keine Geschmacksfrage: Solche Daten veralten, müssen zwischengespeichert und nachgeladen werden, und all das müssten Sie hier von Hand bauen.

2:33 Dafür gibt es spezialisierte Werkzeuge. Was hierher gehört, ist alles, was Ihre Oberfläche über sich selbst weiß — welcher Reiter aktiv ist, was im Einkaufswagen liegt, welches Erscheinungsbild gewählt wurde. Fünf Schritte, die zusammen etwa zehn Zeilen ergeben — und das ist der ganze Einstieg. Bemerkenswert ist, was hier fehlt: keine Hülle um die Anwendung, keine Anmeldung, keine Konfiguration.

2:56 Der vierte Schritt nennt die beiden Handgriffe zum Schreiben und Lesen innerhalb des Speichers; das Lesen brauchen Sie seltener, aber es ist wichtig, wenn eine Aktion den aktuellen Stand kennen muss, ohne dass er ihr übergeben wurde. Sechs Zeilen für einen vollständigen Speicher — und die letzte ist die interessante. Was Sie dort sehen, ist keine Abfrage des gesamten Speichers, sondern eine gezielte Auswahl eines einzelnen Wertes.

3:21 Merken Sie sich diese Schreibweise gut, denn sie ist der Kern des nächsten Kapitels. Beachten Sie außerdem beim Erhöhen: Der neue Wert wird aus dem alten berechnet, statt einen festen Wert zu setzen. Das ist die verlässliche Variante, wenn mehrere Änderungen kurz hintereinander kommen. Bauen Sie Ihren ersten Speicher. Die Aufgabe ist absichtlich klein — es geht darum, ein Gefühl dafür zu bekommen, wie wenig dazugehört.

3:46 Wer das aus einer zeremoniellen Lösung kennt, wird kurz misstrauisch: Das kann doch nicht alles sein. Doch, das ist es. Die Zusatzaufgabe mit der Aufgabenliste ist dann der erste realistischere Fall, in dem Sie mit Listen arbeiten und dabei gleich üben, sie zu ersetzen statt zu verändern. Der erste Punkt ist die Abgrenzung von eben, und er ist der teuerste Fehler in diesem Umfeld — mit ihm bauen Sie sich Ihren eigenen, schlechteren Zwischenspeicher nach.

4:13 Der letzte Punkt betrifft ein Grundprinzip: Werte werden ersetzt, nicht verändert. Wer einen Eintrag in einer Liste direkt anfasst, ändert zwar den Inhalt, aber die Liste bleibt aus Sicht von React dieselbe — und niemand zeichnet neu. Die Anwendung zeigt dann alte Daten an, ohne dass ein Fehler sichtbar wird.

Selektoren & Rendering-Optimierung

4:31 Jetzt kommt das wichtigste Kapitel des Tages. Die Notiz sagt es unverblümt: Hier sitzt der häufigste Fehler überhaupt. Und das Schöne daran ist, dass er sich mit einer Handvoll Zeichen beheben lässt — man muss nur wissen, worauf man achtet. Wenn Sie heute nur ein Kapitel wirklich mitnehmen, sollte es dieses sein. Bleiben wir beim Bild der Pinnwand.

4:52 Sie können jedes Mal die ganze Wand fotografieren und dann nachsehen, ob sich Ihr Zettel geändert hat — oder Sie schauen gleich nur auf Ihren Zettel. Beides führt zum Ziel, aber im ersten Fall werden Sie bei jeder fremden Änderung aufgeschreckt. Genau das ist der Unterschied hier. Eine Auswahlfunktion sagt: Mich interessiert nur dieser eine Wert. Und dann wird nur neu gezeichnet, wenn genau der sich ändert. Alles andere geht spurlos vorbei.

5:19 Der zweite Punkt beschreibt den Fehler in seiner häufigsten Form. Man holt sich mit einer Zerlegung mehrere Werte auf einmal aus dem Speicher — das sieht kompakt und elegant aus. Tatsächlich hat man damit den gesamten Speicher abonniert. Jede Änderung irgendwo zeichnet diese Komponente neu, auch wenn die gelesenen Werte gleich geblieben sind.

5:39 Bei drei Komponenten fällt das nicht auf. Bei fünfzig wird die Anwendung träge, und die Ursache ist über die ganze Codebasis verteilt. Der dritte Punkt ist der subtilste und verdient eine Erklärung. Wenn Ihre Auswahlfunktion ein neues Objekt zusammenbaut, ist dieses Objekt bei jedem Durchlauf ein anderes — auch wenn die Inhalte identisch sind.

5:59 Der Vergleich schlägt also immer an, es wird neu gezeichnet, dabei entsteht wieder ein neues Objekt, und so weiter. Das Ergebnis ist eine Endlosschleife mit einer Fehlermeldung über zu viele Aktualisierungen. Der Ausweg steht im zweiten Punkt. Hier stehen die beiden korrekten Wege nebeneinander. Oben die einfachste und beste Variante: pro Wert eine eigene Auswahl.

6:21 Das wirkt umständlich, wenn man drei Werte braucht, ist aber völlig unproblematisch — es ist kein nennenswerter Aufwand, mehrere Auswahlfunktionen aufzurufen. Unten die Bündelung mit flachem Vergleich für den Fall, dass Sie wirklich ein Objekt brauchen. Der Zusatz vergleicht dann die Werte darin, nicht die Objektidentität — und die Schleife aus der letzten Folie bleibt aus.

6:43 Diese Übung sollten Sie ernst nehmen, denn sie macht etwas Unsichtbares sichtbar. Schalten Sie im Entwicklungswerkzeug die Hervorhebung für Neuzeichnungen ein und klicken Sie durch die Anwendung. Sie werden Bereiche aufleuchten sehen, die mit Ihrer Änderung nichts zu tun haben. Stellen Sie danach auf gezielte Auswahl um und wiederholen Sie den Test.

7:02 Dieser Vorher-Nachher-Vergleich ist der Grund, warum dieses Kapitel im Gedächtnis bleibt — man sieht den Unterschied buchstäblich. Der zweite Punkt nennt die Fehlermeldung wörtlich, und das ist Absicht: Wenn Sie sie einmal gesehen haben, wissen Sie sofort, wo Sie suchen müssen — in einer Auswahlfunktion, die ein neues Objekt baut.

7:22 Der dritte Punkt ist ein Versionshinweis: Eine frühere Möglichkeit, eine eigene Vergleichsfunktion anzugeben, gibt es nicht mehr. Wer ältere Beispiele aus dem Netz übernimmt, stolpert genau darüber. Der Ersatz ist die Bündelungsfunktion von eben.

TypeScript & Store-Architektur

7:37 Jetzt zur Frage, wie das aussieht, wenn ein Projekt wächst. Zwei Themen: die Typisierung mit ihrer einen eigenwilligen Schreibweise — und der Zuschnitt eines Speichers, der nicht mehr in eine Datei passt. Beides sind Themen, die im kleinen Beispiel keine Rolle spielen und ab einer gewissen Größe unvermeidlich werden. Zur Schreibweise mit den zwei Klammerpaaren eine ehrliche Einordnung: Sie sieht merkwürdig aus, und sie hat einen technischen Grund, den man nicht kennen muss.

8:04 Wichtig ist nur die Regel — sobald eine Erweiterung ins Spiel kommt, brauchen Sie diese Form, sonst bricht die Typableitung. Merken Sie es sich einfach als Konvention und schreiben Sie es immer so. Der zweite Teil ist die Zerlegung: Ein Speicher, der zu groß wird, zerfällt in Teilstücke, die für sich typisiert und getestet werden können.

8:23 Der letzte Punkt ist eine Disziplinregel, die sich auszahlt. Es gibt technisch die Möglichkeit, direkt auf den Speicher zuzugreifen, ohne den Hook. Das ist für einige Sonderfälle nötig — aber wenn es zur Gewohnheit wird, umgehen Sie die gesamte Anmeldungsmechanik. Komponenten, die so lesen, erfahren von Änderungen nichts.

8:42 Exportieren Sie also nur den Hook. Was nicht öffentlich ist, kann auch niemand aus Versehen benutzen. Der dritte und vierte Schritt beschreiben ein Muster, das man gut mit einem Bild fasst: Jedes Teilstück ist ein Werkzeugkasten für einen Bereich — einer für den Einkaufswagen, einer für die Oberflächenzustände. Zusammengesetzt ergeben sie den Gesamtspeicher, aber jeder Kasten bleibt für sich verständlich.

9:06 Der praktische Nutzen zeigt sich bei der Arbeitsteilung: Zwei Personen können an zwei Teilstücken arbeiten, ohne sich in derselben Datei zu begegnen. Beachten Sie die Aufgabenverteilung. Oben ein Teilstück, das ausschließlich seinen eigenen Bereich kennt — es weiß nichts von der Oberfläche, nichts vom Rest. Unten die Zusammensetzung, die selbst keine Logik enthält, sondern nur zusammenlegt. Der Typ oben ist eine Verknüpfung beider Bereiche.

9:33 Das Schöne daran: Ein neuer Bereich bedeutet eine neue Datei und zwei geänderte Zeilen hier. Kein Umbau, kein Anfassen bestehender Teile. Bauen Sie einen Speicher aus zwei Teilstücken. Achten Sie darauf, dass jedes für sich verständlich bleibt — wenn ein Teilstück anfängt, auf Werte des anderen zuzugreifen, ist der Schnitt vermutlich falsch gewählt.

9:53 Die Zusatzaufgabe mit der Erweiterung für veränderndes Schreiben lohnt sich, wenn Sie tief verschachtelte Daten haben. Dann können Sie scheinbar direkt ändern, und im Hintergrund entsteht trotzdem eine ordentliche neue Fassung. Der erste Punkt ist die Schreibweise mit den zwei Klammerpaaren — der Fehler ist in der Praxis leicht zu erkennen, weil er als Typfehler auftaucht, aber die Fehlermeldung ist wenig hilfreich.

10:16 Der letzte Punkt ist der schleichende: Ein Speicher, der alles enthält, entsteht nie durch eine Entscheidung, sondern durch dreißig kleine Ergänzungen. Ziehen Sie die Grenze früh — der Umbau von einer Datei in Teilstücke ist deutlich mühsamer als der umgekehrte Weg.

Middleware & Persistenz

10:31 Jetzt kommen die Erweiterungen, und drei davon sind im Alltag richtig nützlich: Einblick in die Änderungen zur Entwicklungszeit, dauerhafte Ablage über das Neuladen hinaus, und komfortables Schreiben in verschachtelten Daten. Bei einer davon lohnt sich besonderes Nachdenken, weil sie Daten dauerhaft im Browser des Nutzers ablegt.

10:49 Die dauerhafte Ablage ist die interessanteste der drei, weil sie am meisten Nachdenken verlangt. Es genügt nämlich nicht, einfach alles zu speichern. Erstens gehört längst nicht jeder Wert in den Browserspeicher — vorübergehende Zustände sicher nicht, sensible Daten auf keinen Fall. Zweitens, und das wird fast immer vergessen: Was Sie heute speichern, lesen Sie in einem Jahr wieder ein, mit einer Anwendung, die sich inzwischen verändert hat.

11:14 Deshalb gibt es Versionierung und einen Umzugsweg für alte Stände. Der letzte Punkt löst ein Problem, das gelegentlich auftaucht: Etwas außerhalb von React soll auf Änderungen reagieren — ein Analysedienst, eine Datensynchronisation, ein Vollbildmodus. Dafür gibt es eine Erweiterung, mit der man sich gezielt auf einen Ausschnitt anmelden kann, ohne eine Komponente zu sein.

11:36 Das ist ein Nischenfall, aber wenn man ihn hat, ist die Alternative meist ein unschöner Umweg über eine unsichtbare Komponente. Die Schritte drei und vier sind die, die man am ehesten überspringt und am sichersten bereut. Zur Auswahl der gespeicherten Felder haben wir gerade gesprochen. Zur Versionierung ein konkretes Bild: Sie benennen ein Feld um. Ihre Nutzer haben aber noch den alten Namen im Browser liegen.

12:01 Ohne Umzugsweg liest Ihre neue Anwendung einen Wert, den es nicht mehr gibt, und verhält sich seltsam — und zwar nur bei Bestandsnutzern, nie bei Ihnen im Test. Die entscheidende Zeile ist die mit der Feldauswahl. Sie ist optional, und genau das ist die Gefahr — ohne sie wird alles gespeichert, was im Speicher liegt. Machen Sie es sich zur Gewohnheit, sie immer zu schreiben, auch wenn sie anfangs alle Felder aufzählt.

12:25 Dann ist die Frage "gehört das in den Browserspeicher?" bei jedem neuen Feld eine bewusste Entscheidung statt einer stillen Voreinstellung. Und ein Blick auf den Namen: Er muss über alle Speicher hinweg eindeutig sein. Setzen Sie einen Einstellungsspeicher mit dauerhafter Ablage auf. Schauen Sie danach im Entwicklungswerkzeug des Browsers direkt in den Speicher hinein — dort steht Ihr Eintrag im Klartext.

12:50 Das ist eine gute Erinnerung daran, was dieser Ort ist: kein Tresor, sondern ein offenes Regal. Jeder mit Zugang zum Gerät kann mitlesen. Die Zusatzaufgabe mit dem Umzug eines umbenannten Feldes ist die Übung, die im echten Projekt später Gold wert ist. Der zweite Punkt ist der, den ich hervorheben möchte: Ohne Feldauswahl landet alles im Browserspeicher — auch Ladezustände, auch was gerade im Formular stand, möglicherweise auch ein Zugangsschlüssel.

13:17 Nach dem Neuladen kommt das alles zurück, inklusive eines Ladezustands, der nie endet, weil ja niemand mehr lädt. Der dritte Punkt ist ein Versionshinweis mit echtem Gewicht: In älteren Ständen gab es Wettlaufprobleme beim Wiederherstellen. Halten Sie die Version aktuell.

SSR, Next.js & fortgeschrittene Themen

13:33 Zum Abschluss zwei Themen, die man kennen muss, sobald auf dem Server gerendert wird. Das erste ist ein echtes Sicherheitsthema und wird oft unterschätzt. Das zweite ist die Ursache für eine Warnung, die viele schon einmal gesehen und weggeklickt haben. Beide haben gemeinsam, dass sie in der lokalen Entwicklung mit einem einzigen Nutzer nie auffallen.

13:53 Der erste Punkt verdient volle Aufmerksamkeit. Im Browser gibt es Ihre Anwendung genau einmal, für eine Person. Auf dem Server läuft derselbe Code für alle Anfragen gleichzeitig — und ein Speicher, der beim Laden des Moduls entsteht, existiert dort ebenfalls nur einmal. Für alle. Das bedeutet im schlimmsten Fall, dass die Daten eines Nutzers bei einem anderen auftauchen. Deshalb die Regel: pro Anfrage ein eigener Speicher.

14:18 Das ist kein Feinschliff, sondern eine Grundbedingung. Der zweite Punkt betrifft die bekannte Warnung über nicht übereinstimmende Inhalte. Der Grund ist einfach: Der Server hat keinen Zugriff auf den Browserspeicher. Er zeichnet also mit den Vorgabewerten — sagen wir helles Erscheinungsbild. Der Browser liest dann den gespeicherten Wert und würde dunkel zeichnen.

14:40 React vergleicht beides und meldet einen Widerspruch. Die Lösung ist nicht, die Warnung abzuschalten, sondern die Reihenfolge zu berücksichtigen: erst neutral, dann nach dem Einlesen umschalten. Der dritte Schritt ist die praktische Umsetzung dieser Reihenfolge, und er verdient eine gestalterische Anmerkung. "Neutral rendern" heißt nicht unbedingt "nichts rendern" — eine leere Fläche, die dann plötzlich befüllt wird, wirkt unruhig.

15:05 Meist ist ein Platzhalter in der richtigen Größe die bessere Wahl. Der letzte Punkt betrifft Tests: Ein Speicher, der von einem Test zum nächsten Werte behält, führt zu Ergebnissen, die von der Reihenfolge abhängen — und die sucht man lange. Ein kleiner Schalter mit großer Wirkung. Er steht anfangs auf falsch und wird umgelegt, sobald die gespeicherten Werte tatsächlich eingelesen sind.

15:28 Ihre Komponente fragt ihn ab und zeigt vorher etwas Neutrales. Das klingt nach einem Umweg und ist der einzige saubere Weg — die Alternative wäre, dem Server Kenntnisse zu unterstellen, die er nicht haben kann. Merken Sie sich dieses Muster; es gilt für jeden Wert, der nur im Browser existiert. Bringen Sie einen dauerhaft abgelegten Speicher ohne Warnung in eine server-gerenderte Anwendung.

15:51 Achten Sie auf die Gestaltung des Zwischenzustands — ein sichtbares Umspringen von hell auf dunkel ist zwar technisch korrekt, wirkt aber unfertig. Und nehmen Sie unbedingt die Zusatzaufgabe mit dem Speicher pro Anfrage mit, wenn Sie in einem solchen Umfeld arbeiten. Das ist die Sache aus diesem Kapitel, die wirklich schiefgehen kann.

16:10 Der erste Punkt ist der ernsteste des ganzen Tages, deshalb noch einmal in Klartext: Ein global angelegter Speicher auf dem Server wird von allen Anfragen geteilt. Was ein Nutzer hineinschreibt, kann ein anderer lesen. Das ist kein theoretisches Risiko, sondern ein Datenschutzvorfall, der in Tests mit einem einzigen Nutzer nie auffällt.

16:30 Der dritte Punkt ist die Testfalle mit den Ergebnissen, die von der Reihenfolge abhängen — ärgerlich, aber harmlos dagegen. Fassen wir zusammen. Ein Speicher ist hier nicht mehr als ein Hook — kein Rahmenwerk um die Anwendung, keine Zeremonie, und ausdrücklich nur für den Zustand Ihrer Oberfläche, nicht für Serverdaten. Der wichtigste Handgriff des Tages ist die gezielte Auswahl statt der Zerlegung des ganzen Speichers; sie entscheidet darüber, ob die Anwendung bei fünfzig Komponenten noch flüssig läuft.

16:58 Für Größe sorgen die Teilstücke, für Komfort die Erweiterungen — und beim Rendern auf dem Server gilt: pro Anfrage ein eigener Speicher.

Fragen & Weiterarbeiten

17:06 Alle Speicher und Übungslösungen liegen in der Freigabe. Nehmen Sie sich vor allem den Vorher-Nachher-Vergleich aus dem Kapitel zu den Neuzeichnungen mit — diesen Test können Sie nächste Woche an Ihrem eigenen Projekt wiederholen, und er dauert zehn Minuten. Die Dokumentation ist kurz und lesbar; für Sonderfälle sind die Diskussionen im Projekt-Repository oft ergiebiger als jede Suche.

17:28 Wenn bei Ihnen eine Frage aufkommt, melden Sie sich gern. Vielen Dank für Ihre Aufmerksamkeit.