search

dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.45k stars 10.03k forks source link

Provide a way to easily see the state associated with Blazor Server circuits #49017

Open nssidhu opened 1 year ago

nssidhu commented 1 year ago

Is there an existing issue for this?

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

By default in Blazor Server App, the Signal R State is Managed on Server(or as in Singal R service which is again on Server). Provide a state Management Explorer so that Developer knows what items are being managed in SignalR State. This would help with insgihts that developer can use to optimize SignalR State Management. Secondly it would be nice if Developer is allowed to dictate where the State is Managed, Like let some of the SignalR State be managed on client(browser) and other at server.

Describe the solution you'd like

Like how we now have in Blazor 8, we could specify where the component runs(Server Rendered, WebAssembly etc), let developers have the samilat options for Signal R State Management as well.

Additional context

No response

mitchdenny commented 1 year ago

Adding area-blazor tags to get some eyes on for it. This seems more like a Blazor ask?

@nssidhu just to confirm that your question is more focused on Blazor rather than SignalR? SignalR doesn't really have much in terms of state that could/should be delegated to the client.

nssidhu commented 1 year ago

Yes, Blazor Server

danroth27 commented 1 year ago

Provide a state Management Explorer so that Developer knows what items are being managed in SignalR State

@nssidhu Do you mean the state associated with each circuit? How do you expect to use this functionality? Is this to debug Blazor Server memory consumption issues?

Secondly it would be nice if Developer is allowed to dictate where the State is Managed, Like let some of the SignalR State be managed on client(browser) and other at server.

To shift state from the server to the client we are introduce the concept of render modes in .NET 8 so that you can choose whether interactive components are handled on the server using the Blazor Server model, or on the client using Blazor WebAssembly.

nssidhu commented 1 year ago

@danroth27 yes

Provide a state Management Explorer so that Developer knows what items are being managed in SignalR State

@nssidhu Do you mean the state associated with each circuit? How do you expect to use this functionality? Is this to debug Blazor Server memory consumption issues?

@danroth27 Yes, to see the memory consumption.

Secondly it would be nice if Developer is allowed to dictate where the State is Managed, Like let some of the SignalR State be managed on client(browser) and other at server.

To shift state from the server to the client we are introduce the concept of render modes in .NET 8 so that you can choose whether interactive components are handled on the server using the Blazor Server model, or on the client using Blazor WebAssembly. This would be great!!

Related question: Generally, in Blazor WASM, we have an option of service worker and we can handle refresh of new version with some extra JavaScript code. Would we still have to continue doing that to handle updated in case of client/web assembly render Mode?

danroth27 commented 1 year ago

Yes, to see the memory consumption.

Got it. I'm going to update the title for this issue then to more clearly reflect that.

Related question: Generally, in Blazor WASM, we have an option of service worker and we can handle refresh of new version with some extra JavaScript code. Would we still have to continue doing that to handle updated in case of client/web assembly render Mode?

Adding support for the Progressive Web App option to the Blazor Web App template, which brings in the service worker logic, is tracked by https://github.com/dotnet/aspnetcore/issues/48935.

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.

ghost commented 10 months 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.