From what I see, it would be changing this line: https://github.com/aspnet/Blazor/blob/5be754e75def0c4134e379a6440c6b284828f01e/src/Microsoft.AspNetCore.Blazor/Components/ComponentFactory.cs#L35
Another change would be to allow for interfaces that derives from IComponent in the language service.
The usecases are the following:
Allow for code only components to use constructor injection. The property injection support was native in Asp.Net core while it was in its early stages and was later removed to make the DI simpler and more focussed. This seems to be a step backwards.
Allow this pattern:
//In assembly A
public interface IMyComponent : IComponent { int SomeParameter{get;set;} }
//In assembly B
public class MyComponent: BlazorComponent, IMyComponent { }
//In the blazor app:
//Setting up dependency injection
class Program
{
static void Main(string[] args)
{
var serviceProvider = new BrowserServiceProvider(configure =>
{
//Potentially load implementation dynamically here
configure.Add(ServiceDescriptor.Transient(typeof(IMyComponent), typeof(MyComponent)));
});
new BrowserRenderer(serviceProvider).AddComponent<App>("app");
}
}
//in cshtml page
<IMyComponent SomeParameter="22" />
How would this be useful: it would become possible to expose components as a contract between multiple assemblies, potentially multiple repositories. This could become the base for a micro-ui architecture where each service could expose their UI components as a contract thus removing the need for a fully pre-built application and allowing dynamically loading components for A/B testing or for testing new features behind feature flags.
I guess the designer change would need to be here:
Would need to check those conditions or "is interface".
I'd be glad to make the changes and make a pull request if it would be an acceptable change. Building the vsix with that change to test it should be pretty easy. What do you think?
This works: https://github.com/scabana/Blazor/commit/4b7f303fe7b423a5a47140a7ac9b636a4d749856
The only thing I'm not 100% sure about is about removing the !isAbstract, I don't know if it opens up the gates too much.
Downside: each component activation now goes through the DI. I could add a cache to persist which one worked and use the right way on second pass.
I would like to open a pull request with my commit, I don't want to force it before getting buy-in, anyone reviewing issues? Thanks!
We could go a step further where @injects directives would be only injected by constructor. This would help unit testing the components by making all dependencies very clear. I started looking into this, but I fear it would differ too much from the Asp.Net core's server side Razor.
@injectsThanks for contacting us, @scabana.
@rynowak, can you please look at this? Thanks.
We have no plans to do this for this release.
Most helpful comment
I would like to open a pull request with my commit, I don't want to force it before getting buy-in, anyone reviewing issues? Thanks!