APIs for components to persist state across circuits manually

[javiercn]

This is tracking the next piece of #27576. (Pointing out that this issue has additional 20 reactions)

We want to provide the ability for circuits to be paused and stored in "permanent" storage to make possible certain scenarios:

• Migrating circuits across servers.
• Freeing up resources when the circuits become idle.
• Enabling reconnection to an existing session even after the circuit has been discarded.

Our goal is that circuits stored this way can be restored in a similar fashion as when they are restored after prerendering.

Important note

This is not a suggestion that circuits could automatically be persisted in their entirety. In general that's not possible as much of the system state is not even serializable, and we don't require developers only to work with serializable data. Rather, what we may be able to do here is provide some APIs by which you can load and save state in your components, so that if a user loses their circuit, we can reload that manually-saved state in the new circuit. It could not be a global or automatic thing.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

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.

[mkArtakMSFT]

@javiercn should this be closed in favor of the linked issue ? We now have both on the .NET 7 milestone

[nkosi23]

@mkArtakMSFT this ticket is different in that it includes scope explicitly excluded from the other ticket. This ticket will enable both seamless scale out and transparent user-friendly failovers on application update deployments. These are 2 huge features that will finally enable Blazor Server to be used for mid and high-traffic consumer-facing applications.

Thank to this ticket, many people will use Azure for their consumer applications considering the built-in SignalR service and the auto-scaling capabilities. Considering the huge productivity boost provided by Blazor Server I believe this ticket will position Blazor Server and Azure as the leading Web Development stack. With this regard, shipping this in .NET 7 would make the timing perfect.

Generally speaking, this ticket will essentially allow users to treat the servers hosting Blazor Server Apps like stateless servers even though Blazor Server itself would remain stateful. This enables the two aforementioned use cases (which are major ones) and will also simplify a lot of other essential things from an infrastructure management / devops perspective.

This ticket is awaited by a lot of people as can be seen in the popularity of this reddit thread.

[javiercn]

#41791

[jonrmorgan99]

@SteveSandersonMS I've been using https://github.com/SteveSandersonMS/StatefulReconnection a bit. The form handling and smoother reconnection is a much better experience imo. So much so, I'm reluctant to upgrade to .net 8 preview 7 because StatefulReconnection doesn't work with it [without modification]. ;-D

@kijanawoodard Were you able to modify StatefulReconnection to work with Net8 ?

Dan Roth's workaround script in https://github.com/dotnet/aspnetcore/issues/10325 worked fine in my apps through Net7 but not so well in Net8 interactive server mode.

So this issue rumbles on with a possible fix for net9. IMHO it is a key issue preventing Blazor getting real traction.

[Mike-E-angelo]

So this issue rumbles on with a possible fix for net9. IMHO it is a key issue preventing Blazor getting real traction.

I, too, was wondering what the status of this issue is now that .NET8 has been released. I see that it's part of the Complete Blazor Web pillar but it's unclear what that means.

It would be ideal to get this formalized and part of the next major release. 👍🙏

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[Mike-E-angelo]

Thank you @mkArtakMSFT, @SteveSandersonMS, @danroth27, and team for all your efforts out there! 🙏

Happy Holidays 🎅⛄❄

[kijanawoodard]

@jonrmorgan99

@kijanawoodard Were you able to modify StatefulReconnection to work with Net8 ?

No. Just popped in here to see if there was any development before giving it another shot. At the moment, I don't need to preserve forms, I'm just looking to reload the page after a redeploy rather than getting stuck on the "reload" overlay.

[JoshuaDBruton]

I think Blazor Server is currently unusable because of this. Very much regret building much of our internal application with it; especially with the insane length of time this has taken to resolve, over 3 years with no traction or progress whatsoever.

[KonnectSalon]

Why are we moving this to .net 10?

[danroth27]

Why are we moving this to .net 10?

Hi @KonnectSalon. Unfortunately, we no longer believe we have the time and resources available to deliver this feature for .NET 9. You can see the full roadmap of what we do plan to deliver for .NET 9 here: https://aka.ms/aspnet/roadmap.