As you probably know by now I love event aggregation and being able to seamless forward server side events to clients. My library SignalR.EventAggregatorProxy have been around for a while now and it enables seamless event aggregation between server and client. The .NET core client library just got updated to .NET 5. And as it turns out it works without any effort in Blazor WASM.
(more…)Event Aggregation
Client – server event aggregation with React
I implemented my client/server event aggregation library in Vue yesterday and thought it was time for React. I must say React is alot different from Vue, and since I come from Knockout Vue was very easy to adopt. Though after som fiddling I got the hang of it. 😀
Client – server event aggregation with Vue
Client – server event aggregation with SignalR ASP.NET Core
Event aggregation is really a pattern i like, there is something elegant about firing events and subscribers can listen to them without knowing who fired them. This creates decoupled domains both in backends and frontends. Back in 2013, at my customer of that time we saw an increasing demand for pub / sub and immediate update. We fired events on the backend event bus and in the frontend we had SignalR Hubs that picked up the events and forwarded them to the clients. This caused duplicated and similar code both on the client and on the web server. I decided to create an abstraction layer between SignalR and the event aggregator. The result is a library called SignalR.EventAggregatorProxy
It has now been ported to support ASP.NET Core, this article will focus on the changes, for the orginal article go here.
Client server event aggregation with Angular
I dont fancy Angular much, its slow and Knockout with its MVVM approach is much cleaner, and faster since computed and observables only mutate and change view state when they actually need to (That will change with Angular 2.0). Anyway, my current customer sports Angular and then you just have to form inline 😀 We needed immediate update and you know I love event aggregation and probably know that I have a library for it, you can read more about it here!
I created a little wrapper for the the vanilla javascript client, install it using nuget
Install-Package SignalR.EventAggregatorProxy.Client.Angular
Basically it works by extending the Angular $rootScope and adds a eventAggregator function to all scopes. The eventAggregator function resolves the scope and then creates a closure with two methods, subscribe and publish. You can now listen to a event like (Serverside or client side event).
$scope.eventAggregator().subscribe(MyApp.MyEvent, onEvent);
Single Page Application with Sub-routing
One of my colleagues is working on a Single Page Application, he asked me for help on a solid design for routing and specifically about sub-routing. Sub-routing in a SPA is complex, as an example when you click a link in a list you want that item to be presented in a modal window. If you close the modal window and press back in the history you want it to show again, and if you press forward you want it to close. I choose to attack this problem with an Event Aggregation approach, where changes to the route resulted in a change event being fired to any listener. (more…)
Client – Server Event aggregation with Role Authorization
I’ve covered my SignalR Event aggregation library in an earlier post found here. That library has a Constraint API so that you can control which events a specific user should receive. It requires you to write one constraint handler for each type of event. But how about standard declarative Role Authorization?
(more…)
Client – server event aggregation with SignalR
Event aggregation is really a pattern i like, there is something elegant about firing events and subscribers can listen to them without knowing who fired them. This creates decoupled domains both in backends and frontends. At my latest customer we saw an increasing demand for pub / sub and immediate update. We fired events on the backend event bus and in the frontend we had SignalR Hubs that picked up the events and forwarded them to the clients. This caused duplicated and similar code both on the client and on the web server. I decided to create an abstraction layer between SignalR and the event aggregator. The result is a library called SignalR.EventAggregatorProxy
Anders Malmgren 