React v19 - State Management & Hooks

React v19+ — State Management & Hooks

0:00 Eine Oberfläche, die sich nichts merkt, ist nutzlos. Ob ein Menü offen ist, was im Suchfeld steht, welche Zeile gerade markiert ist — all das ist Zustand, und der Umgang damit entscheidet, ob eine Anwendung vorhersehbar funktioniert oder sich seltsam verhält. React nennt das State, und die Werkzeuge dafür heißen Hooks. Sie sind nicht viele, aber jeder hat seinen klaren Einsatzbereich — und die typischen Probleme entstehen fast immer dann, wenn man den falschen wählt.

0:27 Genau darum geht es heute: welchen Hook wann, und warum.

State & Hooks in React v19+

0:31 Der rote Faden führt vom einfachsten Fall bis zum eigenen Werkzeug. Wir beginnen mit `useState` — ein Wert, den sich eine Komponente merkt. Dann `useEffect`, das die Komponente mit der Außenwelt in Einklang bringt. Wird die Logik komplexer, kommt `useReducer` ins Spiel. Danach das Thema Performance, wo Sie heute weniger tun müssen als noch vor zwei Jahren. Und zum Schluss bauen Sie Ihren eigenen Hook — inklusive Test.

0:57 Fünf Kapitel, jedes mit einer Übung. Kurz zu Ihnen, bevor wir einsteigen. Hooks sind mittlerweile Alltag, aber die Erfahrung damit ist meist sehr unterschiedlich verteilt — manche nutzen `useState` täglich und haben `useReducer` noch nie angefasst. Besonders interessiert mich die zweite Frage: Wer ist schon einmal in eine Endlosschleife beim Rendern geraten oder hat sich gewundert, warum eine Variable im Effekt hartnäckig einen alten Wert zeigt?

1:23 Beides sind Klassiker, beide erklären wir heute im Detail. Und sagen Sie mir gern, was am Ende des Tages konkret sitzen soll.

useState — Lokaler State

1:31 Fangen wir beim Fundament an. `useState` ist der Hook, den jeder zuerst lernt — und das Prinzip dahinter tragen alle anderen State-Hooks ebenfalls in sich. Wer hier sauber denkt, hat es später deutlich leichter. Eine Komponente ist eine Funktion, und Funktionen vergessen normalerweise alles, sobald sie durchgelaufen sind.

1:51 `useState` ist das Gedächtnis, das React daneben stellt — Sie bekommen einen Wert und eine Funktion, um ihn zu ändern. Stellen Sie sich einen Notizzettel vor, den React für Sie aufbewahrt: Die Funktion läuft hundertmal, der Zettel bleibt liegen. Wichtig ist der zweite Teil: Wenn Sie den Setter aufrufen, ändern Sie nicht nur den Wert — Sie melden React an, dass neu gerendert werden muss.

2:13 Zustand und Anzeige bleiben so automatisch im Gleichklang. Warum nicht einfach eine normale Variable? Weil die bei jedem Rendern neu angelegt wird — Sie schreiben etwas hinein, und beim nächsten Durchlauf ist es fort. State überlebt diesen Zyklus, das ist der ganze Unterschied. Der zweite Punkt ist ebenso wichtig: Der Setter löst das Neu-Rendern gezielt aus.

2:36 Sie müssen React nirgendwo mitteilen, dass sich etwas geändert hat, das passiert automatisch. Dazu kommt die angenehme Schlankheit — kein `this`, kein Konstruktor, nur ein Funktionsaufruf. Und mehrere unabhängige Werte stehen einfach nebeneinander, statt in einem großen State-Objekt zu verklumpen. Die Schritte sind schnell erzählt, aber der vierte ist der entscheidende.

2:59 Sie deklarieren Wert und Setter als Paar, lesen den Wert im JSX und ändern ihn ausschließlich über den Setter — eine direkte Zuweisung ignoriert React schlicht. Und wenn der neue Wert vom alten abhängt, nutzen Sie die Updater-Form, also die Funktion statt des fertigen Werts. Warum das wichtig ist, sehen wir gleich am Code.

3:18 Der letzte Punkt ist eher Architektur: State so weit unten wie möglich halten. Was nur eine Komponente braucht, gehört auch nur dorthin — sonst rendert bei jeder Kleinigkeit der halbe Baum neu. Ein Zähler, unspektakulär — bis auf ein Detail. Statt `setCount(count + 1)` steht hier eine Funktion, die den aktuellen Wert bekommt und den neuen zurückgibt.

3:39 Der Unterschied wird sichtbar, wenn mehrere Updates dicht aufeinanderfolgen. React sammelt sie nämlich und arbeitet sie gebündelt ab — das nennt sich Batching. Lesen Sie dabei die Variable von außen, lesen alle drei Aufrufe denselben alten Wert, und statt drei zählen Sie einen. Die Updater-Form dagegen rechnet immer vom tatsächlich aktuellen Stand. Gewöhnen Sie sich das gleich an, es kostet nichts und erspart eine sehr schwer auffindbare Fehlerklasse.

4:08 Jetzt provozieren Sie den Effekt selbst. Bauen Sie einen Zähler, der über die Updater-Form arbeitet — das Lernziel ist genau diese Ableitung vom aktuellen statt vom eingelesenen Wert. Ihr Erfolgskriterium ist bewusst praktisch: schnell und mehrfach hintereinander klicken, und die Zahl muss lückenlos hochlaufen. Probieren Sie ruhig zuerst die naive Variante, damit Sie den Unterschied einmal mit eigenen Augen sehen — das prägt sich besser ein als jede Erklärung.

4:33 Als Erweiterung ergänzen Sie eine einstellbare Schrittweite als zweiten, unabhängigen State. Vier Fallen, die alle dieselbe Wurzel haben: State wird wie eine normale Variable behandelt. Ein direktes Hochzählen ändert zwar den Wert, meldet React aber nichts — die Oberfläche bleibt stehen, und man sucht am falschen Ende. Das Ableiten ohne Updater-Form führt zum stale State, den wir gerade gesehen haben.

4:57 Objekte und Arrays zu mutieren ist der subtilste Fall: React vergleicht Referenzen, nicht Inhalte — dieselbe Referenz bedeutet für React "nichts passiert", egal was drinsteht. Und der vierte Punkt ist eine Denkfrage: Was sich aus vorhandenem State berechnen lässt, gehört nicht in den State, sondern ins Rendern.

useEffect — Side Effects

5:16 Bis hier war alles in sich geschlossen. Aber Anwendungen leben nicht im luftleeren Raum — sie holen Daten, hören auf Ereignisse, sprechen mit Timern. Für diese Verbindung zur Außenwelt gibt es `useEffect`, den vermutlich am häufigsten missverstandenen Hook überhaupt. `useEffect` führt Code aus, nachdem gerendert wurde — für alles, was außerhalb von React passiert: ein Datenabruf, ein Timer, ein Listener am Browser-Fenster.

5:42 Das Dependency-Array bestimmt, wann der Effekt erneut läuft, und die Rückgabefunktion räumt hinterher auf. Der beste Denkrahmen dafür ist nicht Lifecycle, sondern Synchronisation: Sie beschreiben, wie die Außenwelt zu Ihrem State passen soll, und React sorgt dafür, dass das gilt. Ändert sich der State, wird nachgezogen — alte Verbindung aufräumen, neue aufbauen. Wer so denkt, stellt die Dependency-Frage von selbst richtig.

6:08 Das Rendern soll rein bleiben — Props hinein, JSX heraus, ohne Nebenwirkungen. Alles andere hat einen eigenen Platz, und der heißt Effekt. Das Dependency-Array ist dabei mehr als Formalität: Es ist Ihre Aussage darüber, wovon dieser Effekt tatsächlich abhängt, und React hält sich exakt daran. Das Cleanup verhindert die Sorte Fehler, die man erst nach einer halben Stunde Benutzung bemerkt — drei Listener auf demselben Event, ein Timer, der nach dem Schließen weiterläuft.

6:36 Und das Ganze ersetzt drei separate Lifecycle-Methoden aus der Klassen-Ära durch ein einziges Muster, das für Mount, Update und Unmount gilt. Punkt zwei und Punkt fünf sind die, an denen es sich entscheidet. Tragen Sie die Abhängigkeiten vollständig ein — jeden Wert, den der Effekt liest. Es ist verlockend, etwas wegzulassen, damit der Effekt seltener läuft, aber dann arbeiten Sie mit veralteten Werten, und der Fehler ist später kaum zu finden.

7:03 Vertrauen Sie lieber der Lint-Regel. Das leere Array ist ausschließlich für echte Einmal-Effekte gedacht, nicht als Abkürzung. Und der letzte Punkt ist der wichtigste: Was sich beim Rendern berechnen lässt, gehört nicht in einen Effekt. Das ist die mit Abstand häufigste Fehlanwendung dieses Hooks. Vier Zeilen, die das komplette Muster zeigen. Oben wird etwas aufgebaut — hier ein Timer, es könnte genauso eine WebSocket-Verbindung oder ein Event-Listener sein.

7:30 Und darunter steht die eigentliche Pointe: das `return` mit der Aufräumfunktion. React ruft sie auf, bevor der Effekt erneut läuft, und beim Verschwinden der Komponente. Merken Sie sich die Faustregel — was Sie im Effekt aufbauen, bauen Sie im Cleanup wieder ab. Ohne diese Zeile tickt der Timer munter weiter, während die Komponente längst nicht mehr existiert.

7:51 Im Entwicklungsmodus macht React das übrigens absichtlich sichtbar, indem es Effekte doppelt ausführt. In dieser Übung starten Sie eine Subscription und beenden sie zuverlässig wieder. Das Lernziel ist das Paar aus Aufbauen und Abbauen — beides gehört zusammen, immer. Das Erfolgskriterium ist gut prüfbar: Beim Verlassen der Komponente darf nichts weiterlaufen und keine Warnung in der Konsole erscheinen.

8:15 Als Erweiterung ergänzen Sie eine Abhängigkeit im Array und beobachten, was dann passiert — Sie sehen dann schön, wie React erst aufräumt und danach neu aufsetzt. Genau dieses Nachziehen ist gemeint, wenn wir von Synchronisation statt Lifecycle sprechen. Diese vier begegnen Ihnen garantiert. Fehlende Abhängigkeiten führen zu Werten, die eingefroren sind, oder zu Updates, die einfach ausbleiben — das ist der stale State in seiner unangenehmsten Form.

8:42 Fehlendes Cleanup sammelt Listener an, bis das Verhalten kippt. Ableitungen im Effekt zu berechnen kostet einen kompletten zusätzlichen Renderzyklus, weil erst gerendert, dann gerechnet, dann State gesetzt und erneut gerendert wird. Und der vierte Punkt ist der berühmte: State im Effekt setzen, der State steht in den Dependencies, der Effekt läuft wieder — die Endlosschleife, die den Browser lahmlegt.

useReducer — komplexe State-Logik

9:06 Solange Sie zwei, drei unabhängige Werte verwalten, reicht `useState` vollkommen aus. Aber irgendwann hängen die Werte voneinander ab, und die Setter verteilen sich über die halbe Komponente. Für diesen Punkt gibt es ein besseres Werkzeug. Ein Reducer ist eine Funktion mit einem festen Vertrag: Sie bekommt den aktuellen Zustand und eine Aktion und gibt den neuen Zustand zurück. Mehr nicht.

9:29 Die Komponente ruft diese Funktion nie selbst auf — sie schickt nur eine Aktion los, per `dispatch`. Denken Sie an eine Schaltzentrale: Von überall kommen Meldungen herein, aber entschieden wird an genau einer Stelle. Der Gewinn liegt in dieser Bündelung. Statt fünf Setter-Aufrufe über die Komponente zu verteilen, steht die gesamte Übergangslogik in einer Funktion, die Sie am Stück lesen können.

9:52 Und weil sie rein ist, können Sie sie auch am Stück testen. Der eigentliche Nutzen zeigt sich beim Lesen fremden Codes — oder des eigenen nach drei Monaten. Wenn alle Übergänge an einem Ort stehen, beantworten Sie die Frage "Wie kann dieser Zustand entstehen?" durch einmaliges Lesen einer Funktion statt durch Durchsuchen der Komponente.

10:12 Weil ein Reducer rein ist, testen Sie ihn ohne React, ohne Rendern, ohne Testbibliothek für Komponenten: Zustand rein, Aktion rein, Ergebnis prüfen. Und die Übergänge werden vorhersehbar — jede Änderung hat einen Namen. Bei verzahnten `useState`-Aufrufen dagegen wächst die Zahl möglicher Kombinationen still an, bis niemand mehr den Überblick hat.

10:32 Der Reducer muss eine reine Funktion sein — das ist keine Stilfrage, sondern die Bedingung dafür, dass alles andere funktioniert. Keine Netzwerkaufrufe, kein Zugriff auf die Uhrzeit, kein Zufall: gleiche Eingabe, gleiches Ergebnis. Ausgelöst werden Übergänge ausschließlich per `dispatch` mit einem sprechenden Typ — dieser Name ist später Ihre Dokumentation.

10:54 Zurückgegeben wird immer ein neues Objekt, nie das alte verändert; sonst merkt React die Änderung nicht. Und Punkt fünf ist eine ehrliche Warnung: Bei einem einzelnen Wahrheitswert ist ein Reducer schlicht Überkonstruktion. Dann bleiben Sie bei `useState`. Hier sehen Sie die Standardform: eine Funktion mit einer Verzweigung über den Aktionstyp, je Fall ein neues State-Objekt. Achten Sie auf zwei Dinge.

11:18 Erstens gibt jeder Zweig ein frisch gebautes Objekt zurück, nichts wird am alten verändert. Zweitens der Default-Zweig — er fängt alles ab, was Sie nicht kennen, und gibt den Zustand unverändert zurück, statt still `undefined` zu liefern. Unten steht der Aufruf: Sie bekommen den Zustand und die `dispatch`-Funktion. Die reichen Sie weiter, und jede Stelle in Ihrer Anwendung kann Aktionen senden, ohne die Logik zu kennen. Das ist im Kern dasselbe Prinzip, auf dem Redux aufbaut.

11:47 Diese Aufgabe ist ein Refactoring — und damit realistisch, denn genau so entsteht ein Reducer im Alltag: Sie merken, dass Ihre Setter-Aufrufe sich gegenseitig bedingen. Das Lernziel ist, diese verzahnten Übergänge in einer reinen Funktion zu bündeln. Der Erfolg ist doppelt geprüft: Alle Änderungen laufen über `dispatch`, und der Reducer lässt sich testen, ohne dass eine einzige Komponente gerendert wird.

12:10 Genau dieser zweite Punkt ist der eigentliche Gewinn. Als Erweiterung ergänzen Sie eine `reset`-Aktion und sichern sie mit einem Test ab — das sind dann buchstäblich drei Zeilen. Die ersten beiden Punkte betreffen die Reinheit, und die ist beim Reducer nicht verhandelbar. Den State zu mutieren statt ein neues Objekt zu liefern führt dazu, dass React die Änderung nicht bemerkt — die Logik stimmt, die Oberfläche bleibt stehen.

12:34 Seiteneffekte im Reducer, etwa ein Netzwerkaufruf, zerstören die Testbarkeit und werden bei doppelter Ausführung im Entwicklungsmodus unangenehm sichtbar. Der dritte Punkt ist die Übertreibung in die andere Richtung: nicht jeder Zustand braucht einen Reducer. Und ein fehlender Default-Zweig bedeutet, dass ein Tippfehler im Aktionsnamen den State kommentarlos auf `undefined` setzt.

useMemo & useCallback — Performance

12:56 Kommen wir zum Thema Geschwindigkeit — und gleich vorweg: Dieses Kapitel ist heute kürzer relevant als noch vor zwei Jahren. Was diese beiden Hooks tun, sollten Sie trotzdem verstehen, schon um alten Code zu lesen. Warum Sie sie seltener brauchen, klären wir gleich mit. Beide Hooks tun im Kern dasselbe: Sie merken sich etwas zwischen zwei Renderläufen.

13:17 `useMemo` behält das Ergebnis einer Berechnung, `useCallback` eine Funktion — und neu gemacht wird nur, wenn sich die angegebenen Abhängigkeiten ändern. Der Vergleich mit einem Nachschlagewerk trägt gut: Sie rechnen einmal und schauen danach nach, statt jedes Mal neu zu rechnen. Bei `useCallback` geht es dabei gar nicht ums Rechnen, sondern um Identität.

13:38 Eine Funktion, die bei jedem Rendern neu entsteht, ist für React eine andere Funktion — auch wenn sie identisch aussieht. Und genau das kann bei memoisierten Kindern unnötige Renderläufe auslösen. Der Nutzen ist real, aber schmaler, als viele denken. Eine wirklich teure Berechnung — Sortieren und Filtern über zehntausend Einträge — nicht bei jedem Tastendruck zu wiederholen, ist ein handfester Gewinn.

14:02 Und stabile Handler- Referenzen verhindern, dass ein memoisiertes Kind bei jedem Elternrender mitrendert. Der vierte Punkt ist allerdings der wichtigste dieser Folie: Seit Version 19 gibt es den React Compiler, und der übernimmt genau diese Arbeit automatisch. Was früher mühsame Handarbeit war und den Code mit Klammern zupflasterte, erledigt das Werkzeug. Prüfen Sie also erst, ob es überhaupt noch Ihr Problem ist.

14:27 Punkt eins ist die einzige Regel, die Sie sich merken müssen: erst messen. Die React DevTools zeigen Ihnen, welche Komponente wie lange braucht — und die Antwort ist erstaunlich oft eine ganz andere, als man vermutet hätte. Erst wenn ein Engpass belegt ist, kapseln Sie die Berechnung in `useMemo` oder stabilisieren einen Handler mit `useCallback`.

14:47 Die Abhängigkeiten geben Sie dabei vollständig und ehrlich an — dieselbe Regel wie beim Effekt, mit denselben Konsequenzen. Und im v19-Projekt lohnt vorher der Blick, ob der Compiler die Sache längst erledigt hat. Optimierung ohne Messung ist Ratespiel mit Zusatzaufwand. Zwei Zeilen, die die Anwendung zeigen — und die Fußzeile ist hier fast wichtiger als der Code.

15:09 Beide Hooks sind nämlich nicht kostenlos: React muss die Abhängigkeiten bei jedem Rendern vergleichen und die alten Werte vorhalten. Bei einer Berechnung, die ohnehin nur Mikrosekunden dauert, zahlen Sie damit drauf. Sie tauschen Rechenzeit gegen Speicher und Vergleichsaufwand, und dieser Tausch lohnt sich nur, wenn die Berechnung wirklich teuer ist.

15:29 Deshalb der Rat: Schreiben Sie diese Zeilen nicht vorsorglich, sondern als Reaktion auf eine Messung. Alles andere macht den Code schwerer lesbar, ohne ihn schneller zu machen. Diese Übung beginnt bewusst nicht mit dem Optimieren, sondern mit dem Messen. Das Lernziel ist die gezielte Memoisierung — gezielt heißt: an einer Stelle, von der Sie wissen, dass sie teuer ist, nicht überall auf Verdacht.

15:52 Der Erfolg ist eine Messung, die zeigt, dass die Berechnung nur noch bei geänderten Abhängigkeiten läuft. Nehmen Sie sich die Zeit für den Vorher-Zustand, sonst fehlt Ihnen der Vergleich. Und als Erweiterung die spannendste Frage überhaupt: Schauen Sie im v19-Projekt nach, ob der Compiler das Memo bereits selbst gesetzt hat.

16:11 Die Stolpersteine hier sind fast alle Fälle von zu viel des Guten. Pauschal alles zu memoisieren erzeugt Overhead ohne Gegenwert und macht den Code unübersichtlich. Unvollständige Abhängigkeiten liefern stale Ergebnisse — dasselbe Muster wie beim Effekt, nur dass es hier zusätzlich noch nach einem Performance-Feature aussieht.

16:29 Ohne Messung zu optimieren bedeutet, Zeit an einer Stelle zu investieren, die vielleicht gar nicht das Problem war. Und der letzte Punkt ist der neue: Manuell zu memoisieren, wo der Compiler es längst tut, ist doppelte Arbeit — und kann im Zweifel sogar im Weg stehen.

Custom Hooks — entwickeln & testen

16:45 Zum Abschluss drehen wir den Spieß um: Bisher haben Sie Hooks benutzt, jetzt bauen Sie selbst einen. Custom Hooks sind der Weg, Logik über Komponenten hinweg zu teilen — und weil sie reine Logik sind, lassen sie sich auch für sich allein testen. Ein Custom Hook klingt nach einem großen Konzept, ist aber schlicht eine Funktion, die andere Hooks aufruft — mehr steckt nicht dahinter.

17:07 Das einzige formale Kriterium ist das `use`-Präfix im Namen, und daran erkennen React und die Lint-Regeln, dass hier die Hook-Regeln gelten. Der Gedanke dahinter ist Composition auf einer neuen Ebene: Sie fassen zusammengehörige Logik hinter einer sauberen Schnittstelle zusammen und geben ihr einen Namen. Was Sie zurückgeben, bestimmen Sie selbst — ein Wert, ein Paar, ein Objekt mit Funktionen. Und ganz nebenbei entsteht damit etwas, das Sie ohne Markup testen können.

17:34 Der Kern ist einfach: Kopierte Logik läuft auseinander. Sie fixen einen Fehler an einer Stelle, die anderen beiden bleiben — das ist keine Theorie, das passiert zuverlässig. Ein Hook mit klarer Schnittstelle löst das, und diese Schnittstelle ist zugleich Dokumentation: Was geht rein, was kommt raus, mehr müssen die Nutzer nicht wissen.

17:54 Der vierte Punkt ist der, den ich am höchsten hänge: Ein Custom Hook ist isoliert testbar. Sie brauchen keine Komponente, kein Markup, keine Klicks — nur den Hook und einen Test-Renderer. Damit wird Ihre Zustandslogik zu etwas, das Sie tatsächlich absichern können. Ein Custom Hook entsteht selten am Reißbrett, sondern fast immer durch Extrahieren — Ihnen fällt Wiederholung auf, und Sie ziehen sie heraus.

18:19 Der Name beginnt mit `use`, das ist Pflicht. Was der Hook braucht, kommt als Argument hinein, was er liefert, als Rückgabe heraus; intern nutzt er ganz normal `useState`, `useEffect` und alles andere. Für den Test gibt es `renderHook` — damit prüfen Sie die Rückgabe und die Übergänge direkt, ohne Umweg über eine Komponente.

18:37 Und halten Sie die Schnittstelle klein: Was Sie einmal zurückgeben, müssen Sie später pflegen. Oben der Hook, unten im Kommentar der Test — beides passt zusammen auf eine Folie, und das ist die eigentliche Botschaft. Der Hook selbst enthält nichts Neues: ein State, eine Funktion, die ihn erhöht, zurückgegeben als Objekt mit sprechenden Namen. Interessant ist der Test darunter.

19:00 `renderHook` gibt Ihnen den Hook in einer minimalen Testumgebung, Sie greifen auf das Ergebnis zu, lösen einen Übergang aus und prüfen den neuen Wert. Keine Komponente, kein Rendern von Markup, kein simulierter Klick. Genau das meint der Satz, Ihre Zustandslogik werde durch Extraktion prüfbar — hier sehen Sie es in vier Zeilen.

19:20 Die letzte Übung führt beides zusammen. Sie kapseln Zustandslogik in einem eigenen Hook und schreiben einen Test dazu. Das Erfolgskriterium hat bewusst zwei Teile: Zwei Komponenten teilen sich denselben Hook — das beweist die Wiederverwendbarkeit —, und mindestens ein Test prüft einen Übergang. Achten Sie bei der Gelegenheit darauf, dass beide Komponenten ihren eigenen Zustand behalten; geteilt wird die Logik, nicht die Daten. Das ist eine häufige Verwechslung.

19:47 Als Erweiterung ergänzen Sie eine `reset`-Funktion und erweitern den Test entsprechend. Der erste Punkt ist reine Namensdisziplin mit echten Folgen: Ohne `use`-Präfix greifen die Lint-Regeln nicht, und Sie verlieren das Netz, das Hook-Fehler früh meldet. Der zweite ist die eiserne Regel überhaupt — Hooks werden immer in derselben Reihenfolge aufgerufen, nie in einer Bedingung, nie in einer Schleife.

20:10 React verwaltet sie intern über die Reihenfolge, deshalb bringt jede Abweichung alles durcheinander. Eine zu große Schnittstelle macht den Hook schwer verständlich und schwer testbar. Und der letzte Punkt ist tückisch: Vergessen Sie das Effekt-Cleanup im Hook, wandert das Leck künftig in jede Komponente mit, die ihn nutzt.

20:28 Ziehen wir die Linie durch den Tag. `useState` für den lokalen Wert, geändert immer über den Setter und bei Ableitungen über die Updater-Form. `useEffect` für die Synchronisation mit der Außenwelt, mit vollständigen Abhängigkeiten und einem Cleanup zu allem, was Sie aufbauen. `useReducer`, sobald Übergänge zusammengehören — dann liegt die Logik an einer Stelle und ist testbar.

20:51 Memoization nur bei gemessenem Bedarf, und im v19-Projekt oft schon vom Compiler erledigt. Und Custom Hooks als Weg, all das zu bündeln und zu teilen. Vom einzelnen Wert zum getesteten eigenen Werkzeug.

Fragen & Weiterarbeiten

21:04 Damit sind wir durch. Alle Beispiele und Übungen liegen in der Freigabe — schauen Sie besonders noch einmal auf die Stretch-Aufgaben, die Sie heute nur angerissen haben. Für alles Weitere ist react.dev die richtige Adresse: Die offizielle Dokumentation hat gerade zu den Hooks sehr gute, ausführliche Seiten und ist auf dem Stand von Version 19 — das ist wichtig, denn zu `useEffect` und Memoization kursieren im Netz viele ältere Empfehlungen, die inzwischen überholt sind.

21:30 Wenn im Projektalltag Fragen auftauchen, erreichen Sie uns unter der Adresse auf der Folie. Vielen Dank für Ihre Aufmerksamkeit.