Switch blazor hosting model without need of a reload

hez2010 commented 1 year ago

Is there an existing issue for this?

[X] I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

This is a continuation of #17678.

With #17678 being completed, we can use the Auto mode to switch from server mode to WebAssembly mode in the next time we load the page. However, how about switching the hosting model on-the-fly without need of a page reload?

Describe the solution you'd like

Support switching hosting model without need of a page reload. Blazor can switch from server mode to WebAssembly immediately after all files fetched. To achieve this, it may need to support passing the states from the server to the browser, then render the page with states fetched from the server with WebAssembly in the browser.

Additional context

No response

mkArtakMSFT commented 1 year ago

Thanks @hez2010. @MackinnonBuck didn't we have a proposal for detecting if the Blazor WebAssembly runtime is already available or not? I wonder if that with an additional event for when the runtime is ready to be loaded will suffice here.

SteveSandersonMS commented 1 year ago

A major challenge here is that automatic transfer of all possible state from server to client isn't realistic (.NET objects aren't even serializable by default), so it's likely only desirable to switch over for newly-added components, not existing ones.

But it's more complicated than that because:

When adding new child components, we can't add a WebAssembly component as a child of a Server one (it would break all kinds of patterns where children receive cascaded state from an ancestor), so it would be limited to entirely new root components. In practice, that means new pages.
What happens to things like <HeadOutlet> that tend to be in the layout? They never die, so they would never be able to switch over. So any new HeadContent provided by a new page would not be rendered.

Altogether, some much more clever design or constraints are needed for this to make sense.

I wonder if that with an additional event for when the runtime is ready to be loaded will suffice here.

Yes, that's the sort of design that might be viable. If there's an event, developers could receive it and make their own decision about whether to reload the page, knowing that this will discard any existing state on the page. I don't know for sure how practical that would be, since in many realistic apps you can't know for sure if there's currently some state in any component that you don't want to lose. It might be an OK feature for demos but less useful in the real uncertain world.

ghost commented 1 year ago

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

dotnet / aspnetcore