DEV Community

Discussion on: SignalR without Javascript, the Promise of Blazor

Collapse
 
slorello profile image
Steve Lorello • Edited

Hi Katie, thank you for reading, that is a valid point. While they threw out IHub<T> for SignalR Core, they replaced it with Hub<T>. You could, as you suggested, use a strongly typed interface with the Hub and drive everything through that.

I'm not entirely sold on that being cleaner, however. In the client, when you're building your HubConnection, you'd still need to tell it to register to an event with a stringified name of the called symbol.

So, if I had my Index component implement an interface IMessageClient and used a Hub extension I could call the clients like:

await Clients.All.ReceiveMessage(message);

But, I would still have to receive the message into my component like:

_hubConnection.On<Message>("ReceiveMessage", 
            (message)=>this.ReceiveMessage(message));

I found this, going from symbol => stringified Event Name versus stringified event name => stringified event name, more confusing. It's particularly odd as it doesn't enforce type-safety in the clients as there's no obligation for the client to actually implement the interface to receive the event. That's just a personal opinion, though; it could break either way.

It'd be nice if there were a HubConnection<T> in the Client library that would manage all that for you. This looks like it's something the aspnetcore team is at least considering: github.com/dotnet/aspnetcore/issue... I just upvoted this and I'd encourage you to as well :).

That's a really good suggestion though and I'd encourage anyone reading this to take it under advisement, for all we know the aforementioned issue may be resolved for .NET 5!

Collapse
 
katnel20 profile image
Katie Nelson

Okay, I up voted too. And, I looked at my code again and you are right, I used Hub<InterfaceType> for by hub. Also, on the client side, I'm using the @microsoft/signalr package in TypeScript. It could use the HubConnection<T> as you describe too.