Blazor Server Reconnection Gets an Upgrade in .NET 10

What’s the biggest negative that comes to mind when you think about Blazor Server?

I imagine the server disconnection experience is near the top of most people’s lists.

I recently heard from someone who steers away from using Blazor Server because their users really, really dislike seeing that reconnecting modal!

This looks set to change in .NET 10, in a couple of key areas.

But with new change comes new potential for chaos and confusion!

So here’s a quick explanation of the key changes landing in .NET 10 that affect what happens when your users lose their connection to the server.

The original problem (solved by persistent state)#

Have you ever noticed your Blazor page ‘flash’ soon after loading? If so, the chances are you’re using prerendering.

Prerendering is switched on by default for your Blazor components.

This means your components are rendered once on the server, then again in ‘Interactive’ mode (Server or WASM).

If you’re fetching data from your component this results in the data being fetched twice.

Your page loads and fetches the data during prerendering, then fetches it again when rendering in interactive mode.

The ‘flash’ occurs during that second render.

For a while now you’ve been able to use persistent state to solve that problem.

This is a way to take the data from the first render and re-use it for the second.

In .NET 10 this has becomes much easier, with the new PersistentState attribute.

[PersistentState]
public WeatherForecast[]? Forecasts { get; set; }

protected override async Task OnInitializedAsync() {

    // fetch data from DB and assign to Forecasts property

}

The weather data will be fetched during prerendering, serialized and embedded in the generated HTML, then Blazor will take that serialized data and use it during the second render.

This effectively removes the flash that would have occurred if we fetched and rendered the data a second time.

Persistent state gets new powers#

.NET 10 takes this persistent state and gives it an additional purpose.

Imagine your user loses their connection to your app. What happens next?

After a configurable period of time their original Blazor Server circuit will be evicted (to free up resources on the server).

New for .NET 10 is what Blazor does with persisted state.

When the circuit is evicted Blazor will take any data decorated with the PersistentState attribute and store it in memory, automatically.

If the user then successfully reconnects to the server (from the same tab) that data will be automatically restored to the new circuit.

From the users perspective this means they see the data they had before the disconnect.

In many cases this will be entirely seamless, without the user seeing any reconnection UX at all.

By default, the state is cached in memory, and you can switch this to HybridCache to store it in both memory and a database if needed.

Customise the reconnection UI as much (or little) as you want#

There are also changes to the reconnection UI itself (for those occasions where your users still end up seeing it).

The new Blazor project template now includes the HTML, CSS and JavaScript for the reconnection modal.

All the code for the reconnection UI is included in your project by default, so you can change it as much (or as little) as you want.

In Summary#

The reconnection experience for Blazor Server in .NET 10 looks set to less intrusive, and more easily customised than in previous releases.

.NET 10 will launch in November 2025.