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.
- Dr. Holger Schwichtenberg
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.
Bewahrung des Zustands
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.
NuGet-Pakete
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:
- Blazor.Extensions.Storage bietet Zugang zum Session Storage und Local Storage.
- Blazored.LocalStorage bietet nur Zugang zum Local Storage.
- Blazored.SessionStorage bietet nur Zugang zum Session Storage.
- Microsoft.AspNetCore.ProtectedBrowserStorage: Microsoft selbst stellt ein NuGet-Paket für die Speicherung im Browser Storage bereit. Es verschlüsselt die Daten im Browserspeicher mit der Data Protection API (DAPI) von ASP.NET. Das Paket funktioniert allerdings nur in Blazor Server.
