InteractiveAuto behavior needs more details regarding when it's using WebAssembly.

[ghost]

Description

The article says:

The .NET runtime and app bundle are downloaded to the client in the background and cached so that they can be used on future visits.

Which I interpret as once the client is fully downloaded the Auto will use WebAssembly from there on.

Examples

• Reloading an Auto page will run it as WebAssembly as expected
• Navigating back and forth between an Auto and WebAssembly page will render the Auto page in WebAssembly
• Navigating to an (Interactive)Server page and then to an Auto page will not launch the WebAssembly but instead run the Auto page as (Interactive)Server.

Thus "future visits" need to be clarified that it depends on how the visitor navigates and not only whether the runtime and app is fully downloaded.

Page URL

https://learn.microsoft.com/en-us/aspnet/core/blazor/components/render-modes?view=aspnetcore-8.0#automatic-auto-rendering

Content source URL

https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/blazor/components/render-modes.md

Document ID

7c9948a3-9886-8097-6014-492a4c21ea4e

Article author

@guardrex

[github-actions]

🍂🎁 Happy Holidays! ❄️⛄

A green dinosaur 🦖 will be along shortly to assist. Stand-by ........

[guardrex]

Thanks @breakerofbuilds ... I agree; but in the third case, I would guess the Auto page runs initially with WASM because the WASM runtime is active.

@MackinnonBuck ... Can you clarify what "on future visits" means? I'll add remarks to the article.

[guardrex]

There's one thing that we'll probably need to add (I'll look on Monday to see how we're handling it) ... Auto components are still prerendered on the server. Therefore, we'll need to make sure that it's clear that even if the Blazor runtime is active on the client, there's a prerendering step on the server. Then, we need to flesh out if page transitions affect CSR. I don't think so ... I think after the Blazor client becomes active (and after prerendering) that Auto components always render on the client. However, I assumed that was the case from product unit remarks and didn't inquire further.

[guardrex]

Perhaps, the line that can cover it is ...

After prerendering has occurred on the server and the Blazor runtime has activated on the client, Auto components always use WebAssembly, regardless of the render mode used by component that the user has navigated from.

.... something along those lines.

When Mackinnon gets on, he'll be able to say if that's accurate.

[ghost]

It may be correct but missing clarification for this crucial part:

and the Blazor runtime has activated

The missing information here is: When is the runtime activated?

I assumed incorrectly that it would activate whenever the runtime was cached(and the page reloaded after being cached the first time).

[guardrex]

That should be true tho. I have a feeling that we might hit a problem that Steve Sanderson has called out several times about lifecycle methods over the years, namely that our documentation isn't going to be able to cover exactly when things happen because the framework is complicated and timing is a bit arbitrary (e.g., network lags, task completion, etc.). The runtime activates after it and the app bundle are downloaded, and we might not be able to be more specific than that. Mackinnon can comment on this aspect as well.

[ghost]

I see.

Then the problem I see with the documentation is that is makes statements based on conditions that are undefined(runtime being loaded).

The .NET runtime and app bundle are downloaded to the client in the background and cached so that they can be used on future visits.

In the next paragraph it says:

but on subsequent visits it's rendered from the client after the .NET runtime and app bundle are downloaded and cached.

Instead it could say something like this.

The component is initially rendered with interactive server-side rendering (interactive SSR) using the Blazor Server hosting model. The .NET runtime and app bundle are downloaded to the client in the background and cached so that they can be used on future visits.
On subsequent visits a runtime algorithm determines each time whether to render the component with InteractiveServer or InteractiveWebAssembly. The runtime being cached is a requirement but not a guarantee that the component will render using InteractiveWebAssembly.

And in the second paragraph:

...from the server, but on subsequent visits it's rendered from the client after the .NET runtime and app bundle are downloaded and cached.

Into

...from the server . On subsequent visits it's rendered from either the client or the server.

[guardrex]

No, your proposed language isn't correct based on what they told me. I was told that if the app bundle and runtime are cached on the client they will be used for Auto component rendering (i.e., WASM will be used at that point). If you can demonstrate that isn't the case, you'd need to open an issue on the PU's repo to show them. You may have found a bug in the framework.

https://github.com/dotnet/aspnetcore/issues

[guardrex]

What I'm saying is that the exact timing of when that happens is indeterminate ... when the download is finished and exactly when the runtime starts. AFAIK, that can't be predicted exactly.

[ghost]

Ok, my initial observation was that the rendermode used with Auto was determined by what rendermode the user was navigating from.

I will open a bug report.

[guardrex]

... and whatever might be going on like that we would need to get in. These articles were all checked over by the PU, but behaviors and details do sometimes get left out on the first pass setting up new docs.

Please add ...

cc: @guardrex https://github.com/dotnet/AspNetCore.Docs/issues/31228

... to the bottom of your opening comment of your PU issue so that I can follow along.

I still want to work on the text. Leave this open. It will close automatically later when the PR merges.

[guardrex]

Thanks @breakerofbuilds ... That's perfect. I'll keep an 👂 open there for their response.

[guardrex]

Ok ... now we know. 😄 Indeed! The full logic wasn't explained to me when we put the coverage up.

I'll get to this fairly fast ... next week tho. I'm buried in other work at the moment trying to get our 8.0 snippet sample apps in place and cross-linked for doc snippets. I'll get back to this as soon as I can 🏃‍♂️🏃‍♂️🏃‍♂️🏃‍♂️🏃‍♂️🏃‍♂️🏃‍♂️🏃‍♂️🏃‍♂️🏃‍♂️😅.

[bxjg1987]

same issue :dotnet/aspnetcore#52719

[guardrex]

It's already cross-linked via @breakerofbuilds's issue. I see the related ones ... Artak probably marked all of them. I'll survey all of them when I work on this.

[guardrex]

UPDATE ... I'm trying to get back to this issue, but I'm a bit ⛰️⛏️😅 at the moment on other high priority work items. I hope to reach this issue next week before taking off for the holiday break ⛄.

[guardrex]

OK ... I'm finally 😅 BACK! 😄 I've been buried in work for weeks, often putting out emergency 🔥🚒 that have cropped up in coverage.

I'm going to see about resolving this issue now.