Blazor nested subcomponents idea

[miroslavsiska]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Blazor developers often create hierarchical or templated components using RenderFragment<T>, but there's no official way to define nested subcomponents (e.g. Component.InnerPart) directly within their parent component.

This leads to:

• Fragmented code spread across multiple .razor or .cs files
• Lack of semantic and visual grouping in markup
• Reduced IntelliSense and discoverability for related UI parts
• Challenges in state sharing, cascading values, and styling cohesion

While RenderFragment<T> works for templating, it doesn't support scoped, composable component hierarchies that reflect UI structure and logic as intuitively as nested tags would.

Describe the solution you'd like

Introduce support for scoped subcomponents (e.g. Component.InnerPart) that allow developers to define and use inner classes as renderable components in Razor markup.

<FormBuilder>
    <FormBuilder.InputField Label="Name" Value="@user.Name" />
    <FormBuilder.SubmitButton />
</FormBuilder>

Implementation Ideas:

• Allow nested public class components inside parent ComponentBase to be registered as tags using a naming convention (e.g. FormBuilder.InputField)
• Optionally use [Subcomponent] attribute or source generator to surface nested classes as Razor components
• Enable scoped IntelliSense and syntax validation in tooling
• Support inheritance of styling, cascading values, and event lifecycles from parent

This pattern would improve clarity, reduce namespace clutter, and enable more expressive component trees—especially for form builders, dashboard layouts, or design systems.

Additional context

No response

[javiercn]

@miroslavsiska thanks for contacting us.

We have evaluated similar ideas in the past and have decided not to pursue this approach for serveral reasons:

• Complexity and Maintenance: Supporting this feature requires significant changes to the Razor parser and Blazor’s component model. This added complexity impacts the framework’s implementation and overall maintainability.
• Tooling and Discoverability: The current approach, where each component is a top-level class in its own file, makes it easier for developers and tools (such as IntelliSense) to find, use, and refactor components. Introducing nested components makes these workflows less straightforward.
  Consistency with .NET and Razor: Blazor follows established practices in the .NET and Razor ecosystems, where top-level classes and files are the norm. Nested components break with this convention and introduce confusion.

In addition to that, the framework is responsible for creating components. A RenderFragment is not a component, but "an executable spec" of what UI needs to be generated, however the framework is still always in control of how and when components get created.

[dotnet-policy-service]

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.