-
Notifications
You must be signed in to change notification settings - Fork 10.4k
Description
Is there an existing issue for this?
- 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