InteractiveAuto rendermode determined by from where the user was navigating

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

It's unclear how a page with rendermode InteractiveAuto should behave.
The documentation appear to say that once the runtime is cached subsequent loads should use WebAssembly. However in practice the rendermode used appear to be depending on what the last visited page was using.

Expected Behavior

Once the runtime is cached, loading a page with rendermode InteractiveAuto should render it using WebAssembly.

Steps To Reproduce

Create 3 pages, one with their own rendermode: InteractiveAuto, InteractiveWebAssembly, InteractiveServer.
Add some code to the InteractiveAuto page indicating what mode it's using, for example @Directory.GetCurrentDirectory().

Load the page with InteractiveAuto, first time it is running on the server as expected.
Reload the page, now it's running in the client as expected.
Navigate to the InteractiveWebAssembly page and then back to the InteractiveAuto page, the page is still rendering in the client as expected.

Navigate to the InteractiveServer page and then back to the InteractiveAuto page. Now the InteractiveAuto page is running on the server.

It appears that whether an InteractiveAuto page is loading on the server or the client is based on whether the runtime is running or not, and the state of the runtime is started/stopped by visiting the InteractiveWebAssembly/InteractiveServer.

This it's not based on whether the runtime is cached or not.

Exceptions (if any)

No response

.NET Version

8.0.100

Anything else?

cc: @guardrex dotnet/AspNetCore.Docs#31228

[javiercn]

@breakerofbuilds thanks for contacting us.

It's a bit more nuanced than that. If the webassembly runtime has not yet been started and there is a server runtime started (which starts much faster) the component might render in that mode.

That can happen if there is a component on the page that renders in server mode unconditionally.

@MackinnonBuck can you add details here?

[guardrex]

If the webassembly runtime has not yet been started and there is a server runtime started (which starts much faster) the component might render in that mode.

That part we cover. 👍

That can happen if there is a component on the page that renders in server mode unconditionally.

We don't cover that scenario or any other scenario that would ever render an Auto component on the server after the runtime/app bundle arrives and the runtime activates.

I'm 👂 here for what to add ... or @MackinnonBuck, you can leave remarks on @breakerofbuilds's documentation issue at ...

dotnet/AspNetCore.Docs#31228

[MackinnonBuck]

The logic determining which render mode to use looks like the following:

1. If there exist components using WebAssembly interactivity, use WebAssembly interactivity.
2. Otherwise, if there exist components using Server interactivity, use Server interactivity.
3. Otherwise, if WebAssembly resources have loaded, use WebAssembly interactivity.
4. Otherwise, if WebAssembly resources have not been cached, use Server interactivity.
5. Otherwise, don't make the component interactive until something causes one of the above cases to become true (e.g., WebAssembly resources finish downloading).

Fun fact: The actual auto mode logic reads almost exactly like the above.

The reason that Auto mode prefers to use the existing interactivity mode is to avoid introducing a new interactive runtime that doesn't share any state with the existing one. For example, if a <HeadOutlet> component gets rendered with server interactivity, you wouldn't want an Auto component containing a <HeadContent> to use WebAssembly interactivity, because the <HeadOutlet> and <HeadContent> wouldn't be able to communicate with each other.

[guardrex]

Thanks @MackinnonBuck ... Between this and remarks on the other issues, I'll be able to place coverage. I'll ping you on the docs PR next week. I'm 🏃 on a few other items at the moment.

[bxjg1987]

@MackinnonBuck

The reason that Auto mode prefers to use the existing interactivity mode is to avoid introducing a new interactive runtime that doesn't share any state with the existing one. For example, if a <HeadOutlet> component gets rendered with server interactivity, you wouldn't want an Auto component containing a <HeadContent> to use WebAssembly interactivity, because the <HeadOutlet> and <HeadContent> wouldn't be able to communicate with each other.

Should we hand over control to users?

In my project, some components on the same page use server rendering mode because they want it to be real-time, while the other components use auto mode because they want to save server memory.

[ElderJames]

I have the same issue.