Blazor WebAssembly, Teil 4: Zustandsverwaltung und Nachladen von Modulen

In diesem Teil des Tutorials werden Informationen lokal im Browser persistiert, sodass sie einen Neustart der MiracleList-Webanwendung überleben.

Lesezeit: 6 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 10 Beiträge
Von
  • Dr. Holger Schwichtenberg
Inhaltsverzeichnis

Klassische Webanwendungen mit serverseitigem Rendering sind zustandslos: Ein HTTP-Request geht auf dem Webserver ein, wird verarbeitet und irgendwann wird eine Antwort zum Browser gesendet. Nach Absenden der Antwort werden alle auf dem Webserver gesetzten Variablen vernichtet. Das ist in Blazor anders: Der Komponentenzustand mit allen gesetzten Fields und Properties bleibt erhalten, solange eine Razor Component aktiv ist. Eine Komponente ist aktiv, wenn sie

  • entweder über eine Route (relative URL) direkt aktiviert ist.
  • in eine andere Komponente eingebettet ist, die über eine Route aktiviert ist.
  • in eine andere Komponente eingebettet ist, für die der vorhergehende Satz gilt.
Blazor-Tutorial

Für die Bewahrung des Komponentenzustands über die oben genannten Fälle hinaus gibt es mehrere Alternativen in Blazor, die sowohl in Blazor WebAssembly als auch Blazor Server funktionieren (s. Tabelle).

Strategie Nicht mehr Teil der aktuellen Ansicht Reload und Browserneustart Verbindungsverlust (nur bei Blazor Server)
Sitzungszustand innerhalb von Blazor hilft hilft nicht hilft nicht
Session Storage des Browsers bzw. Session Cookies hilft hilft nicht hilft
Local Storage des Browsers bzw. persistente Cookies hilft hilft hilft
Persistierung in Datenbank oder anderem persistenten Speicher auf dem Server hilft hilft hilft

Strategien für die Zustandsbewahrung in Blazor

Die in den ersten drei Teilen des Tutorials mit Blazor WebAssembly erstellte Single-Page-Webanwendung "MiracleList" soll nun so erweitert werden, dass Benutzer sich nach einem Neustart des Webbrowsers (oder des ganzen Client-Systems) nicht noch mal erneut anmelden müssen, sondern wieder direkt beim Aufrufen der URL in die Aufgabenverwaltung gelangen. Eine Persistierung im Server würde für diesen Fall nicht helfen; vielmehr braucht es eine Information im lokalen Speicher des Webbrowsers. Diese Information sollte nicht Benutzername und Kennwort sein (das wäre ein Sicherheitsrisiko), sondern das zeitlich begrenzte Token, das das Backend-System bei der WebAPI-Operation /Login vergibt (vgl. Teil 1 dieser Serie).

Im Browserspeicher kann man mehr Daten (mehrere Megabyte, je nach Browser) ablegen, als in Cookies erlaubt ist. Auch für die Arbeit mit Cookies gibt es in Blazor keine eingebaute Funktion; man müsste auf die JavaScript-Interoperabilität oder eine entsprechende Wrapper-Komponente zurückgreifen.

Für den Zugriff auf den lokalen persistenten Speicher (Local Storage) des Webbrowsers gibt es bisher keine direkt in das Blazor-Framework integrierte Lösung, sondern einige Zusatzpakete bei NuGet.org: