Skip to content
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

Merged
merged 3 commits into from
Mar 8, 2023

Conversation

dvail
Copy link
Contributor

@dvail dvail commented Mar 2, 2023

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

  • Implement correct icons and styling for summary cards
  • Integrate query with URL search parameters applied by the filter bar
  • Integrate summary card "hidden" rendering with URL search parameters

Checklist

  • Investigated and inspected CI test results
  • Unit test and regression tests added
  • Evaluated and added CHANGELOG entry if required
  • Determined and documented upgrade steps
  • Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.

Testing Performed

Error state:
image

Loading state (the blue speck is a spinner):
image

Rendering at various sizes when the request completes successfully:
image
image

@openshift-ci
Copy link

openshift-ci bot commented Mar 2, 2023

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@roxbot
Copy link
Contributor

roxbot commented Mar 2, 2023

Images are ready for the commit at 16bf636.

To use with deploy scripts, first export MAIN_IMAGE_TAG=3.74.x-313-g16bf636f53.

@dvail dvail force-pushed the dv/ROX-15384-implement-image-single-page-summary branch 2 times, most recently from 939248b to 1a45852 Compare March 3, 2023 15:46
@@ -109,7 +110,7 @@ export type ImageDetailsResponse = {
} | null;

scan: {
dataSource: { name: string };
dataSource: { name: string } | null;
Copy link
Contributor Author

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).

Comment on lines +23 to +30

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);
}
Copy link
Contributor Author

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">
Copy link
Contributor Author

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';
Copy link
Contributor Author

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?

Copy link
Contributor

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;
Copy link
Contributor Author

@dvail dvail Mar 6, 2023

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;
}
Copy link
Contributor

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

Copy link
Contributor Author

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>
Copy link
Contributor

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?

Copy link
Contributor Author

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']);
Copy link
Contributor

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?

Copy link
Contributor Author

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>
</>
Copy link
Contributor

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';
Copy link
Contributor

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.

@dvail dvail force-pushed the dv/ROX-15384-implement-image-single-page-summary branch from 81b074b to 16bf636 Compare March 8, 2023 18:28
@dvail dvail merged commit bb8d847 into master Mar 8, 2023
@dvail dvail deleted the dv/ROX-15384-implement-image-single-page-summary branch March 8, 2023 20:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants