Guidance for cross-server state management in Blazor

[SteveSandersonMS]

This is part of #10472

Provide examples/guidance around state management when reconnecting to a different server.

This can include patterns like storing state in localStorage or a database, and addressing the question of whether/how to restore some level of UI state. For server-side state storage, how do we associate the state with the circuit, and how do we ensure we clean it up at the right time?

Consider whether it makes sense ever to do this on a per-component basis, as opposed to on an app-wide basis

[SHAGGAR]

It would be cool if in addition to this kind of cross-server state management there could also be a way for the application to do cross-browser state management. I'm mostly thinking of scenarios where the user's browser is closed and then they reopen the application. This could be because the browser crashed or the user went to lunch or maybe they just closed the browser cause that's what users do sometimes..

The idea would be while the user uses the application, state changes could be persisted to long term storage related to some kind of unique id. The application would be responsible for associating that id with a user or session within the application since users and application workflow concepts are independent of blazor. If the user closes their browser and then opens up a new application session (lets say on a new device) the application can dig their unique state id out of the application specific database and then provide it to the state manager which can then pull the blazor state out of storage. The user then resumes the application where they left off.

Im sure im not alone in having users that do their best to interrupt their workflow in fun and interesting ways, so having a way to defend against it would be great. The added benefit of letting users close their session and resume it where off would be a bonus.

I realize this can all be done entirely outside of blazor by managing the application workflow state separately from the UI, but if you guys are planning to create this state management mechanism then maybe we can reuse it and save a bunch of development time.

[SteveSandersonMS]

I realize this can all be done entirely outside of blazor by managing the application workflow state separately from the UI

We'll definitely not be proposing a way to persist the UI itself, since in general it's not serializable, and there's no general way to recover the entire spectrum of state (arbitrary referenced values in .NET memory, arbitrary state in the JavaScript runtime e.g., following JS interop calls).

What we will offer is guidance on managing the application workflow state separately from the UI. I think there will be some commonly reusable patterns that solve a bunch of edge cases that developers might not necessarily anticipate, and the guidance will spare everyone from having to reinvent this the hard way.

[SHAGGAR]

Thanks for the clarification. I wasn't sure on if the state was serializable and I hadn't even considered javascript interop, so this all sounds good.

[SteveSandersonMS]

OK, I've written up some detailed guidance about this that I hope can go into our documentation.

I've opened dotnet/AspNetCore.Docs#13259, so let's consider this "done" as far as the aspnetcore repo is concerned - it's now a matter of converting the content into a doc page.