I’ve written about Golden Layout already, but not really what I intend to do with it. I am keeping that under wraps for the most part, but I want to talk about an issue that I needed to solve in order for things to progress.
Naturally, I need to get data into these Golden Layout panels. There’s a lot of ways to do this if you check out the official website, including through React.js and Angular. I’ve looked into both, but find Angular far too obtuse for its own good, and React.js, while technically appropriate, is just not cooperating with my development environment right now. The problem, though, isn’t really getting data into a GL panel; it’s communicating between panels, but also between panels between clients.
SignalR relies on ASP.NET MVC, which is a design practice that uses a “model” — the part that processes business rules — a “view” — the part you see when you enter the URL — and a “controller” — a bridge between the model and the view.
All this mumbo jumbo aside, what’s the bottom line? Let me blow your mind in a single GIF:
The idea is that on the controller, processing would happen. We’ll do more than just accept a value from a button; we’ll need to take in a whole lot of data like a client identifier (which SignalR does, but we’ll need to supplement), input from the type of action we’re initiating, and info on how far we need to reach in serving the result. The controller would process the data, and then we’d have to determine who gets the data.
In the GIF, once we press the button we send the name “Chris” to the controller, which doesn’t have any other clients to investigate, so it merely sends “Chris” to all clients. On the client-side, the called method adds another row to the table that is being used to display the results.
The major benefit here is that we don’t rely on polling. This is commonly referred to as “event-driven”: we only act when an event is “raised” which in this case is trigger by the press of a button. When no person is taking action, no events are being raised. Because SignalR can broadcast to everyone or just a defined subset, we can divide users into bins (like regions in a game worl…I mean, chat channels) and only push the data needed to be received to the people who need to receive it. In this case, the client JS doesn’t even update the client directly; it sends a message to the server, and the server responds with the command for the client(s) to update.
The final benefit to this over simple polling is that, should there be a server-side process that does fire off without needing any user input, it can also use SignalR to select all or some of the clients to broadcast to. This could be used to send all connected clients a message at a predefined time, or in relation to a server IT or hardware event.