Register Blazor's ComponentHub in the IServiceCollection

[dotnetjunkie]

Some non-conforming DI Containers rely on the use of ambient state for providing scoping. This causes a challenge when it comes to integrating with with Blazor due to the way both Blazor and SignalR are set up.

Such container (such as Simple Injector) will have to replace SignalR's default IHubActivator<T> implementation in order to apply scoping. But even without ambient scoping, non-conformers will likely want to replace the IHubActivator<T> in order to resolve application hubs. When replacing IHubActivator, however, there is no way to callback into SignalR's DefaultHubActivator<T> to resolve framework hubs, such as Blazor's ComponentHub, as DefaultHubActivator<T> is internal.

Implementing a custom IHubActivator<T> likely means choosing one of the following three options:

1. Completely reimplement DefaultHubActivator<T>'s behavior in order to resolve framework types like ComponentHub
2. Resolve ComponentHub directly from the built-in container
3. Resolve ComponentHub directly from the third-party (non-conforming) container

About these options:

• Option 1 is not desirable because of the amount of code duplication it causes for integration scenarios and the possibly conflicts when the default implementation changes in the future.
• Option 3 is difficult to achieve because ComponentHub is an internal type. Neither application code, nor a third-party can access this type and accessing using reflection is brittle as the internal type could change in the future.
• Option 2 is currently impossible because ComponentHub is not registered in the IServiceCollection.

There are multiple possible solutions:

• Make SignalR's DefaultHubActivator<T> public. This allows the custom activator to create or possibly inject the default activator and call it
• Make ComponentHub public. This allows an application developer or non-conforming integration package to register it in the application container, or optionally directly into the IServiceCollection
• Register ComponentHub into the IServiceCollection. This allows a custom activator to resolve this type from the framework container without requiring ComponentHub to become public.

I think adding ComponentHub to the IServiceCollection is the easiest solution because it doesn't require making any type public, which saves writing and maintaining new documentation. Adding ComponentHub to the IServiceCollection is likely a very low-risk operation. The risk of it breaking existing applications presumably is very low.

[javiercn]

@dotnetjunkie thanks for contacting us.

I'm not very familiar with the problem. Maybe @davidfowl has some thoughts?

Is there something you could do by adding a circuit handler and calling an API on your container to set the scope?

[dotnetjunkie]

Hi @javiercn, thank you for your comment.

Is there something you could do by adding a circuit handler and calling an API on your container to set the scope?

I've done some testing with circuit handlers, but their execution doesn't seem to wrap a call to the hub activator. This makes them unsuited for applying ambient scoping, unless I'm missing something.

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.