Aspnetcore: How to integrate non-conforming containers with Razor Components?

[dotnetjunkie]

At the moment, Razor Components seem to be tightly coupled to the built-in IServiceProvider model, which makes it hard to hook into the pipeline using an interception point, similar to IControllerActivator and IViewComponentActivator.

Up until recently, Razor Components didn't even allow conforming containers to be integrated, but this has been fixed. That model, however, does not work well for non-conforming containers, as they leave the built-in infrastructure in place, and only hook into framework-supplied seams.

What is the best way to intercept the creation of Razor Components? If there is no way to do so, please introduce the correct seam.

/cc @davidfowl

[mkArtakMSFT]

We've moved this issue to the Backlog milestone. This means that it is not going to happen for the coming release. We will reassess the backlog following the current release and consider this item at that time. However, keep in mind that there are many other high priority features with which it will be competing for resources.

[davidfowl]

We should discuss it to determine what the missing extensibility points are then decide.

[dotnetjunkie]

Thanks @davidfowl,

I've been browsing through the current code and implementation, and find it odd that those UI Components are not resolved from the container. Instead, they are created using Activator.CreateInstance, which forces them to have a default constructor. Instead, services are wired through property injection.

Perhaps I don't understand the constraints, but to me it seems a very weird design decision, considering that everything else in the framework relies on constructor injection. The design around these UI Components seems wildly different.

Instead, I'd suggest supporting constructor injection instead, and ditching property injection completely. This way, UI Components can simply be registered in the IServiceCollection and can be resolved from an IServiceProvider.

Such change, however, doesn't fix the non-conforming issue. For this, we need an extra factory abstraction, similar to what we have with Controllers, View Components, Tag Helpers, etc. In other words, an IComponentActivator:

``` c#
public interface IComponentActivator
{
IComponent Create(Type componentType);
}

Or alternatively:


``` c#
public interface IComponentActivator
{
    // ComponentContext could supply access to things like the HttpContext
    IComponent Create(ComponentContext context, Type componentType);
}

Instead of calling Activator.CreateInstance(componentType), ComponentFactory could simply call IComponentActivator.Create(componentType).

[dotnetjunkie]

Any progress on this? The lack of the proper abstractions is blocking users of Castle Windsor, Ninject, and Simple Injector to integrate with Razor Components.

[mkArtakMSFT]

Moving to 5.0.0-preview1 to discuss whether this is something we should consider in 5.0.

[SteveSandersonMS]

This was implemented in #19642