State Management mit Pinia

State Management mit Pinia

0:00 In Modul 7 haben wir vier Wege der Kommunikation kennengelernt und den fünften vertagt. Heute holen wir ihn nach: den Store. Es geht um Zustand, der nicht einer Komponente gehört, sondern mehreren — der angemeldete Nutzer, der Bestand, der Warenkorb. Wir sehen uns an, woran man erkennt, dass ein Store fällig ist, wie man ihn baut und wo die typischen Fallen liegen.

0:22 Und wir klären eine Frage, die noch wichtiger ist: wann man ihn besser nicht nimmt.

Bedeutung von State Management

0:28 Bevor wir über Werkzeuge sprechen, klären wir das Problem. Wann reichen Eingaben und Ereignisse nicht mehr? Diese Frage ist wichtiger als jede Einführung in eine Bibliothek, denn der häufigste Fehler in diesem Bereich ist nicht der falsche Store — es ist ein Store für etwas, das gar keinen gebraucht hätte. Ich gebe Ihnen deshalb eine Einordnung, welcher Zustand wohin gehört. Die passt auf eine Tabelle mit fünf Zeilen und beantwortet die Frage in den meisten Fällen zuverlässig.

0:55 Der entscheidende Halbsatz steht am Ende: Es ist nicht der Ersatz für Eingaben. Ein Store hält Zustand außerhalb des Komponentenbaums, damit beliebige Komponenten ihn lesen und ändern können. Das löst ein echtes Problem — aber es löst es, indem es die Ordnung des Baums aufgibt. Stellen Sie sich einen Aktenschrank im Flur vor: Sehr praktisch, wenn alle Abteilungen dieselben Akten brauchen.

1:18 Sehr unpraktisch, wenn dort auch die Notizzettel einzelner Mitarbeiter landen. Die vier Punkte beschreiben eine Entwicklung, die man in fast jedem Projekt erlebt. Zwei weit auseinanderliegende Ansichten brauchen denselben Wert. Also wandert er nach oben, bis er beiden gemeinsam ist — oft bis in die Wurzelkomponente. Und dann reichen fünf Zwischenkomponenten ihn durch, die damit gar nichts zu tun haben.

1:42 Der vierte Punkt ist die Kehrseite: Für die Gegenrichtung muss jedes Ereignis denselben Weg zurückgereicht werden. An diesem Punkt ist ein Store die ehrlichere Lösung. Diese fünf Zeilen sind die Einordnung, die ich versprochen habe. Die ersten beiden bleiben in der Komponente — eine Formulareingabe und ein Aufklappzustand gehören niemandem sonst.

2:03 Die dritte ist der Fall für bereitgestellten Kontext aus Modul 7. Die letzten beiden sind Store-Fälle. Die Fußzeile enthält die praktische Regel: Im Zweifel unten anfangen. Zustand nach oben zu verschieben ist einfach, zurück nach unten selten — weil sich in der Zwischenzeit Abhängigkeiten gebildet haben. Der zweite Punkt ist eine Eigenschaft, die man kennen muss: Zustand im Store überlebt die Ansicht.

2:27 Wenn Sie ein Formular in einem Store halten und der Nutzer die Seite verlässt und zurückkommt, steht dort noch die alte Eingabe. Manchmal ist das genau richtig, oft ist es überraschend. Der letzte Punkt ist eine Unterscheidung, über die viel gestritten wird und die ich wichtig finde: Serverdaten sind kein Anwendungszustand.

2:45 Sie sind ein zwischengespeichertes Abbild von etwas, das woanders die Wahrheit ist.

Grundlagen von Pinia

2:50 Jetzt zum Werkzeug. Pinia ist die offiziell empfohlene Zustandsverwaltung für Vue 3 und der Nachfolger des älteren Vuex. Wenn Sie schon einmal mit Vuex gearbeitet haben, werden Sie merken, dass einiges wegfällt, was dort Zeremonie war. Wenn nicht, umso besser — dann lernen Sie gleich die einfachere Variante. Die Einrichtung ist in zwei Zeilen erledigt, und danach steht Ihnen ein Werkzeug zur Verfügung, das sich in den Rest von Vue nahtlos einfügt.

3:17 Der zentrale Gedanke: Ein Store ist eine Funktion. Sie rufen sie in einer Komponente auf und bekommen den Store — und zwar immer denselben, egal wie oft und wo Sie das tun. Das klingt unspektakulär, ist aber der Unterschied zu Vuex, wo man über Zeichenketten auf verschachtelte Module zugriff. Eine Funktion kann Ihr Editor auflösen: Sie sehen die Definition, Sie sehen alle Verwendungen, Sie können umbenennen. Das ist im Alltag ein erheblicher Unterschied.

3:46 Fünf Zeilen, und wenn Sie in Modul 1 im Assistenten Ja gesagt haben, steht das schon in Ihrem Projekt. Es ist dasselbe Muster wie beim Router: erzeugen, anmelden, danach die Anwendung einhängen. Auch hier gilt die Regel aus Modul 1 — alles vor dem Einhängen. Wer die Anmeldung vergisst, bekommt beim ersten Store-Aufruf eine Fehlermeldung, die immerhin deutlich ist: Pinia sagt Ihnen, dass es nicht installiert ist.

4:11 Fünf Zeilen Vergleich, und die erste ist die, die den spürbarsten Unterschied macht. In Vuex gab es zwei Arten, Zustand zu ändern: synchrone Mutationen und asynchrone Aktionen, die wiederum Mutationen auslösten. Das war viel Zeremonie für wenig Gewinn. Bei Pinia ist das weggefallen — Aktionen ändern den Zustand direkt. Die vorletzte Zeile ist für alle relevant, die mit Typisierung arbeiten: Was bei Vuex mühsam war, funktioniert hier von selbst.

4:40 Der erste Punkt ist eine Regel, die man einmal versteht und dann nie wieder verletzt: Ein Store muss innerhalb einer Komponente oder jedenfalls nach der Anmeldung aufgerufen werden. Wer die Store-Funktion im Kopf einer Moduldatei aufruft, tut das beim Laden des Moduls — und da ist Pinia noch nicht da. Der zweite Punkt ist ein Detail beim Importieren: Der Store selbst ist die Funktion. Sie importieren also die Funktion und rufen sie auf, nicht deren Ergebnis.

Aufbau eines zentralen Stores

5:07 Pinia bietet zwei Schreibweisen an, und beide sind vollwertig. Die eine wird sich für Sie vertraut anfühlen, wenn Sie aus der Vuex-Welt kommen. Die andere wird sich vertraut anfühlen, wenn Sie die letzten neun Module mitgemacht haben — sie sieht nämlich aus wie das Innere einer Komponente. Ich zeige Ihnen beide und sage, welche ich empfehle. Beide sind vollwertig, es geht also nicht um richtig oder falsch, sondern darum, was zu dem passt, was Sie ohnehin schreiben.

5:34 Die Objektform beschreibt drei Bereiche: Zustand, Ableitungen und Methoden. Die Funktionsform ist ein Setup-Block, wie Sie ihn aus Modul 5 kennen — reaktive Werte werden zum Zustand, Ableitungen zu Gettern, Funktionen zu Methoden. Das ist eine schöne Konsequenz: Sie müssen für Stores nichts Neues lernen, sondern schreiben, was Sie ohnehin können.

5:55 Nur die Rückgabe am Ende bestimmt, was von außen sichtbar wird. Die Objektform. Beachten Sie zwei Details. Erstens: Der Zustand ist eine Funktion, kein Objekt — das ist Pflicht und der Grund steht gleich bei den Stolpersteinen. Zweitens: In den Methoden zeigt das Schlüsselwort auf den Store selbst, und Sie ändern den Zustand direkt. Kein Umweg über Mutationen, keine Zeichenkette mit einem Namen.

6:20 Wer aus Vuex kommt, wird diese Direktheit zunächst für unsauber halten — sie ist es nicht, die Werkzeuge verfolgen die Änderungen trotzdem. Und hier dieselbe Sache in der Funktionsform. Sehen Sie sich an, wie vertraut das aussieht: ein reaktiver Wert, eine Ableitung, eine Funktion. Genau wie in einer Komponente. Der Unterschied steht in der letzten Zeile — die Rückgabe bestimmt, was nach außen sichtbar wird.

6:46 Und das ist zugleich ein Vorteil, den die Objektform nicht hat: Was Sie nicht zurückgeben, bleibt privat. Sie können also Hilfsfunktionen im Store haben, die von außen niemand sieht. Vier Zeilen, und die letzten beiden sind die Argumente für die Funktionsform. Sie können darin ein Composable verwenden — etwa das Abruf-Composable aus Modul 9.

7:08 Und Sie können einen Beobachter einbauen, um auf Änderungen zu reagieren. Beides geht in der Objektform nur mit Umwegen. Die Fußzeile ist meine Empfehlung: Wer die Composition API gewohnt ist — und das sind Sie nach neun Modulen —, fährt mit der Funktionsform am besten. Der erste Punkt ist der, den ich angekündigt habe, und er ist wichtig: Der Zustand ist eine Funktion, kein Objekt.

7:31 Der Grund ist derselbe wie bei den Vorgabewerten aus Modul 7 — ein Objektliteral würde von allen geteilt. Bei einem Store fällt das selten auf, weil es meist nur einen gibt, aber beim serverseitigen Rendern wird es zum echten Problem. Der zweite Punkt ist eine Formalie: Die Kennung im ersten Argument muss eindeutig sein, sie identifiziert den Store in den Werkzeugen.

Daten speichern und abrufen

7:53 Jetzt zur Verwendung in der Komponente. Das ist unspektakulär — Funktion aufrufen, Werte lesen, Methoden aufrufen. Es gibt allerdings genau eine Falle, und die erwischt praktisch jeden beim ersten Mal. Sie hat mit dem Zerlegen zu tun, und sie scheitert stumm: Die Anwendung läuft, nur die Anzeige aktualisiert sich nicht mehr.

8:13 Deshalb behandeln wir sie ausführlich — und Sie werden merken, dass die Erklärung dahinter direkt aus Modul 5 stammt. Der Zugriff ist angenehm direkt: Zustand, Ableitungen und Methoden liegen alle auf demselben Objekt nebeneinander. Sie müssen sich also nicht merken, ob etwas ein Zustand oder eine Ableitung ist — Sie schreiben in beiden Fällen dasselbe.

8:34 Und der letzte Satz nimmt Ihnen eine Sorge aus Modul 5 ab: Kein Zusatz für den Zugriff nötig, Pinia packt die reaktiven Werte bereits aus. Solange Sie über den Store-Namen zugreifen, kann nichts schiefgehen. Sieben Zeilen, und der Weg ist der einfachste, den es gibt: Store holen, über seinen Namen zugreifen. Die Fußzeile sagt es deutlich — dieser Weg ist immer richtig.

8:57 Wenn Sie unsicher sind, schreiben Sie den Store-Namen davor, und Sie haben nie ein Problem. Der einzige Nachteil ist, dass es im Template etwas länger wird. Genau deshalb möchte man zerlegen — und genau dort liegt die Falle, die jetzt kommt. Oben der Fehler, unten die Lösung. Der obere Weg sieht völlig vernünftig aus und ist der, den jeder als Erstes probiert.

9:19 Er funktioniert sogar — beim ersten Rendern steht der richtige Wert da. Nur aktualisiert er sich nie wieder. Die Lösung ist eine Hilfsfunktion, die für Zustand und Ableitungen jeweils einen reaktiven Behälter erzeugt. Beachten Sie die letzte Zeile: Methoden brauchen das nicht, die dürfen Sie direkt entnehmen. Hier die Erklärung, und sie schließt an Modul 5 an. Der Store ist ein reaktives Objekt — kein Bündel aus einzelnen Behältern.

9:46 Wenn Sie daraus etwas entnehmen, bekommen Sie den Wert zum Zeitpunkt des Entnehmens, ohne jede Verbindung zur Quelle. Das ist exakt dasselbe Verhalten wie beim Zerlegen eines reaktiven Objekts in Modul 5. Die Hilfsfunktion baut die Verbindung wieder auf, indem sie je Feld einen Behälter erzeugt. Und Methoden brauchen keine Verbindung, weil sie an nichts hängen.

10:08 Der erste Punkt ist die Falle noch einmal, und ich betone das Wort nie: Ein zerlegter Zustand ohne die Hilfsfunktion aktualisiert sich nie wieder. Kein Fehler, keine Warnung. Der letzte Punkt ist eine Beruhigung: Zwei Aufrufe derselben Store-Funktion liefern dieselbe Instanz. Sie müssen den Store also nicht durchreichen und auch nicht darauf achten, ihn nur einmal zu holen.

10:30 Jede Komponente holt sich ihren eigenen Zugang zum selben Store — das ist der Normalfall.

Reaktive Store States

10:36 Ein kurzes Kapitel über das Ändern. Zustand im Store verhält sich reaktiv wie überall sonst, und Sie dürfen ihn direkt zuweisen — das ist der große Unterschied zu Vuex. Es gibt darüber hinaus zwei Hilfsmittel für Fälle, in denen mehrere Felder gemeinsam geändert werden sollen. Die sehen wir uns an, samt der Frage, wann Sie sie brauchen und wann nicht.

10:56 Für Vuex-Umsteiger ist dieses Kapitel das befremdlichste — deshalb erkläre ich zwischendurch auch, warum die alte Zeremonie technisch nie nötig war. Der wichtigste Satz: Ändert eine Komponente den Zustand, sehen alle anderen die Änderung sofort. Genau dafür ist ein Store da. Die drei genannten Wege unterscheiden sich nicht im Ergebnis, sondern in der Bündelung: eine einzelne Zuweisung, mehrere Felder in einem Schritt oder das Zurücksetzen auf den Anfangszustand.

11:23 Der letzte Punkt ist erwähnenswert, weil er in der Praxis oft gebraucht wird — etwa beim Abmelden, wenn alle Nutzerdaten verschwinden sollen. Fünf Zeilen. Die zweite und dritte sind Bündelungen: Mehrere Felder in einem Schritt zu ändern, macht in den Entwicklerwerkzeugen einen einzigen Eintrag statt fünf — bei der Fehlersuche angenehm.

11:43 Die letzte Zeile ist mir die liebste: eine Methode mit einem fachlichen Namen. Denn ob Sie drei Felder zuweisen oder eine Methode namens Abmelden aufrufen, macht für das Programm keinen Unterschied, für den Leser aber einen großen. Die Fußzeile nennt eine Einschränkung, die man kennen muss. Zwei Varianten. Oben die einfache mit einem Objekt — das reicht für Zuweisungen.

12:04 Unten die Funktionsform, und die brauchen Sie, sobald Sie mit Listen arbeiten: etwas anhängen, etwas entfernen, sortieren. Mit einem Objekt ginge das nicht, denn Sie wollen ja nicht die ganze Liste ersetzen, sondern sie verändern. Beide Formen fassen die Änderungen zu einem einzigen Vorgang zusammen, was in den Werkzeugen und für Abonnenten des Stores einen Unterschied macht.

12:27 Für Vuex-Umsteiger ist das der befremdlichste Teil von Pinia, deshalb hier die Begründung. Der zweite Punkt räumt die Hauptsorge aus: Die Entwicklerwerkzeuge verfolgen Änderungen trotzdem nachvollziehbar. Die Zeremonie war also nie technisch nötig. Der dritte Punkt ist trotzdem eine Empfehlung: Methoden bleiben sinnvoll, weil sie den Vorgang benennen.

12:47 Für einen einzelnen Wert ist die direkte Zuweisung völlig in Ordnung; für einen fachlichen Vorgang mit mehreren Schritten nehmen Sie eine Methode. Der zweite Punkt ist ein Grundsatz, der über Pinia hinausgeht: Zustand von außen zu ändern verteilt die Regeln über die Anwendung. Wenn zwanzig Komponenten direkt in den Store schreiben, gibt es keinen Ort mehr, an dem steht, unter welchen Bedingungen das erlaubt ist.

13:11 Der dritte Punkt ist eine praktische Einschränkung, die überrascht: Das Zurücksetzen auf den Anfangszustand gibt es nur in der Objektform. In der Funktionsform schreiben Sie es selbst — was einfach ist, aber man muss daran denken.

Getter für abgeleitete Daten

13:24 Jetzt die Ableitungen im Store, und das ist konzeptionell nichts Neues: Es ist genau das, was wir in Modul 3 über abgeleitete Werte gelernt haben, nur eine Ebene höher. Die interessante Frage ist deshalb nicht, wie es funktioniert, sondern warum es sich lohnt, eine Ableitung in den Store zu ziehen statt sie in jeder Komponente zu wiederholen.

13:43 Die Antwort hat mit Regeln zu tun, die sich ändern — und das tun sie immer. In der Objektform bekommt die Ableitung den Zustand als Argument, in der Funktionsform schreiben Sie schlicht einen abgeleiteten Wert. Beide merken sich das Ergebnis — die Regel aus Modul 3 gilt hier genauso. Das ist ein praktischer Nebeneffekt: Wenn zehn Komponenten dieselbe gefilterte Liste anzeigen, wird sie trotzdem nur einmal berechnet.

14:08 Bei einer Filterfunktion, die jede Komponente selbst aufruft, wären es zehn Durchläufe. Oben die Objektform, unten die Funktionsform. Beachten Sie in der Objektform die zweite Ableitung: Sie greift auf die erste zu und benutzt dafür das Schlüsselwort statt des Zustandsarguments. Das ist eine Feinheit, über die man einmal stolpert — mit dem Argument kommen Sie nur an den Zustand, nicht an andere Ableitungen.

14:32 In der Funktionsform stellt sich die Frage gar nicht, dort greifen Sie einfach auf die Variable zu. Ein weiterer kleiner Punkt für die Funktionsform. Der erste Punkt ist die eigentliche Begründung: Dieselbe Regel steht sonst in jeder Komponente erneut. Und Regeln haben die Eigenschaft, sich zu ändern — irgendwann gilt ein Artikel auch dann als verfügbar, wenn er reserviert, aber noch nicht abgeholt ist.

14:56 Dann wollen Sie eine Stelle ändern und nicht sieben. Der letzte Punkt ist ebenso wichtig: Der Zustand bleibt roh. Sie speichern die Artikel, nicht die gefilterten Artikel — und behalten damit alle anderen Sichten offen. Die Aufgabe ist eine Aufräumaufgabe mit einem klaren Prüfkriterium: Eine Änderung der Regel wirkt an genau einer Stelle.

15:16 Das können Sie testen — ändern Sie die Regel und sehen Sie nach, ob wirklich alle Ansichten mitziehen. Wenn eine zurückbleibt, haben Sie eine Kopie übersehen. Suchen Sie in Ihrem Projekt nach Filteraufrufen in Komponenten; das sind die Kandidaten. Erfahrungsgemäß findet man dabei zwei oder drei Stellen, die man längst vergessen hatte.

15:36 Der zweite Punkt ist eine Feinheit, die technisch interessant ist: Eine Ableitung mit Argument gibt eine Funktion zurück und verliert dabei ihr Gedächtnis. Das Ergebnis wird also bei jedem Aufruf neu berechnet. Für kleine Listen egal, für große nicht. Der dritte Punkt ist eine klare Grenze: Asynchrones gehört nicht in eine Ableitung.

15:56 Eine Ableitung rechnet, sie holt nicht. Wenn Sie beim Ableiten etwas laden wollen, brauchen Sie eine Methode — und die kommt im nächsten Kapitel.

Actions für API Kommunikation

16:06 Damit sind wir beim Zusammentreffen von Modul 9 und Modul 10: Wo gehört das Laden hin? Methoden im Store dürfen asynchron sein, und das macht sie zum naheliegenden Ort für Abrufe. Ich zeige Ihnen das Muster, den Fall mit mehreren Stores und dann die ehrliche Abwägung — denn nicht jeder Abruf gehört in einen Store. Wer das nicht trennt, hat nach einem halben Jahr einen Store, der die halbe Anwendung enthält.

16:30 Der Unterschied zu den Ableitungen ist der entscheidende: Methoden dürfen asynchron sein. Damit sind sie der richtige Ort für einen Abruf, der Daten holt und in den Zustand schreibt. Und weil Lade- und Fehlerzustand ebenfalls im Store liegen, führt die Methode sie gleich mit. Das Ergebnis ist, dass jede Komponente, die den Store benutzt, ohne Zusatzaufwand weiß, ob gerade geladen wird — auch die, die den Abruf gar nicht ausgelöst hat.

16:56 Das sieht aus wie das Muster aus Modul 9, und das ist es auch — dieselben drei Zustände, dasselbe Aufräumen im letzten Zweig. Der Unterschied ist der Ort: Diese Zustände wohnen jetzt im Store und stehen damit allen Ansichten zur Verfügung. Das ist besonders praktisch bei Anwendungen, in denen mehrere Stellen denselben Bestand anzeigen — eine Liste, ein Zähler in der Navigation, ein Diagramm.

17:19 Alle drei zeigen den Ladezustand, ohne dass jemand etwas durchreicht. Hier greift ein Store auf einen anderen zu — der Ausleih-Store fragt den Nutzer-Store, ob überhaupt jemand angemeldet ist. Das ist ein völlig normaler Vorgang, und die Fußzeile enthält die einzige Regel dazu: Der Aufruf steht innerhalb der Methode, nicht im Kopf der Datei.

17:39 Der Grund ist der aus Kapitel zwei — im Modulkopf ist Pinia noch nicht angemeldet. Diese eine Regel erspart Ihnen eine Fehlermeldung, die man beim ersten Mal nicht sofort einordnet. Der zweite Punkt ist der, der über die reine Struktur hinausgeht: Der Store kann prüfen, ob die Daten schon vorliegen. Damit wird aus dem Store ein Zwischenspeicher — die zweite Ansicht lädt nicht erneut, sondern zeigt sofort an. Das ist ein spürbarer Gewinn für die Nutzer.

18:06 Der letzte Punkt ist die Bequemlichkeit auf Ihrer Seite: Die Komponente ruft eine benannte Methode auf und ist fertig. Kein Ladezustand, kein Fehlerzweig, keine Wiederholung — das alles wohnt jetzt an einer Stelle. Der zweite Punkt ist die Kehrseite des Zwischenspeicherns, und sie wird gern übersehen: Ein Store als Cache braucht eine Regel, wann er veraltet ist.

18:28 Ohne sie zeigt Ihre Anwendung Daten von vor zwanzig Minuten an, und niemand merkt es. Der letzte Punkt ist die Abwägung, die ich angekündigt habe: Nicht jeder Abruf gehört in einen Store. Ein einmaliger Abruf für eine Detailseite, den sonst niemand braucht, bleibt besser lokal — sonst wächst der Store zur Sammelstelle.

Nutzung von Stores in verschiedenen Komponenten

18:47 Zum Abschluss die Frage nach dem Schnitt. Wie viele Stores braucht eine Anwendung, und wonach teilt man sie? Die Antwort ist erfreulich einfach und folgt demselben Prinzip wie der Komponentenschnitt aus Modul 2: nach Fachbereich. Ich zeige Ihnen den Schnitt für unser Beispielprojekt und die Gründe, warum mehrere kleine Stores besser sind als einer — technische wie menschliche.

19:09 Der erste Satz enthält die Eigenschaft, auf der alles beruht: Jeder Aufruf liefert dieselbe Instanz. Deshalb sehen alle Komponenten denselben Zustand, ohne einander zu kennen — genau das ist der Zweck. Der zweite Teil ist die Empfehlung: ein Store je Thema, nicht einer für die ganze Anwendung. Ein einziger großer Store hätte technisch dieselbe Wirkung, wäre aber in der Pflege das, was eine einzige riesige Komponente wäre.

19:35 Vier Stores für unsere Beispielanwendung, und ich möchte, dass Sie die Größenordnung im Gefühl haben: Es sind wenige, und jeder hat einen Namen aus der Fachsprache. Der letzte ist ein Sonderfall, der oft vergessen wird — Oberflächenzustand wie Hinweise und Meldungen. Der gehört tatsächlich in einen Store, weil er von überall ausgelöst und an einer Stelle angezeigt wird.

19:56 Die Fußzeile nennt die Alternative, die man vermeiden will: einer mit vierzig Feldern. Der zweite Punkt ist der technische: Der Bundler kann einen ungenutzten Store weglassen. Bei einem großen Store geht das nicht — er wird immer geladen, auch wenn die Ansicht nur ein Zehntel davon braucht. Der letzte Punkt ist der, den ich am wichtigsten finde: Abhängigkeiten zwischen Bereichen werden sichtbar. Wenn der Ausleih-Store den Nutzer-Store braucht, steht das im Code.

20:23 Bei einem einzigen Store verschwimmt das — dort hängt alles mit allem zusammen, ohne dass man es sähe. Diese Aufgabe hat zwei Teile, und der zweite ist der wichtigere: die Zwischenkomponenten von durchgereichten Eingaben befreien. Genau darin liegt ja der Gewinn — nicht darin, dass der Wert jetzt woanders liegt. Der Hinweis unten ist eine Selbstprüfung, die ich Ihnen ans Herz lege: Können Sie begründen, warum Eingaben nicht gereicht hätten?

20:49 Wenn die Antwort schwerfällt, war es vielleicht doch kein Store-Fall. Der erste Punkt ist eine Eigenschaft mit Sicherheitsbezug: Ein Store hält seinen Zustand bis zum Neuladen der Seite — auch nach dem Abmelden. Wenn dort Nutzerdaten liegen, sollten Sie sie beim Abmelden ausdrücklich löschen. Der zweite Punkt ist eine Falle bei wechselseitigen Abhängigkeiten: Zwei Stores, die sich gegenseitig im Modulkopf aufrufen, erzeugen eine Schleife beim Laden.

21:15 Die Regel aus Kapitel sieben — Aufruf innerhalb der Methode — verhindert das zuverlässig.

Geteilter Zustand

21:21 Fassen wir zusammen. Ein Store ist für Zustand, der mehreren Ansichten gehört — und die Prüfung davor, ob es wirklich einer ist, ist der wichtigste Schritt. Die Funktionsform liest sich wie eine Komponente und erlaubt Privates. Beim Zerlegen brauchen Sie die Hilfsfunktion, Methoden dürfen Sie direkt entnehmen. Im nächsten Modul wird es deutlich kleiner: Es geht um eigene Direktiven — ein schmales Werkzeug für den Rest, den Komponenten und Composables nicht abdecken.