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 a component for filtering repositories based on their results #2343

Merged
merged 13 commits into from
Apr 19, 2023

Conversation

robertbrignull
Copy link
Contributor

This PR adds a new dropdown in the variant analysis results view, to control filtering of repositories. This allows filtering to only those repositories that have results, and is treated separate from the existing search bar which allows filtering based on the repository name.

Screenshot 2023-04-17 at 16 34 14

I've tried where at all possible to use the term "search" when referring to the existing feature of filtering based on the repository name, and used the term "filter" to refer to the new feature of filtering based on results.

The default value is "All" and therefore the default behaviour is identical to the existing behaviour. In later PRs we'll look at changing the default behaviour to "With results" and making it configurable.

I haven't added any kind of feature flag for this because I think we can implement it in shippable chunks, where each individual PR isn't too large and could be shipped on its own. If you think this PR is too large or you'd prefer to have a feature flag regardless, just let me know and we can look at that. This PR contains all the parts, including adding the UI and the backend implementation, and unit tests and a storybook story. I've tried to split up the commits as much as I could so they should all be reviewable in separately.

Checklist

  • CHANGELOG.md has been updated to incorporate all user visible changes made by this pull request.
  • Issues have been created for any UI or other user-facing changes made by this pull request.
  • [Maintainers only] If this pull request makes user-facing changes that require documentation changes, open a corresponding docs pull request in the github/codeql repo and add the ready-for-doc-review label there.

Copy link
Contributor

@shati-patel shati-patel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks sensible, and works nicely locally! ☑️

I have a couple of non-blocking questions/suggestions, but LGTM overall 😎

@@ -42,6 +43,60 @@ describe(matchesFilter.name, () => {
).toBe(matches);
},
);

it("returns true if filterKey is all and resultCount is positive", () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor: this test block is quite large, I wonder if it makes sense to chunk it up into describe blocks somehow? E.g. the first tests (not the ones you added here) are all about searching, while these new ones describe "when filterKey is all/withResults"

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've split it up into two describe blocks. Let me know if that wasn't quite what you meant.

});
});

describe("when sort key and search and filter withResults are given", () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor: I found this a bit difficult to parse 😅

Maybe something like

Suggested change
describe("when sort key and search and filter withResults are given", () => {
describe("when sort key, search, and filter withResults are given", () => {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. Those definitely could be clearer 😅

I've updated the tests that have at least three items in the list to use commas.

repositories: T[] | undefined,
filterSortState: RepositoriesFilterSortStateWithIds | undefined,
): T[] | undefined {
if (!repositories) {
return undefined;
}

// If repository IDs are given, then ignore the search value and filter key
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor: Just a question around IDs, since I don't really understand where they come in to play with filtering 😅 When would repository IDs "be given"? As in, where do they come from?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question! I believe the answer is whenever you're operating on a list of repos selected by the user, such as when exporting results or copying a repo list to the clipboard. A user can use the tickboxes to select repos, and we pass that list into here using the repository IDs.

@robertbrignull
Copy link
Contributor Author

Also added a changelog entry because I forgot one until now.

Copy link
Contributor

@elenatanasoiu elenatanasoiu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good 👍

Thanks for splitting up the commits. It was easy to follow along.

@robertbrignull robertbrignull merged commit cf78dbb into main Apr 19, 2023
@robertbrignull robertbrignull deleted the robertbrignull/results_filter branch April 19, 2023 11:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants