Another CR note: this PR changes what was previously an invariant of the system. Until now, we always knew for sure that a rendertree frame of type "Component" with ComponentType = T for some type T would always correspond to a component instance of type T.

After this PR, that invariant no longer holds, since the activator could return a component instance of any IComponent type, not necessarily T.

Loosening this invariant is beneficial for cases like testing as it means you can "mock" a child component or do shallow rendering (replace all the child components with empty things). However it's something to bear in mind in the future and not get confused about!

Pinging @dotnet/aspnet-blazor-eng for sign-off.

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

@SteveSandersonMS With this PR merged I will finally be able to do what I wanted long time ago within my component library. I cannot thank you enough time for helping me. I really appreciate all your work. Thank you!

@stsrki I am curious what you will use this feature for.

@SteveSandersonMS will this feature be added to the 3.x versions of Blazor as well, or will it only be available in the .net 5 version? Either way I guess I need to figure out how to do multi targeting correctly with bUnit.

It’s for 5.0 only.

@stsrki Thanks for your help in making this happen too!

@egil Basically in my components library Blazorise every component in the root project can be overriden and customized by any the supported frameworks(Bootstrap, Material, AntDesign, etc.) But since untll now I didn't have freedom to create the components, I had to come up with some workarounds. Like, whenever any component is created and rendered for the first time I would check if there exists custom implementation. In case it exists it would render that one instead.

The problem was that I would basically create two components instead if just one. So with this PR I would be able to finally do that.

@stsrki ahh I see. So for example, you have a public <Button/> component, which internally would have a <BootstrapButton/>, a <MaterialButton/>, etc. implementations, which you choose at runtime. I have done something similar before, just with differnet renderfragments depending on the context. I see how this will enable a more clean and simple approach.

I wonder if the public <Button /> component in the scenario above could be an interface that inherits from IComponent. Would Blazor complain about this?

@egil Yeah you got it. That's how it works.

Well in theory it could be an interface but there is a lot more features and implementations behind the scenes. Just making it an interface would not suffice.

@stsrki no I guess you have shared logic between them, so an interface might not be ideal. I was more wondering if it would be allowed by the Blazor compiler.

@egil using plain C# you can render both abstract and interface types (when handling those by implementing a capable IComponentActivator):

    private static RenderFragment RenderAbstractComponent(int arg1) => builder =>
    {
        builder.OpenComponent<IJustTestComponent>(1);
        builder.AddAttribute(2, nameof(IJustTestComponent.Arg1), arg1);
        builder.CloseComponent();
    };

It's only the razor interpreter which starts acting stupid as soon as the component class is abstract or an interface:

    <JustTestComponentBase Arg1="123" />

and lies on this with unnecessary false errors:

error RZ10012: Found markup element with unexpected name 'JustTestComponentBase'.

This is frustating and imho if the referenced type finally implements IComponent the razor compiler should just leave it to the runtime as any other argument typo or argument-left-over just crashes at runtime when it doesn't match - or missing ParameterAttribute also just waits for the user at runtime to find the error.

Hi @springy76. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.