You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is the proper way to let a background process/task raise an event or notification that a Razor Component can consume?
For example, if I have a background queue processor, it might make changes to a record through a service class, and the service could raise an event or notification that the entity has changed.
Using Angular or other SPA frameworks, it was pretty easy to listen for SignalR hub messages with notifications from the service which would signal to the component to either apply the record change, or signal to the component to pull fresh data.
With Razor Components there is no SignalR connection needed to send messages, as they would all be handled server side (only the rendering is passed to the browser), but there should be a generic way to send messages to a component to enable the same kind of functionality you would have using a JS SPA framework with SignalR.
Is there, or could there be an IComponentHubContext that could be injected into backend services that would let you invoke methods on all component instances (much as you would invoke a SignalR method on a IHubContext) and it would handle calling using the appropriate execution/thread context (as opposed to running it on the thread that the service making the call is currently running on). On Blazor it could push the call to the client to execute, over the existing SignalR hub connection.
Maybe it could be constrained to calling event handler methods in the component, since such calls wouldn't be able to wait for or use the results of the methods if they had a return type.
The text was updated successfully, but these errors were encountered:
Thanks for contacting us, @keithwill.
It's actually much simpler with Razor Components in ASP.NET Core. You can inject a service you want to listen to directly into the component using the @inject directive and subscribe to the event of your interest. When the event fires, the component will handle it and should call the StateHasChanged() method to indicate that a UI update is required. That will cause the runtime to do the needful and send UI updates to the browser.
So the events would need to be async delegates if the component event handler needs to do any database or network IO to avoid causing substantial delays in user perception of the event propagation, and its probably not appropriate to do computationally expensive operations in the event handler.
What is the proper way to let a background process/task raise an event or notification that a Razor Component can consume?
For example, if I have a background queue processor, it might make changes to a record through a service class, and the service could raise an event or notification that the entity has changed.
Using Angular or other SPA frameworks, it was pretty easy to listen for SignalR hub messages with notifications from the service which would signal to the component to either apply the record change, or signal to the component to pull fresh data.
With Razor Components there is no SignalR connection needed to send messages, as they would all be handled server side (only the rendering is passed to the browser), but there should be a generic way to send messages to a component to enable the same kind of functionality you would have using a JS SPA framework with SignalR.
Is there, or could there be an IComponentHubContext that could be injected into backend services that would let you invoke methods on all component instances (much as you would invoke a SignalR method on a IHubContext) and it would handle calling using the appropriate execution/thread context (as opposed to running it on the thread that the service making the call is currently running on). On Blazor it could push the call to the client to execute, over the existing SignalR hub connection.
Maybe it could be constrained to calling event handler methods in the component, since such calls wouldn't be able to wait for or use the results of the methods if they had a return type.
The text was updated successfully, but these errors were encountered: