Restrict parent and child component hierarchy in blazor

[Stamo-Gochev]

Tag helpers can restrict (to a certain extent) which tags can be their child tag helpers and vice versa using RestrictChildren:

[HtmlTargetElement("parent-taghelper")]
[RestrictChildren("child-taghelper")]
public partial class ParentTagHelper : TagHelper { ... }

and also with ParentTag:

[HtmlTargetElement("child-taghelper", ParentTag="parent-taghelper" )]
public partial class ChildTagHelper : TagHelper { ... }

What will be the way to do that in blazor? Having the ability to restrict parent/child hierarchy will be very important for the IntelliSense as the users of components will not be able to define components in incorrect places.

Describe the solution you'd like

How tag helpers are implemented to solve this issue (using strings) can be improved What I think will be better is to pass the name of the class that can be a parent of child in a way similar to:

[Child(MyNamespace.Components.ChildComponent)]
// multiple children
[Child(MyNamespace.Components.AnotherChildComponent)]
public class ParentComponent: ComponentBase

and the other way around:

[Parent(MyNamespace.Components.ParentComponent)]
// multiple parents
[Parent(MyNamespace.Components.AnotherParentComponent)]
public class ChildComponent : ComponentBase

The exact names of the attributes can be different. I am not sure whether they should be multiple attributes for a list of parents/children or a single one (e.g. [Children(ChildComponent, AnotherChildComponent)]), but the general idea is to use concrete class names instead of strings.

You can also suggest other ways to solve this issue apart from using attributes. What are your thoughts? @SteveSandersonMS @NTaylorMullen

Additional context

I want to point out an analogy with a problem that we faced when building tag helpers that we want to avoid when building blazor components.

The problem that we faced when creating tag helpers using the parent/child restrictions was that when a tag helper with the same name was used in more than one parents, the IntelliSense doesn't display it correctly. Here is an example:

We have the pointer tag helper in both the RadialGauge and LinearGauge tag helpers. As the name "pointer" is not unique, there is a problem like that:

Note that although we are in the radial gauge tag helper, the IntelliSense picks up things from the linear gauge.

We discussed with @NTaylorMullen back in the days that the fix for that is to use unique names for the tag helpers, but this clutters the names as it requires a unique prefix before each name on each level (or at least in places of collisions). For longer nesting of hierarchies, which happens in more complex tag helpers, this is getting very long.

Restricting parent/child hierarchy with class names instead of strings should fix this problem (if this approach is chosen by blazor) as class names are unique according to a namespace.

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

[danroth27]

This is an ask from one of the major Blazor component vendors, so let's consider it for 5.0

[Stamo-Gochev]

Another option that can be discussed is to use an attribute for defining an "inner prop", e.g.:

public class ParentComponent: ComponentBase
{
    [ChildProperty]
    public ChildComponent ChildComponentInstance
    ...
}

By doing this, it is explicit that the ChildComponent should be visible from the IntelliSense when nested directly in the ParentComponent tag.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.