[Blazor] Introduce IComponentPropertyActivator for property injection

[javiercn]

Summary

This PR introduces a new public abstraction IComponentPropertyActivator for customizing property injection in Blazor components, addressing the extensibility gap identified in #63451.

Background

Currently, Blazor's property injection logic (for [Inject] attributes) is embedded within the internal ComponentFactory class with no way to customize it. While IComponentActivator exists for customizing component instantiation, there's no equivalent for property injection.

This becomes problematic for scenarios like:

• Blazor Hybrid with .NET MAUI where additional context might be needed for property resolution
• Custom DI containers that need to intercept property injection
• Advanced scenarios requiring property injection customization

Changes

New Public API

namespace Microsoft.AspNetCore.Components;

/// <summary>
/// Represents an activator that can be used to activate the properties on a component.
/// </summary>
public interface IComponentPropertyActivator
{
    /// <summary>
    /// Returns an activator delegate that can be used to activate the properties on a component.
    /// </summary>
    /// <param name="componentType">The type of the component.</param>
    /// <returns>An action that takes a service provider and a component instance.</returns>
    Action<IServiceProvider, IComponent> GetActivator(
        [DynamicallyAccessedMembers(Component)] Type componentType);
}

Implementation Details

1. IComponentPropertyActivator: New public interface following the same pattern as MVC's property activators
2. DefaultComponentPropertyActivator: Internal default implementation that:
   • Caches property activators per component type using ConcurrentDictionary
   • Supports keyed services via [Inject(Key = "...")]
   • Integrates with Hot Reload for cache invalidation
   • Uses proper trimming annotations for AOT compatibility
3. ComponentFactory: Refactored to accept IComponentPropertyActivator as a dependency
4. Renderer: Updated to resolve IComponentPropertyActivator from DI with fallback to default

Tests

Added comprehensive unit tests covering:

• Custom property activator usage
• Default property activator behavior
• Keyed service injection
• Required vs optional injection
• Cache clearing for Hot Reload

API Usage

// Custom implementation
public class CustomPropertyActivator : IComponentPropertyActivator
{
    public Action<IServiceProvider, IComponent> GetActivator(Type componentType)
    {
        // Custom property injection logic
        return (serviceProvider, component) =>
        {
            // Inject properties with custom behavior
        };
    }
}

// Registration
services.AddSingleton<IComponentPropertyActivator, CustomPropertyActivator>();

Related Issues

• Fixes [Blazor] Introduce a public abstraction for property injection #63451
• Related to Allow the interception of property injection with Blazor Components #28957

[Copilot]

Pull request overview

This PR introduces a new public extensibility point IComponentPropertyActivator that allows customization of property injection in Blazor components, addressing the gap identified in issue #63451. The change follows the same design pattern as IComponentActivator and enables scenarios like custom DI containers and advanced property injection requirements in Blazor Hybrid applications.

Key Changes:

• New public interface IComponentPropertyActivator with proper XML documentation and trimming annotations
• Internal DefaultComponentPropertyActivator implementation extracted from ComponentFactory with caching and Hot Reload support
• Refactored ComponentFactory to delegate property injection to the activator, simplifying the class and improving separation of concerns

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/Components/Components/src/IComponentPropertyActivator.cs	New public interface defining the property activation contract with comprehensive documentation
src/Components/Components/src/DefaultComponentPropertyActivator.cs	Default implementation with caching, Hot Reload integration, and keyed service support
src/Components/Components/src/ComponentFactory.cs	Refactored to use IComponentPropertyActivator, removing embedded property injection logic and simplifying the class
src/Components/Components/src/RenderTree/Renderer.cs	Added DI resolution for IComponentPropertyActivator with fallback to default, integrated cache clearing for Hot Reload
src/Components/Components/src/PublicAPI.Unshipped.txt	Added new public API surface entries
src/Components/Components/test/ComponentFactoryTest.cs	Updated existing tests with new constructor parameter, added comprehensive tests for custom property activator scenarios
src/Components/Components/test/RouteViewTest.cs	Updated test to pass new required IComponentPropertyActivator parameter
src/Components/Authorization/test/AuthorizeRouteViewTest.cs	Updated test to pass new required IComponentPropertyActivator parameter

---

You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.

[ilonatommy]

Looks good to me but I would prefer more reviewers to see it.

[javiercn]

Looks good to me but I would prefer more reviewers to see it.

Fine with me. Just to set the context. This follows the same pattern as everything else on the framework (MVC/RazorPages/Controllers). The PR is mostly defining the equivalent abstraction for components and moving the code that was on the DefaultComponentFactory into the activator.