Skip to content

Provide default implementation for IHubFilter.InvokeMethodAsync #23968

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jul 22, 2020

Conversation

BrennanConroy
Copy link
Member

@halter73 mentioned we should probably add a default for this as well. It's not too hard to imagine filters being written that don't want to implement InvokeMethodAsync.

@BrennanConroy BrennanConroy added the area-signalr Includes: SignalR clients and servers label Jul 15, 2020
@BrennanConroy BrennanConroy requested a review from halter73 as a code owner July 15, 2020 19:12
@@ -19,7 +19,7 @@ public interface IHubFilter
/// <param name="invocationContext">The context for the method invocation that holds all the important information about the invoke.</param>
/// <param name="next">The next filter to run, and for the final one, the Hub invocation.</param>
/// <returns>Returns the result of the Hub method invoke.</returns>
ValueTask<object> InvokeMethodAsync(HubInvocationContext invocationContext, Func<HubInvocationContext, ValueTask<object>> next);
ValueTask<object> InvokeMethodAsync(HubInvocationContext invocationContext, Func<HubInvocationContext, ValueTask<object>> next) => next(invocationContext);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be worth adding a simple test that verifies you don't have to implement InvokeMethodAsync.

@BrennanConroy BrennanConroy added this to the 5.0.0-rc1 milestone Jul 16, 2020
@@ -19,7 +19,7 @@ public interface IHubFilter
/// <param name="invocationContext">The context for the method invocation that holds all the important information about the invoke.</param>
/// <param name="next">The next filter to run, and for the final one, the Hub invocation.</param>
/// <returns>Returns the result of the Hub method invoke.</returns>
ValueTask<object> InvokeMethodAsync(HubInvocationContext invocationContext, Func<HubInvocationContext, ValueTask<object>> next);
ValueTask<object> InvokeMethodAsync(HubInvocationContext invocationContext, Func<HubInvocationContext, ValueTask<object>> next) => next(invocationContext);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are hub filters an interface with a default implementation rather than an abstract base class?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're rebels. I actually think it's a good experiment to try this on

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a fan of how people generally call base.FunctionName(); (and intellisense adds it automatically) with abstract base classes when the base class does nothing

@BrennanConroy
Copy link
Member Author

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 2 pipeline(s).

@BrennanConroy BrennanConroy merged commit a8c39e9 into master Jul 22, 2020
@BrennanConroy BrennanConroy deleted the brecon/default branch July 22, 2020 23:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-signalr Includes: SignalR clients and servers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants