You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently have a not-so-streamlined option 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. This is also done for SSR to WebSocket switching.
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 just 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 in any kind 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.
So, when we can share the state between SSR and WASM, why not try doing the same thing with WS/WASM? I mean, the page starts with SSR, then, if WASM isn't cached or outdated, fire up a WS connection. When the WASM is loaded, immediately share the state with it and leave the control of DOM to WASM, without refreshing the page.
I personally think that if this gets implemented correctly, the overall user experience can be comparable to, say React applications, or other JS-based front-end frameworks. But I'd also love to hear from you, what do you think? Is this workaround practical? Are there any better solutions?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
We currently have a not-so-streamlined option 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. This is also done for SSR to WebSocket switching.
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 just 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 in any kind 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.
So, when we can share the state between SSR and WASM, why not try doing the same thing with WS/WASM? I mean, the page starts with SSR, then, if WASM isn't cached or outdated, fire up a WS connection. When the WASM is loaded, immediately share the state with it and leave the control of DOM to WASM, without refreshing the page.
I personally think that if this gets implemented correctly, the overall user experience can be comparable to, say React applications, or other JS-based front-end frameworks. But I'd also love to hear from you, what do you think? Is this workaround practical? Are there any better solutions?
Beta Was this translation helpful? Give feedback.
All reactions