Skip to content
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

How to integrate non-conforming containers with Razor Components? #8886

Open
dotnetjunkie opened this issue Mar 28, 2019 · 4 comments

Comments

@dotnetjunkie
Copy link

commented Mar 28, 2019

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

This comment has been minimized.

Copy link
Member

commented Mar 29, 2019

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

This comment has been minimized.

Copy link
Member

commented Mar 29, 2019

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

@dotnetjunkie

This comment has been minimized.

Copy link
Author

commented Mar 29, 2019

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:

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

Or alternatively:

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

This comment has been minimized.

Copy link
Author

commented Sep 28, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.