8.2 KiB
| title | author | description | monikerRange | ms.author | ms.custom | ms.date | no-loc | uid | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ASP.NET Core Blazor templated components | guardrex | Learn how templated components can accept one or more UI templates as parameters, which can then be used as part of the component's rendering logic. | >= aspnetcore-3.1 | riande | mvc | 03/04/2021 |
|
blazor/components/templated-components |
ASP.NET Core Blazor templated components
Templated components are components that accept one or more UI templates as parameters, which can then be used as part of the component's rendering logic. Templated components allow you to author higher-level components that are more reusable than regular components. A couple of examples include:
- A table component that allows a user to specify templates for the table's header, rows, and footer.
- A list component that allows a user to specify a template for rendering items in a list.
A templated component is defined by specifying one or more component parameters of type xref:Microsoft.AspNetCore.Components.RenderFragment or xref:Microsoft.AspNetCore.Components.RenderFragment%601. A render fragment represents a segment of UI to render. xref:Microsoft.AspNetCore.Components.RenderFragment%601 takes a type parameter that can be specified when the render fragment is invoked.
Often, templated components are generically typed, as the following TableTemplate component demonstrates. The generic type <T> in this example is used to render IReadOnlyList<T> values, which in this case is a series of pet rows in a component that displays a table of pets.
Shared/TableTemplate.razor:
::: moniker range=">= aspnetcore-5.0"
::: moniker-end
::: moniker range="< aspnetcore-5.0"
::: moniker-end
When using a templated component, the template parameters can be specified using child elements that match the names of the parameters. In the following example, <TableHeader>...</TableHeader> and <RowTemplate>...<RowTemplate> supply xref:Microsoft.AspNetCore.Components.RenderFragment%601 templates for TableHeader and RowTemplate of the TableTemplate component.
Specify the Context attribute on the component element when you want to specify the content parameter name for implicit child content (without any wrapping child element). In the following example, the Context attribute appears on the TableTemplate element and applies to all xref:Microsoft.AspNetCore.Components.RenderFragment%601 template parameters.
Pages/Pets1.razor:
::: moniker range=">= aspnetcore-5.0"
::: moniker-end
::: moniker range="< aspnetcore-5.0"
::: moniker-end
Alternatively, you can change the parameter name using the Context attribute on the xref:Microsoft.AspNetCore.Components.RenderFragment%601 child element. In the following example, the Context is set on RowTemplate rather than TableTemplate:
Pages/Pets2.razor:
::: moniker range=">= aspnetcore-5.0"
::: moniker-end
::: moniker range="< aspnetcore-5.0"
::: moniker-end
Component arguments of type xref:Microsoft.AspNetCore.Components.RenderFragment%601 have an implicit parameter named context, which can be used. In the following example, Context isn't set. @context.{PROPERTY} supplies pet values to the template, where {PROPERTY} is a Pet property:
Pages/Pets3.razor:
::: moniker range=">= aspnetcore-5.0"
::: moniker-end
::: moniker range="< aspnetcore-5.0"
::: moniker-end
When using generic-typed components, the type parameter is inferred if possible. However, you can explicitly specify the type with an attribute that has a name matching the type parameter, which is TItem in the preceding example:
Pages/Pets4.razor:
::: moniker range=">= aspnetcore-5.0"
::: moniker-end
::: moniker range="< aspnetcore-5.0"
::: moniker-end
Infer generic types based on ancestor components
::: moniker range=">= aspnetcore-6.0"
An ancestor component can cascade a type parameter by name to descendants using the CascadingTypeParameter attribute. This attribute allows a generic type inference to use the specified type parameter automatically with descendants that have a type parameter with the same name.
For example, the following Chart component receives stock price data and cascades a generic type parameter named TLineData to its descendent components.
Shared/Chart.razor:
@attribute [CascadingTypeParameter(nameof(TLineData))]
@typeparam TLineData
...
@code {
[Parameter]
public IEnumerable<TLineData> Data { get; set; }
[Parameter]
public RenderFragment ChildContent { get; set; }
}
Shared/Line.razor:
@typeparam TLineData
...
@code {
[Parameter]
public string Title { get; set; }
[Parameter]
public decimal Value { get; set; }
[Parameter]
public IEnumerable<TLineData> Data { get; set; }
}
When the Chart component is used, TLineData isn't specified for each Line component of the chart.
Pages/StockPriceHistory.razor:
@page "/stock-price-history"
<Chart Data="stockPriceHistory.GroupBy(x => x.Date)">
<Line Title="Open" Value="day => day.Values.First()" />
<Line Title="High" Value="day => day.Values.Max()" />
<Line Title="Low" Value="day => day.Values.Min()" />
<Line Title="Close" Value="day => day.Values.Last()" />
</Chart>
[!NOTE] The Razor support in Visual Studio Code hasn't been updated to support this feature, so you may receive incorrect errors even though the project correctly builds. This will be addressed in an upcoming tooling release.
By adding @attribute [CascadingTypeParameter(...)] to a component, the specified generic type argument is automatically used by descendants that:
- Are nested as child content for the component in the same
.razordocument. - Also declare a
@typeparamwith the exact same name. - Don't have another value supplied or inferred for the type parameter. If another value is supplied or inferred, it takes precedence over the cascaded generic type.
When receiving a cascaded type parameter, components obtain the parameter value from the closest ancestor that has a CascadingTypeParameter with a matching name. Cascaded generic type parameters are overridden within a particular subtree.
Matching is only performed by name. Therefore, we recommend avoiding a cascaded generic type parameter with a generic name, for example T or TItem. If a developer opts into cascading a type parameter, they're implicitly promising that its name is unique enough not to clash with other cascaded type parameters from unrelated components.
::: moniker-end
::: moniker range="< aspnetcore-6.0"
[!NOTE] Inferred generic types are supported in ASP.NET Core 6.0 or later. For more information, see a version of this article later than ASP.NET Core 5.0.
::: moniker-end