[FEAT] Add plugin hook to define resource status rendering across views #4632
Description
Is your feature request related to a problem? Please describe the impact that the lack of the feature requested is creating.
Currently, Headlamp does not provide a high-level plugin API to define how a resource’s status should be rendered (for example: label, color, or icon) across the UI. Status rendering logic is implemented directly inside UI components and differs between list views, detail pages, and other views.
For plugin developers—especially those working with Custom Resource Definitions (CRDs)—this creates several issues:
- Status rendering logic must be duplicated in multiple places to achieve consistent visuals.
- There is no single, authoritative way to define what a resource’s status means and how it should appear.
- The same resource type can appear with different status representations depending on the view.
This makes it difficult for plugins to provide a consistent and maintainable user experience.
Describe the solution you'd like
Introduce a plugin API hook (for example, registerResourceStatusRenderer) that allows plugins to define how the status of a given resource kind and API version should be rendered.
The hook would allow a plugin to return a status configuration (such as label, color, and optional icon), which Headlamp can then reuse consistently across list views, detail pages, and other applicable UI surfaces.
An initial implementation could focus on list and detail views, with support for additional views added incrementally.
What users will benefit from this feature?
- Plugin developers, particularly those building plugins for CRD-heavy systems such as custom controllers or schedulers.
- Users running Headlamp in-cluster or via Helm, who rely on plugins to surface domain-specific Kubernetes resources.
- Headlamp maintainers, through reduced duplication and more consistent status rendering patterns across the UI.
Are you able to implement this feature?
Yes (I will propose a PR).
Additional context
Plugins can currently customize resource table columns using registerResourceTableColumnsProcessor, but this only affects list views and does not provide a reusable way to define status semantics or visuals. A dedicated status-rendering hook would complement the existing plugin APIs and improve consistency across the application.