Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

APIs for components to persist state across circuits manually #30344

Open
javiercn opened this issue Feb 21, 2021 · 145 comments
Open

APIs for components to persist state across circuits manually #30344

javiercn opened this issue Feb 21, 2021 · 145 comments
Assignees
Labels
area-blazor Includes: Blazor, Razor Components enhancement This issue represents an ask for new feature or an enhancement to an existing one feature-blazor-server feature-circuit-lifecycle Issues to do with blazor server lifecycle events Needs: Design This issue requires design work before implementating. needs-prototype Pillar: Complete Blazor Web Priority:1 Work that is critical for the release, but we could probably ship without triaged

Comments

@javiercn
Copy link
Member

javiercn commented Feb 21, 2021

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.

@javiercn javiercn added the area-blazor Includes: Blazor, Razor Components label Feb 21, 2021
@javiercn javiercn added this to the 6.0-preview3 milestone Feb 21, 2021
@javiercn javiercn added the Needs: Design This issue requires design work before implementating. label Feb 21, 2021
@javiercn javiercn self-assigned this Feb 21, 2021
@mkArtakMSFT mkArtakMSFT added the enhancement This issue represents an ask for new feature or an enhancement to an existing one label Feb 23, 2021
@ghost
Copy link

ghost commented Mar 19, 2021

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.

@javiercn javiercn added feature-blazor-server feature-circuit-lifecycle Issues to do with blazor server lifecycle events labels Apr 20, 2021
@ghost
Copy link

ghost commented Jul 20, 2021

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.

@pranavkm pranavkm modified the milestones: Backlog, .NET 7 Planning Oct 19, 2021
@pranavkm pranavkm added the Priority:1 Work that is critical for the release, but we could probably ship without label Oct 28, 2021
@mkArtakMSFT
Copy link
Member

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

@nkosi23
Copy link

nkosi23 commented Mar 17, 2022

@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
Copy link
Member Author

#41791

@Mike-E-angelo
Copy link

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
Copy link

ghost commented Dec 19, 2023

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
Copy link

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

Happy Holidays 🎅⛄❄

@kijanawoodard
Copy link

kijanawoodard commented Dec 26, 2023

@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.

@SteveSandersonMS SteveSandersonMS changed the title Pause and resume Blazor Server circuits APIs for components to persist their state across circuits explicitly Jan 24, 2024
@SteveSandersonMS SteveSandersonMS changed the title APIs for components to persist their state across circuits explicitly APIs for components to persist state across circuits manually Jan 24, 2024
@JoshuaDBruton
Copy link

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
Copy link

Why are we moving this to .net 10?

@danroth27
Copy link
Member

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.

@wstaelens
Copy link

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.

this is also our biggest complaints that our customers have, the reloads/disconnects of blazor server.

@JoshuaDBruton
Copy link

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.

this is also our biggest complaints that our customers have, the reloads/disconnects of blazor server.

Now I think it is more of a problem with HTML-over-the-wire and web sockets in general; I think Blazor Server sounded like a good idea but ultimately should not be used in production.

@nbiada
Copy link

nbiada commented Jul 9, 2024

Now I think it is more of a problem with HTML-over-the-wire and web sockets in general; I think Blazor Server sounded like a good idea but ultimately should not be used in production.

The reload/disconnect situations could be managed via javascript.
When the disconnect happens I intercept the case and redirect the client to the home page.
With the .net 8 version I can create a full static (server rendered) home page, so I need to use the websocket only on forms and complex pages.
Currently I have a lot of Blazor Server website in production and I have no issue from the clients.

@JoshuaDBruton
Copy link

The reload/disconnect situations could be managed via javascript. When the disconnect happens I intercept the case and redirect the client to the home page. With the .net 8 version I can create a full static (server rendered) home page, so I need to use the websocket only on forms and complex pages. Currently I have a lot of Blazor Server website in production and I have no issue from the clients.

What is great about traditional MVC applications is that you don't have to worry at all about only using AJAX or whatever only on certain low-traffic pages because the majority of the computation for rendering and animations is always done on the client. I think web sockets basically cap the usage of your application at about ~100 users, which is fine for some small internal applications but is a severe limitation that I think people should be warned about. Even at low usage, I think the cost and user experience will be worse than if the app was developed using more traditional front-end JS; maybe only viable for MVPs or enterprise system where usability is not of high-importance.

@Mike-E-angelo
Copy link

In the case of my Blazor application deployed to Azure, I have processed closing in on $15K of volume via Stripe, PayPal, and Coinbase Commerce. This seems pretty production-ready to me. I use Azure SignalR to remove the WebSocket connection challenges. Everything has always been lightning fast and the bottleneck for me is SQL which has been a huge learning lesson for me during this time.

From my experience of actually deploying a Blazor application, everything is pretty awesome and the runtime works incredibly well. It's the socket state/management that has been the sore spot, particularly with iOS devices which disconnect when you simply alt-tab away. 💥😢

@wstaelens
Copy link

Now I think it is more of a problem with HTML-over-the-wire and web sockets in general; I think Blazor Server sounded like a good idea but ultimately should not be used in production.

The reload/disconnect situations could be managed via javascript. When the disconnect happens I intercept the case and redirect the client to the home page. With the .net 8 version I can create a full static (server rendered) home page, so I need to use the websocket only on forms and complex pages. Currently I have a lot of Blazor Server website in production and I have no issue from the clients.

care to share your interception logic?

@Mike-E-angelo
Copy link

https://www.reddit.com/r/Blazor/comments/1egnkew/a_lot_of_the_features_i_was_looking_forward_to_in/

@yablos
Copy link

yablos commented Aug 9, 2024

Hi, real word scenario(even worse) with IOS 17.6:

<InputFile accept="image/*" capture="camera" OnChange.... />

  • if you use at blazor-server page simple "camera input", just for capturing photo, the Circuit disconnects ~ about 3s after clicking the input. You are in the middle of the capturing proces(and page at background kills the websocket circuit), so after finishing capturing, the image is "lost". Curcuit is NOT trashed, but disconnected. After returning from capturing, is "resumed", but image is lost(because of the sequence -> click capture->websocket disconected->finished capture->return data to the page= NOGO, we are disconected->resumed connection-> you are back at page, but without "image/data").

If this is new behavior with ios, so capturing images are broken.

  • solution? none
  • workaround? you have to point user go throught galery/pick file, there take the photo and so on.... uhoh

@SteveSandersonMS
Copy link
Member

SteveSandersonMS commented Aug 9, 2024

@yablos That does sound like a problem but is not exactly the same as this issue. Would you mind filing it as a new issue? I can't guarantee this is something Blazor can control but either way having an issue makes it possible to track.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-blazor Includes: Blazor, Razor Components enhancement This issue represents an ask for new feature or an enhancement to an existing one feature-blazor-server feature-circuit-lifecycle Issues to do with blazor server lifecycle events Needs: Design This issue requires design work before implementating. needs-prototype Pillar: Complete Blazor Web Priority:1 Work that is critical for the release, but we could probably ship without triaged
Projects
None yet
Development

No branches or pull requests