Infer component generic types from ancestor components

[SteveSandersonMS]

Summary

Currently, component generic type inference is based exclusively on parameters passed to that component, ignoring any other context such as ancestor components. This imposes problematic limitations in more sophisticated scenarios, particularly for component vendors trying to create a really smooth consumption experience.

See customer report in #7268, but note this has also been requested independently by component vendors.

Motivation and goals

The classic example is a generic <Grid> component containing generic <Column> children. As of today you have to do something like this:

<Grid Items="@people">
    <Column TItem="Person" Name="Full name">@context.FirstName @context.LastName</Column>
    <Column TItem="Person" Name="E-mail address">@context.Email</Column>
</Grid>

...when what you actually want to do is this:

<Grid Items="@people">
    <Column Name="Full name">@context.FirstName @context.LastName</Column>
    <Column Name="E-mail address">@context.Email</Column>
</Grid>

Notice how the consumer has to re-specify TItem on each column, because it can't be inferred from the enclosing <Grid> (even though <Grid> itself can infer based on its own Items parameter).

In scope

• Inferring a generic type from an ancestor in the same .razor file
  • ... when a same-named generic type is specified explicitly on the ancestor (e.g., <Grid TItem=Person>)
  • ... when a same-named generic type is inferred on the ancestor (e.g., <Grid Items=@someEnumerableOfPerson>)
• Sensible overriding rules
  • We still prefer to use explicitly-provided generic type parameters (e.g., <Column TItem=Person>) - that overrules all inference
  • Failing that, we still prefer to infer based on a regular [Parameter] - that overrules inference based on ancestors
  • Only failing both of those do we go looking for same-named ancestor generic type parameters
• Continuing to provide a good compile error if one or more generic types can't be inferred

Open questions:

• Instead of only matching based on generic type names, should we have a way to specify in a strongly-typed way which other component(s) are valid suppliers of values for each generic type? This probably requires new syntax, e.g., a directive like @typeparam TItem from Grid. I'm not keen on inventing new syntax like that.
• Or should we wait until implementing some kind of "Restrict component hierarchy" feature, and then say we're only going to infer based on the specific ancestors that are declared as required? I'm not convinced this is a good idea, because "Restrict component hierarchy" will probably only support immediate-child/parent relationships, otherwise it runs into trouble when people want to split things over multiple .razor files, and in that case it's not really flexible enough to handle the requirements for generic type inference. For generic type inference, we want to support arbitrary depth ancestors within the same .razor file.

Out of scope

• Partial generic type inference. Due to C# compiler limitations, if you specify any generic type values explicitly, you must specify all of them explicitly. This is an existing limitation in the Razor compiler too, and the work here isn't going to change that.
• Matching against an ancestor in a different .razor file. We can't know which other .razor files are going to contain a reference to your component, hence we don't know what the ancestors will be. Even if we did, there might be multiple ones that would "supply" different generic types. Altogether it's meaningless to imagine we're matching against "ancestors" in entirely separate files.
  • Note that people can still do generic type inference across files, but only the existing form of generic type inference that requires your component to receive a parameter involving that generic type.
• Anything cleverer than matching based on generic type parameter name. For example, even if the closest candidate match is incompatible due to generic type constraints, we're not going to know about that and pick a different candidate. Likewise, if the candidate you want to match has a different name, we can't know that's your intention (even if there's only one such candidate).

Risks / unknowns

It's taking a fairly magic thing and making it more magic still. It will become fairly hard to explain the exact rules around type inference.

It makes the declared generic type parameter name more important. It's no longer just named for explanatory purposes, but also for uniqueness purposes. Some existing components might have generic type parameter names that aren't unique enough (e.g., just T) and so the inference-based-on-ancestors mechanism might match a different ancestor than you intended. This isn't massively bad because you'd know about it at compile time, plus in most cases, developers can change their generic type names to make them more unique when required. We should check that our own generic components have good type generic type names.

If we implement an "Extract Component"-type refactoring in the future, it will have to account for this. That is, it will have to work out which generic types were being inferred from an ancestor, and convert those into @typeparam declarations on the extracted component.

Examples

See the <Grid> example above as the primary scenario.

Other scenarios are anything where you have multiple child components that all take a RenderFragment<T> ChildContent parameter, each of which does something with the same data source. Example: a <Chart> component containing multiple <Series>.

Even if literally the only scenario was "grids", I think that would still be important enough to warrant this work.

Also bear in mind cases where the inference needs to flow through multiple levels in the component hierarchy. You don't always infer based on the immediate parent. For example,

<Grid Items="@people">
    <CascadingValue Value="@someUnrelatedThing">
        <Column Name="Full name">@context.FirstName @context.LastName</Column>
        <Column Name="E-mail address">@context.Email</Column>
    </CascadingValue>
    <Column Name="Actions"><button ... /></Column>
</Grid>

[ebekker]

Based on the out-of-scope "partial inference" comment, would it still be possible to support implicit inference from both immediate parameter and ancestor types? In other words as long as there are no explicit type parameters provided, all other inference types would be allowed?

[ebekker]

Just thinking out loud... instead of inferring the generic type from ancestor components, would it be possible to infer it from Cascading Parameters? This would avoid the unique name dependency, and potentially could even allow inference across files. It would also provide a form of a more strongly-typed generic inference.

[SteveSandersonMS]

I know we've already established that this feature is desirable, so I'm moving on to some candidate implementation suggestions.

Implementation proposals

Before we start, first understand how the existing generic type inference works. As of 5.0, Razor's generic type inference works by converting "the code that emits component frames" into "a method call that emits those component frames". As a simplified example, without generic inference we might have this, where Items is a parameter of type IEnumerable<TItem>:

// <Column TItem=Person ColumnName="@someColumnName" Items=@people />
void BuildRenderTree(RenderTreeBuilder builder)
{
    builder.OpenComponent<Column<Person>>(0);
    builder.AddAttribute(1, "ColumnName", someColumnName);
    builder.AddAttribute(2, "Items", people);
    builder.CloseComponent();
}

Whereas with generic type inference we have this:

// <Column ColumnName="@someColumnName" Items=@people />
void BuildRenderTree(RenderTreeBuilder builder)
{
    EmitColumnComponent(builder, arg0: someColumnName, arg1: people);
}

// This is generated by the Razor compiler
static void EmitColumnComponent<TItem>(RenderTreeBuilder builder, string arg0, IEnumerable<TItem> arg1)
{
    builder.OpenComponent<Column<TItem>>(0);
    builder.AddAttribute(1, "ColumnName", arg0);
    builder.AddAttribute(2, "Items", arg1);
    builder.CloseComponent();
}

The C# compiler does the fancy work of inferring the TItem type at the call site inside BuildRenderTree based on the arg1 expression type.

Notice how EmitColumnComponent has to have parameters for all the parameters of Column<TItem>, even those not involved in generic type inference. We can't just inline the expressions for their values into the code inside EmitColumnComponent, because those expressions might reference other variables that only exist in scope at the original call site inside BuildRenderTree. For example, someColumnName might be a local variable that only exists at this point during rendering (e.g., a loop variable), so we can't reference it directly from EmitColumnComponent.

It's actually slightly more complicated still, but that's the core idea (by @rynowak originally, mentioning him in case he wants to come and share any further wisdom!) and is all we need to know to understand the following.

1. Have the C# compiler get the generic type name from lexical scope

Spoiler: this is not my preferred option - see later

What if, instead of EmitColumnComponent taking parameters for all the parameters of Column<TItem>, it only took ones for those involved in generic type inference? The other parameter values could be inlined into the generated code. For example, if you're passing a ChildContent fragment (which is compiled as a lambda), then the source for that lambda would go inside EmitColumnComponent rather than at the call site.

Then to make this safe so you can still reference variables that are only in scope at the call site, we could change the whole thing to be a local function:

// <Column ColumnName="@someColumnName" Items=@people />
void BuildRenderTree(RenderTreeBuilder builder)
{
    EmitColumnComponent(builder, arg1: people);

    // This is generated by the Razor compiler
    static void EmitColumnComponent<TItem>(RenderTreeBuilder builder, IEnumerable<TItem> arg1)
    {
        builder.OpenComponent<Column<TItem>>(0);
        builder.AddAttribute(1, "ColumnName", someColumnName);
        builder.AddAttribute(2, "Items", arg1);
        builder.CloseComponent();
    }
}

Now, if we have multiple nested levels of type inference, they will get compiled as multiple nested levels of local functions, hence they are within each other's scopes, e.g.:

void BuildRenderTree(...)
{
   ...

   EmitGridComponent<TItem>(...)
   {
       ...

       EmitColumnComponent(...)
       {
           ...
       }
   }
}

So at this point, all the Razor compiler has to do is not put any generic type declarations on the nested Emit... methods if their names exactly match one of the generic type declarations on an ancestor, and by lexical scope, the ancestor's value will get used.

2. Extend the type inference method to take extra synthetic parameters used for inference only

As an alternative, instead of changing where the type inference methods go, we could just add some more parameters to them. As of 5.0, they take one parameter for each [Parameter] on the component you're rendering. But what if we extend this to include not only the [Parameter]s from the component you're rendering, but also include selected [Parameter]s from ancestor components in the same .razor markup?

For example, given this markup (where both Grid and Column declare @typeparam TItem):

<Grid Items="@people">
    <Column IsCoolColumn="true" />
</Grid>

... we generated the following:

void BuildRenderTree(RenderTreeBuilder builder)
{
    EmitGridComponent(builder, arg0: people, arg1: (RenderFragment)(builder =>
    {
        EmitColumnComponent(builder, syntheticArg0: people, arg0: true);
    });
}

static void EmitGridComponent<TItem>(RenderTreeBuilder builder, IEnumerable<TItem> arg0, RenderFragment arg1)
{
    builder.OpenComponent<Grid<TItem>>(0);
    builder.AddAttribute(1, "Items", arg0);
    builder.AddAttribute(2, "ChildContent", arg1);
    builder.CloseComponent();
}

static void EmitColumnComponent<TItem>(RenderTreeBuilder builder, IEnumerable<TItem> syntheticArg0, bool arg0)
{
    builder.OpenComponent<Column<TItem>>(0);
    builder.AddAttribute(1, "IsCoolColumn", arg0);
    builder.CloseComponent();
}

That is, when rendering Column, we notice that its TItem isn't "covered" by either an explicit declaration (TItem=...), nor by a [Parameter] on the component itself. So we fall back on scanning up the ancestor hierarchy to look for the closest thing that has a generic parameter called TItem and was supplied with any [Parameter] value that could "cover" it (or an explicit declaration).

We discover Grid is the closest candidate, and that its type inference made use of a parameter called Items of type IEnumerable<TItem>. So for EmitColumnComponent, we add a synthetic extra argument whose type is IEnumerable<TItem>, and we pass the people value which is known to be in scope because descendant rendering is always within a lambda within the call site for the ancestor.

Even though EmitColumnComponent's logic doesn't use syntheticArg0 in any way, simply passing it makes generic type inference work.

3. Use some extension of <CascadingValue>

We've had a couple of community suggestions (here, here) that <CascadingValue> should be extended to supply generic types as well as actual parameter values.

I don't personally think this works in any way, because generic type inference has to be resolved at compile time in order for generic types to do all the things people want (e.g., produce correct intellisense when operating on instances of those generic types, and give compile-time errors if you reference non-existent members on them).

CascadingValue is a runtime feature, since the actual set of component ancestors can't be known in general until runtime (you could decide it dynamically based on user actions, for example). So it's not meaningful to have it impact compiler output.

About inheriting types across independent files

More generally, I don't think the problem of inheriting types across .razor files can have any solution. Consider sources like this:

@* Index.razor *@

<Grid Items=@people>
    <MyColumns />
</Grid>

@*MyColumns.razor*@

<Column Name="First name">@context.FirstName</Column>
<Column Name="E-mail address">@context.Email</Column>

That can't possibly work at compile time because MyColumns.razor has no way to know it's only ever going to be used from within a specific place inside Index.razor. Even if at runtime that happens to be true, the compiler can't know it. So it can't possibly specify any particular TItems value for the <Column> component.

What you'd actually need to do is add a type parameter onto MyColumns.razor, e.g.,

@*MyColumns.razor*@

@typeparam TItem
<Column TItem=TItem Name="First name">@context.FirstName</Column>
<Column TItem=TItem Name="E-mail address">@context.Email</Column>

Now this can work with design 2 above, because Index.razor infers the type to pass to <MyColumns> based on the match local to that file, and MyColumns.razor explicitly passes that on to <Column> (or maybe we even make the inference match @typeparam on the component itself and pass default(TItem) to the inference function, so you can omit the TItem=TItem parts).

So in summary, I don't think that <CascadingValue> is relevant for solving this problem, and isn't needed because design 2 already produces the best possible result anyway.

Matching rules

The designs above assumed that, when we're looking for a value for TItem on a child component, we'd match that by name against any same-file ancestor that also has a type parameter called TItem. That is, matching on the name as a string. Clearly this has the drawback of not being fully strongly typed.

It would be nice if there was some way to define the exact set of types you were willing to match against. For example:

@typeparam TItem from Grid<>

or, without needing new syntax:

@typeparam TItem
@attribute [InferTypeParameter(nameof(TItem), FromComponent: typeof(Grid<>))]

Notice that we can't refer to Grid<TItem> in the attribute, because attributes can't reference type parameters from their own host class (because the attribute is on the open generic type, not any particular closed one), so we're limited to saying Grid<>, so it doesn't lead to any obvious way to say "I can only be inside a Grid<TItem> with the same type arg". Also notice that if Grid had multiple type parameters, we still have no way to say which of them we mean other than stating a name string, so there's still a level of string-based name matching.

However there's a bigger problem still with this, which is that the Razor compiler doesn't know about type compatibility. If somebody subclasses Grid<TItem> to make SuperGrid<TItem>, the Razor compiler doesn't naturally know about this relationship. Likewise with inferface implementations. Unless we actually walk the chain of all base types and interface implementations and recreate all the "is assignable from" rules inside the Razor compiler. In short, we're not going to get anywhere near doing that.

I tried to think of some way to express the type inference method such that it would end up picking a type arg based on type assignment compatibility, but it's absolutely mind-bending and I think at the very least would involve passing a separate parameter for every ancestor (and to do that, involves an extra layer of lambda-capturing for each level of ancestry). It seems like a truly bad direction to go, but by all means correct me if you see a clean way to do it!

A simple compromise

Since we can't truly have strongly-typed type parameter matching, are we at risk of accidental matches and general confusion when unrelated components both have @typeparam T?

A solution that @javiercn and I came up with is simply to make the inference matching opt-in. That is, type parameters don't flow by default. The developer explicitly enables the flow on particular type parameters, and when they do so, we interpret that as meaning "I promise the name is unique enough for my purposes".

We could either do it on the receiving side:

@* Column.razor *@
@typeparam TItem
@attribute [ReceiveTypeParamFromAncestors(nameof(TItem))]

... or on the sending side:

@* Grid.razor *@
@typeparam TItem
@attribute [CascadeTypeParam(nameof(TItem))]

Perhaps this is where @ivanchev and @ebekker's intuition about an explicit "cascade" gesture does line up with what we can do.

Preferred option

I prefer option 2 above because:

• Unlike option 1, it minimizes the amount we have to change the existing type inference logic. For user code that doesn't need to infer generic types from ancestors, the Razor compiler output would be exactly unchanged, so there's no risk of unanticipated breaking changes.
• Unlike option 1, it doesn't involve inlining parameter values into the type inference function, which could have implications for perf since we'd be closing over more locals and hoisting them. It might even affect behavior when executed within loops.
• Unlike option 1, it means the decisions about matching generic parameters would be implemented in procedural code inside the Razor compiler, so we can use whatever explicit matching rules we want. Whereas with option 1, the matching would happen implicitly inside the C# compiler based on lexical scope, so it would be way harder to put in any special cases. Also it might be much easier to produce good error messages from the Razor compiler if we control the logic more directly.

All this said, it's still a pretty complicated thing to implement, so if there are suggestions of better approaches from @NTaylorMullen, @rynowak, etc., I'd be very interested!

[ebekker]

Just to harp on the cascading param idea a bit more... perhaps I'm missing a subtle point, but while I agree that populating a cascading parameter happens at runtime, isn't the type specification fully declared and known at compile time? You have to define a property on a component class and annotate it to declare a cascading parameter, so it's type should be fully resolvable at compile time. For example:

public class MyComponent<TItem> : ComponentBase
{
    [CascadingParameter]
    public SomeType<TItem> SomeValue { get; set; }
}

It wouldn't matter if SomeValue was ever populated or not, the type is still known at compile time.

Though, I'm sure I'm missing some subtle point here...

[SteveSandersonMS]

@ebekker Sorry but I don't see how that fits in with how generic type inference works. You would need to provide a code sample showing exactly what the compiler would generate, for example in the case I was using above (<Grid Items=@people><Column /></Grid>). Additionally we don't want to give developers an extra job of converting their parameters into cascading parameters when regular parameters would suffice, as in the designs 1 and 2 above.

[Liander]

If you pass the synthetic arguments before the rest of the values to the emit-function I guess that something like <Column ValueSelector = @(x => x.Age) /> can resolve to the type Column<Person, int>, where Person is resolved from the ancestor parameter and int is resolved by the lambda declaration. To get intellisens on lambda. Is that correct and is that the plan? If yes, then I really like it.

[SteveSandersonMS]

@Liander As far as I can tell, yes it would be able to infer the type in this case. However I don't see any reason why it matters what order we put the arguments on the emit function. I think it would work exactly the same if the synthetic arguments go last.

[Liander]

It matters for the intellisens, at least if it works like ordinary factory methods.

[SteveSandersonMS]

It doesn't seem to make a difference when I tried it. If you could post a Gist showing a minimal example of a case where this matters I'd be interested.