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.
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.
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: