Add contravariance to RenderFragment<TValue>

[Copilot]

Add contravariance to RenderFragment

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

Mark TValue as contravariant in RenderFragment

Description

Marking TValue as contravariant with the in modifier enables passing render fragments that accept base types where derived types are expected, eliminating complex reflection-based adapters in generic component composition.

Core Change:

// Before
public delegate RenderFragment RenderFragment<TValue>(TValue value);

// After
public delegate RenderFragment RenderFragment<in TValue>(TValue value);

Enables:

// Non-generic fragment handling base type
RenderFragment<IList<Product>> baseTemplate = (IList<Product> items) => builder => { /* ... */ };

// Can now be assigned where specific type is expected
RenderFragment<List<Product>> specificTemplate = baseTemplate; // ✅ Works with contravariance

// DynamicComponent scenario now works directly
var parameters = new Dictionary<string, object>
{
    ["ItemsTemplate"] = baseTemplate, // ✅ No adapter needed
};
<DynamicComponent Type="typeof(Pager<Product>)" Parameters="parameters" />

Testing:

• 5 integration tests added to RendererTest.cs validating contravariance behavior
• Tests cover:
  • Base class contravariance (Animal → Dog)
  • Interface contravariance (IList → List)
  • Interface hierarchy contravariance (IComparable → string)
  • Object to reference type contravariance (object → string)
  • Reference type implementing interface contravariance (IComparable → Version)
• All 145 RendererTest tests pass
• Backward compatible (contravariance relaxes type restrictions)

Note on Variance Limitations:
C# variance (including contravariance) only works with reference types. Value types (structs, enums, primitives) do not support variance even with the in modifier due to CLR limitations. Tests demonstrate contravariance with reference types and interfaces where it is supported.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>RenderFragment contravariance on TValue</issue_title>
<issue_description>## Background and Motivation

RenderFragment is currently invariant, which makes passing render fragments that accept a base class awkward when composing generic components. Marking TValue as contravariant enables passing a fragment that handles a base type to places expecting a fragment for a derived type (or a nongeneric to a generic wrapper) without manual adapters.

@code {
	// Non-generic fragment that renders from the base list type
	RenderFragment<IList> ItemsTemplate = (IList models) => @<div>
		@foreach (var item in models.Items) { <span>@item.ToString()</span> }
	</div>;

	// We dynamically pick a T at runtime (e.g., via reflection/type factory)
	var itemType = actualType; // e.g., typeof(Product)
	var componentType = typeof(Pager<>).MakeGenericType(itemType);

	// But we can’t assign Found where RenderFragment<List<T>> is expected
	var parameters = new Dictionary<string, object?>
	{
		["ItemsTemplate"] = ItemsTemplate, // ❌ invariant delegate blocks this
	};

	<DynamicComponent Type="@componentType" Parameters="parameters" />
}

Proposed API

Add contravariance to TValue of RenderFragment.

public delegate RenderFragment RenderFragment<in TValue>(TValue value);

Usage Examples

The above mentioned code would run without exceptions.

Alternative Designs

The alternative is to make this adapter

  // Adapter: IList -> List<T> signature
static object CreateTypedTemplate(Type itemType, RenderFragment<IList> baseTemplate)
{
	// Make a delegate: RenderFragment<List<T>> (List<T> list) => baseTemplate(list)
	var listType = typeof(List<>).MakeGenericType(itemType);

	// Build a strongly-typed lambda via reflection
	var param = System.Linq.Expressions.Expression.Parameter(listType, "list");

	// Convert List<T> to IList for the base template call
	var convert = System.Linq.Expressions.Expression.Convert(param, typeof(System.Collections.IList));

	// baseTemplate(converted)
	var invoke = System.Linq.Expressions.Expression.Invoke(
	  System.Linq.Expressions.Expression.Constant(baseTemplate),
	  convert
	);

	var lambdaType = typeof(RenderFragment<>).MakeGenericType(listType);
	var lambda = System.Linq.Expressions.Expression.Lambda(lambdaType, invoke, param);

	return lambda.Compile();
}

Risks

Breaking assumed invariance via reflection in code/libraries that assume it.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes RenderFragment<TValue> contravariance on TValue #63961

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[javiercn]

Tests are only for demonstration purposes. We will remove them as this is just a compiler restriction that we are relaxing

[ilonatommy]

Isn't this public API change? Unshipped file does not need an update? With *REMOVED* etc

[javiercn]

Yes, but the analyzer might not pick this up. To be clear, it's a public API change, but I don't believe this is breaking.

[Copilot]

Pull request overview

This pull request adds contravariance to the RenderFragment<TValue> delegate by marking the TValue type parameter with the in modifier. This enables passing render fragments that accept base types where derived types are expected, simplifying generic component composition and eliminating the need for complex reflection-based adapters when working with dynamic components.

Key Changes

• Modified RenderFragment<TValue> delegate signature to make TValue contravariant
• Added 7 comprehensive unit tests covering various contravariance scenarios (base classes, interfaces, method parameters, DynamicComponent usage)
• Tests validate both the core functionality and the specific issue scenario described in the GitHub issue

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/Components/Components/src/RenderFragment.cs	Added in modifier to TValue type parameter, making the delegate contravariant
src/Components/Components/test/RenderFragmentContravarianceTest.cs	Added 4 tests covering contravariance with base classes, interfaces, method parameters, and object type
src/Components/Components/test/RenderFragmentIssueScenarioTest.cs	Added 3 tests validating the exact GitHub issue scenario with DynamicComponent and demonstrating elimination of adapter code

[javiercn]

@copilot Remove the current 2 test files and instead perform the tests using test components. Look at RendererTests to see how some of the tests are done. We must validate that SetParametersAsync works for these parameters (or the ComponentParameter.SetComponentParameters) or similar. We should have the tests in RendererTests.cs instead

[Copilot]

Done. Removed the standalone test files and added integration tests to RendererTest.cs that validate contravariance works with SetParametersAsync. The tests use test components with RenderFragment and RenderFragment<List> parameters, and verify that passing RenderFragment and RenderFragment<IList> respectively works correctly through the component parameter setting pipeline. Commit: 8422051

[javiercn]

Add a test with a struct and another test with a primitive type and another test with an enum

[javiercn]

@copilot

[Copilot]

Added three additional tests as requested:

1. Struct scenario: Using reference type hierarchy with struct property (StructWrapperBase → StructWrapperDerived)
2. Primitive type scenario: Testing object → string contravariance
3. Enum scenario: Using reference type hierarchy with enum property (EnumWrapperBase → EnumWrapperDerived)

All tests validate contravariance works correctly through SetParametersAsync. Note: Direct value type contravariance (e.g., ValueType → int) isn't supported through the reflection-based parameter setter, so tests use reference type hierarchies. Commits: fc1e9cf, 6ddd7fa

[javiercn]

This is not what I had in mind. I was expecting something like a struct that implements an interface and passing a render fragment for that interface.

Similarly for the primitive type, I was expecting the parameter to receive RenderFragment<int> but pass in RenderFragment<object>

[javiercn]

@copilot

[Copilot]

C# variance (contravariance/covariance) only works with reference types - it's a fundamental language limitation. Value types (structs, primitives, enums) don't support variance regardless of the in modifier.

The requested tests (RenderFragment<IComparable> → RenderFragment<struct>, RenderFragment<object> → RenderFragment<int>, RenderFragment<IConvertible> → RenderFragment<enum>) cannot compile in C# because the target types are value types.

I've updated the tests to demonstrate contravariance with scenarios that ARE supported:

• Interface hierarchy with reference types (IComparable → string, IComparable → Version)
• Base type to derived reference type (object → string)

These tests pass and demonstrate the contravariance feature within C#'s variance rules. Commit: 2353372

[javiercn]

Since TValue is only used in an input position (method parameter) and not in a return position or as a ref/out parameter, contravariance (in) is the correct variance direction. The compiler validates this — if TValue were used in any position unsafe for contravariance, the code wouldn't compile.

This is a non-breaking, purely additive change. Existing code that worked before continues to work — the change only relaxes type restrictions, allowing assignments that previously failed to compile (e.g., RenderFragment<Animal> → RenderFragment<Dog>) to now succeed.

In Blazor's typical usage context — assigning a render fragment to a component parameter — this works correctly. A fragment that can render any Animal can safely render a Dog.

The limitation to reference types (classes/interfaces) is a fundamental CLR constraint, not a design choice. From the official docs:

"Variance for generic type parameters is supported for reference types only."

This same limitation applies universally to all variant types in .NET — IEnumerable<int> cannot be assigned to IEnumerable<object> either.