skip to Main Content

I’ve been experimenting with Blazor in .NET 8 and I’m trying to understand how the Auto-render mode works. From what I’ve learned, Blazor initially uses a WebSocket connection in Auto mode to provide interactivity via server-side rendering. Then, it switches to WebAssembly (WASM) when the WASM resources are loaded in the background.

However, in my tests, I’ve noticed that there’s no interactivity available until the WASM resources are fully loaded. In the network tab of my browser, I can see a WebSocket connection, but it seems like the UI is just prerendered and not interactive.

I’ve also learned that components that are going to be rendered in WASM should be placed in the ProjectName.Client project and these components can’t be set to any render mode other than WASM (including Server mode). But if Auto mode requires the components to be interactive via a WebSocket connection (like what we have in Blazor Server apps) for the first time, how can these components be placed in the ProjectName.Client project?

In my tests, I’ve enabled network throttling to simulate a slow network, and I’ve found that Auto mode behaves almost the same as the WASM render mode. Both modes offer prerendering, but there’s no interactivity until the WASM resources are loaded, even in auto mode.

Additionally, I’ve noticed that if I disable prerendering in both WASM and auto-render modes, none of the components are visible until the WASM resources are fully loaded. This seems to contradict the idea that Auto mode should provide interactivity as soon as possible.

I’ve watched this YouTube video from Steve Sanderson, the creator of Blazor. In the video, it’s shown that when a component is loaded for the first time in Auto mode, it’s rendered and interactive using a WebSocket connection. From the second refresh, it’s loaded via WebAssembly. However, I don’t seem to observe this behavior in my tests.

Can anyone clarify how Auto mode is supposed to work in Blazor .NET 8? If it is WASM, just with prerendering, then what’s its difference with WASM render mode (as all interactive render modes have prerendering on by default)?

2

Answers


  1. Chosen as BEST ANSWER

    After weeks of investigation to find out how auto render mode works in Blazor, I found the answers.

    I can see a WebSocket connection, but it seems like the UI is just prerendered and not interactive.

    It's not right. The WebSocket connection opened with the server by Blazor is used to bring interactivity before WebAssembly is loaded. The reason that it is not noticeable is that the Wasm loads immediately after that, so the client won't have enough time to send any data via that. You can verify this behavior by enabling Network Throttling in a guest window in your browser and opening the wapp (web app).

    If Auto mode requires the components to be interactive via a WebSocket connection (like what we have in Blazor Server apps) for the first time, how can these components be placed in the ProjectName.Client project?

    Well, although the component is placed in the Wasm project, it can be rendered by Server if needed in Auto mode too. Because of the structure of .NET Blazor projects, I guess they had no other solutions other than this. And I think that's because rendering a component, that is placed in Client project, in Server mode is easier to achieve, compared to rendering a Server component in Wasm mode.

    It might seem a bit weird, but it works.

    Additionally, I've noticed that if I disable prerendering in both WASM and auto-render modes, none of the components are visible until the WASM resources are fully loaded.

    In Wasm rendering mode, you're right and this behavior is expected. But in Auto mode, the thing that happens in the background is that the wapp waits a few milliseconds for Wasm to load. If the load gets done in that time, then it won't establish a WebSocket Connection and will directly use Wasm for interactivity. But if it takes a long for Wasm to fully load, then it will make a temporary WS connection to provide interactivity before the Wasm is loaded. Again you can verify this behavior by opening the wapp in a guest window with network throttling enabled.


  2. This ticket suggests that this was fixed in version 8.0.2. I had this problem (interactivity not starting until after all the wasm is downloaded), and I verified that it’s fixed in 8.0.2. You’ll have to update the SDK and the referenced libraries to 8.0.2.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search