-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add status tabs and summary card shells to images single page. #5073
Add status tabs and summary card shells to images single page. #5073
Conversation
Skipping CI for Draft Pull Request. |
Current dependencies on/for this PR: This comment was auto-generated by Graphite. |
Images are ready for the commit at 16bf636. To use with deploy scripts, first |
939248b
to
1a45852
Compare
@@ -109,7 +110,7 @@ export type ImageDetailsResponse = { | |||
} | null; | |||
|
|||
scan: { | |||
dataSource: { name: string }; | |||
dataSource: { name: string } | null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I saw that this field was incorrectly typed when I was experimenting with code generation in #5065, but I fixed it as part of this PR since it is unlikely that the former is going to get merged soon (if at all).
|
||
const cveStatusTabValues = ['Observed', 'Deferred', 'False Positive'] as const; | ||
|
||
export type CveStatusTab = typeof cveStatusTabValues[number]; | ||
|
||
export function isValidCveStatusTab(value: unknown): value is CveStatusTab { | ||
return cveStatusTabValues.some((tab) => tab === value); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved this over since we are now using the CveStatusTab
type in a handful of places, but if you think it fits better in searchUtils LMK. (EntityTab
will probably follow in the future too if we keep this here.)
isBox | ||
> | ||
<Tab eventKey="Observed" title={<TabTitleText>Observed CVEs</TabTitleText>}> | ||
<PageSection variant="light" component="div"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At one of the upcoming syncs we will have to see if the plan is for "Deferrals" and "False positives" to be almost identical to the "Observed" tab. If so, we probably don't need to render a separate component tree in each tab here and can just have the tabs control gql query params for the underlying data.
@@ -0,0 +1,36 @@ | |||
import React from 'react'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These summary card components are barely reusable, if at all. Do you think it is cleaner to keep them in separate files like this, or just inline them in the main ImageSingleVulnerabilities
component?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think keeping them separate makes sense since the ImageSingleVulnerabilities
component is already 200+ lines long.
dataSource: { name: string }; | ||
scanTime: Date | null; | ||
}; | ||
dataSource: { name: string } | null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: un-nesting these fields to avoid extra work on the backend as pointed out by Mandar.
}); | ||
|
||
return statusCounts; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we pull these under the type defs so it's easier to scan? i personally like having the types be defined first, but if this makes sense to you i'm open to that too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure that works for me. How about types for the React component props? I've been trying to keep the prop type definitions directly above the component, but below other functions and type definitions.
mainContent = ( | ||
<Bullseye> | ||
<Spinner isSVG /> | ||
</Bullseye> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just curious, what's the difference in logic here between using a spinner vs the skeleton?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went with the spinner since we are waiting on a large chunk of UI with variable shape. (Summary cards + a table with an unknown number of rows.) That and the spinner is what we use in other parts of the app for these types of table sections, and it matches with the PF example.
I try to use the Skeleton for small, precise UI elements that are loading that we will definitely know the shape of, like the header/label section at the top of this page, or the result preview items on the collection form.
const severityCounts = severityCountsFromImageVulnerabilities(vulnerabilities); | ||
const cveStatusCounts = statusCountsFromImageVulnerabilities(vulnerabilities); | ||
// TODO Integrate these with page search filters | ||
const hiddenSeverities = new Set<VulnerabilitySeverity>(['LOW_VULNERABILITY_SEVERITY']); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh why are we hiding the low severities? is there a possibility of adding new severities to hide in the widget?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, no this was just for testing and I forgot to delete it. The hidden severities/statuses are going to be calculated based on search filters once the toolbar is merged. I'll fix this here.
/> | ||
</GridItem> | ||
</Grid> | ||
</> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i dont think you need the fragments here if it's already wrapped by a single component (Grid
)
@@ -0,0 +1,36 @@ | |||
import React from 'react'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think keeping them separate makes sense since the ImageSingleVulnerabilities
component is already 200+ lines long.
81b074b
to
16bf636
Compare
Description
Implements the CVE status tab section of the image single page and bare-bones summary cards.
Follow ups needed for ROX-15384 to be complete
Checklist
If any of these don't apply, please comment below.
Testing Performed
Error state:
Loading state (the blue speck is a spinner):
Rendering at various sizes when the request completes successfully: