dotnet / dotnet/aspnetcore

Blazor: Hot switching to WASM from Server Render Mode

Open
#59,641 3 comments 9 reactions 0 assignees View on GitHub
area-blazor
Dominant language
C#
Stars
38.4k
Forks
10.9k
Avg merge
2d 5h
Merged PRs (30d)
276

Description

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

We currently have a not-so-streamlined option (`PersistentComponentState`) to preserve the state between SSR and Server/WASM. For example, if a page's data is fetched from the database in the host, the host sends the data to the client WASM so it won't be queried again.

As of my knowledge, in a normal Blazor page with Render Mode set to Auto and SSR enabled, the server always sends the SSR, then, according to the conditions, decides whether the client should establish a WebSocket connection, or use the WASM to fire up the client-side interactivity. WASM is large, so first users' visits are mostly just WebSocket connections, which is not ideal, both for the user and the server. It introduces server overhead and delays all kinds of interaction for the user. But it's still better than waiting for the WASM to load, which might take a long time, depending on the project size.

### Describe the solution you'd like

When we can share the state between SSR and WASM, why not try doing the same thing with WS/WASM? The page starts with SSR, and then, if WASM wasn't cached or outdated, fire up a WS connection. When WASM is loaded, immediately share the state with it and leave the control of DOM to WASM without refreshing the page.

I think that if this gets implemented correctly, the overall user experience can be comparable to JS-based front-end frameworks.

### Additional context

_No response_

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.