Giters

dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.

Home Page:https://asp.net

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Allow more granular return types in signalR

NaNgets opened this issue · comments

commented

Is there an existing issue for this?

  • I have searched the existing issues

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

No response

Describe the solution you'd like

Currently you can only return a type and in the DefaultHubDispatcher it forwards it to a CompletionMessage while indicating the result or error.

This way, we can't return a type which should be handled as an error (like an error action result) so to eliminate the use of throw, nor we can return an object which will decide the return type upon processing (e.g. type unions such as in OneOf package).

I suggest we support another general return type of CompletionMessage whilst overriding the InvocationId (or create a new class with similar properties for result and error) which will allow this sort of behavior.

This will allow the application to better control the returned data (result or error).

Additional context

No response

commented

That code sample is pointing at the wrong SignalR implementation. Did you intend to file an issue on https://github.com/SignalR/SignalR? If yes, I can tell you that implementation in not being evolved anymore.

commented

My bad, I'll have to look further for the correct implementation in the current code, will update the issue ASAP.

commented

If you're going to update the issue, I'd suggest also explaining the "why". I have no idea what you are trying to accomplish from reading this issue.

commented

As I said - two scenarios I want to handle:

  1. Enable returning errors without throwing them. As you know - throw has some effect on the efficiency of the call. In the API we can return an ActionResult which will result in an HTTP error, so why not return a type which will be processed and handled as an error? Thus enabling to 'return' the error without throwing it.

  2. Enable multiple types return. I have a class, e.g. ActionResult<T1, T2>, which on API returns the type which is filled, only one (T1 or T2). In signalR I can't return that type because it will be parsed with properties I don't need\want. So I would like to be able to return a dynamic type but without the dynamic keyword, something more strong-typed, in which I might have something like GetResult which will either return the type or an error, and be handled accordingly.

commented

@davidfowl updated.