Skip to content

Component Visibility in Blazor #34750

@SolarOsQuiere

Description

@SolarOsQuiere

Proposal: Enhancing Component Visibility in Blazor

Description

I am developing a Blazor component library that is consumed by various teams within our organization. During this process, we have identified the need to create internal components that should not be exposed outside of the library.

However, we have encountered a limitation where Razor components in Blazor are required to have public visibility by default. This restriction prevents us from properly encapsulating components that we don't want to make accessible outside the library, which reduces our control over the exposure of our code.

Problem

  • Razor components in Blazor are public by default due to inheriting from ComponentBase.
  • There is no option to define internal or restricted components that are only intended to be used within the assembly or library.
  • This limitation exposes unnecessary components that are not intended to be accessed externally, impacting the modularity and encapsulation of the library.

Proposal

  • Introduce the ability for Razor components to have more restrictive visibility levels, such as internal or protected.
  • This would allow developers to encapsulate components that should remain internal to the library or assembly, improving modularity and code maintainability.

Benefits

  • Improved encapsulation: Developers can restrict component visibility based on their intended scope, preventing unnecessary exposure.
  • Enhanced modularity: Libraries and projects can better structure their code and enforce boundaries between internal and public APIs.
  • Increased maintainability: Limiting access to internal components reduces the surface area for potential issues and improves the organization of the codebase.

Impact

This change would provide more flexibility in how components are designed and structured in Blazor projects. It would help create cleaner, more modular libraries without affecting existing applications, as public components would still be fully supported.


Thank you for considering this proposal. I believe it would significantly enhance the development experience for Blazor component libraries.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions