frontend: CustomResourceDetails: Use DetailsGrid to allow plugins extend CR instance pages#5046
frontend: CustomResourceDetails: Use DetailsGrid to allow plugins extend CR instance pages#5046sniok wants to merge 1 commit intokubernetes-sigs:mainfrom
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sniok The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Pull request overview
This PR updates the Custom Resource instance details view to use the shared DetailsGrid layout so that plugin-registered details sections (via the detailsViewSections mechanism) are rendered on CR instance pages.
Changes:
- Replaced the CR instance details page layout (
PageGrid/MainInfoSection/manual events) withDetailsGrid. - Wired CR instance metadata “extra info” and extra sections (conditions + legacy
DetailsViewSection) throughDetailsGridprops. - Updated storyshot snapshots to reflect the new rendered DOM structure.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| frontend/src/components/crd/CustomResourceDetails.tsx | Switches CR instance details rendering to DetailsGrid and moves extra info/sections/events into DetailsGrid props. |
| frontend/src/components/crd/snapshots/CustomResourceDetails.NoError.stories.storyshot | Snapshot updates for the new DetailsGrid DOM structure in the success case. |
| frontend/src/components/crd/snapshots/CustomResourceDetails.ErrorGettingCR.stories.storyshot | Snapshot updates for the new DetailsGrid DOM structure in the error case. |
| <DetailsGrid | ||
| resourceType={CRClass} | ||
| name={crName} | ||
| namespace={namespace} | ||
| cluster={cluster} | ||
| backLink="" | ||
| extraInfo={item => |
There was a problem hiding this comment.
Switching to DetailsGrid changes the loading/error UI for the CR instance: on fetch errors it now renders error.toString() (e.g. "TypeError: Failed to fetch") without including the CR kind/name (and the header title is blank while item is null). This is a regression from the previous contextual message ("Error getting custom resource {{crName}}: …"). Consider passing an explicit title to DetailsGrid (e.g. from the CRD’s kind + crName) so the page remains identifiable during loading/error, and/or adding a contextualized error presentation if you want to preserve the prior UX.
| @@ -172,17 +160,33 @@ function CustomResourceDetailsRenderer(props: CustomResourceDetailsRendererProps | |||
| </Link> | |||
| ), | |||
| }, | |||
| ...getExtraInfo(extraColumns, item!.jsonData as KubeCRD), | |||
| ]} | |||
| backLink="" | |||
| /> | |||
| {item!.jsonData.status?.conditions && ( | |||
| <SectionBox> | |||
| <ConditionsTable resource={item.jsonData} showLastUpdate={false} /> | |||
| </SectionBox> | |||
| )} | |||
| <DetailsViewSection resource={item} /> | |||
| {item && <ObjectEventList object={item} />} | |||
| </PageGrid> | |||
| ...getExtraInfo( | |||
| getExtraColumns(crd, item.jsonData.apiVersion?.split('/')[1] || '') || [], | |||
| item.jsonData as KubeCRD | |||
| ), | |||
| ] | |||
| } | |||
| extraSections={item => | |||
| item && [ | |||
| ...(item.jsonData.status?.conditions | |||
| ? [ | |||
| { | |||
| id: 'headlamp.cr-conditions', | |||
| section: ( | |||
| <SectionBox> | |||
| <ConditionsTable resource={item.jsonData} showLastUpdate={false} /> | |||
| </SectionBox> | |||
| ), | |||
| }, | |||
| ] | |||
| : []), | |||
| { | |||
| id: 'headlamp.cr-details-view', | |||
| section: <DetailsViewSection resource={item} />, | |||
| }, | |||
| ] | |||
| } | |||
| withEvents | |||
| /> | |||
There was a problem hiding this comment.
This change is specifically intended to make plugin-registered details sections appear on CR instance pages, but the existing storyshots only cover the baseline/no-error and error states and don’t assert that a registerDetailsViewSection-style section is actually rendered. Adding a story/storyshot that seeds the Redux store with a detailsViewSections entry (or uses the plugin registration helper) would prevent regressions in the plugin extension behavior this PR targets.
…end CR instance pages
Custom Resource Instance details pages were not displaying custom details page sections registered by the plugins
This PR adjusts CustomResourceDetails component to use DetailsGrid that handles that already
How to test
pluginLib.registerDetailsViewSection(() => "custom section")in console)Screenshots (if applicable)
CR instance page, after running
pluginLib.registerDetailsViewSection(() => "custom section")in console