Blazor State Management

Where to persist state

Common locations exist for persisting state:

• Server-side storage
• URL
• Browser storage
• In-memory state container service

Server-side storage

For permanent data persistence that spans multiple users and devices, the app can use independent server-side storage accessed via a web API. Options include:

• Blob storage
• Key-value storage
• Relational database
• Table storage

After data is saved, the user’s state is retained and available in any new browser session.

Because Blazor WebAssembly apps run entirely in the user’s browser, they require additional measures to access secure external systems, such as storage services and databases. Blazor WebAssembly apps are secured in the same manner as Single Page Applications (SPAs). Typically, an app authenticates a user via OAuth/OpenID Connect (OIDC) and then interacts with storage services and databases through web API calls to a server-side app. The server-side app mediates the transfer of data between the Blazor WebAssembly app and the storage service or database. The Blazor WebAssembly app maintains an ephemeral connection to the server-side app, while the server-side app has a persistent connection to storage.

URL

For transient data representing navigation state, model the data as a part of the URL. Examples of user state modeled in the URL include:

• The ID of a viewed entity.
• The current page number in a paged grid.

The contents of the browser’s address bar are retained if the user manually reloads the page.

Browser storage

For transient data that the user is actively creating, a commonly used storage location is the browser’s localStorage and sessionStorage collections:

• localStorage is scoped to the browser’s window. If the user reloads the page or closes and re-opens the browser, the state persists. If the user opens multiple browser tabs, the state is shared across the tabs. Data persists in localStorage until explicitly cleared.
• sessionStorage is scoped to the browser tab. If the user reloads the tab, the state persists. If the user closes the tab or the browser, the state is lost. If the user opens multiple browser tabs, each tab has its own independent version of the data.

 Note

localStorage and sessionStorage can be used in Blazor WebAssembly apps but only by writing custom code or using a third-party package.

Generally, sessionStorage is safer to use. sessionStorage avoids the risk that a user opens multiple tabs and encounters the following:

• Bugs in state storage across tabs.
• Confusing behavior when a tab overwrites the state of other tabs.

localStorage is the better choice if the app must persist state across closing and re-opening the browser.

 Warning

Users may view or tamper with the data stored in localStorage and sessionStorage.

In-memory state container service

Nested components typically bind data using chained bind as described in ASP.NET Core Blazor data binding. Nested and un-nested components can share access to data using a registered in-memory state container. A custom state container class can use an assignable Action to notify components in different parts of the app of state changes. In the following example:

• A pair of components uses a state container to track a property.
• The components of the example are nested, but nesting isn’t required for this approach to work.

Sources:

https://docs.microsoft.com/en-us/aspnet/core/blazor/state-management?view=aspnetcore-5.0&pivots=webassembly