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 config options for default sorting/filtering values in variant analysis results view #2392

Merged
merged 13 commits into from
May 3, 2023

Conversation

shati-patel
Copy link
Contributor

@shati-patel shati-patel commented Apr 28, 2023

Adds new settings for configuring the default display of variant analysis results:

image

This also changes the default display to sort by number of results (instead of by name).

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.
    • See internal issue.
  • [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.
    • Not needed: We have a general page about customizing settings here, and we've listed the specific new settings in the changelog.

Comment on lines 73 to 77
// Without this await, `getByDisplayValue` could not find any selected dropdown option.
await new Promise((resolve) => setTimeout(resolve, 0));

expect(screen.getByDisplayValue("With results")).toBeInTheDocument();
expect(screen.getByDisplayValue("Number of results")).toBeInTheDocument();
Copy link
Contributor Author

Choose a reason for hiding this comment

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

For some reason, await new Promise((resolve) => setTimeout(resolve, 0)); was necessary to get these "default" expectations to pass 🤔

Not sure why, but it works 😅 If anyone knows more about this, let us know!

Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure why this is happening (it could be that some of the VS Code UI toolkit shadow DOM is only rendered on the next tick or something like that), but a slightly more reliable way to solve this is by waiting for the element to start existing:

await waitFor(() => screen.getByText("With results"));

This way we don't depend on the exact tick and it will still fail if it doesn't find the element after some time.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is perfect! Thanks ✨

The default filterSortState is no longer to show "all" repositories, so I've created an explicit "all-inclusive" filterSortState for the purpose of these tests.
@shati-patel shati-patel marked this pull request as ready for review May 1, 2023 12:06
@shati-patel shati-patel requested review from a team as code owners May 1, 2023 12:06
extensions/ql-vscode/package.json Outdated Show resolved Hide resolved
extensions/ql-vscode/package.json Outdated Show resolved Hide resolved
Comment on lines 73 to 77
// Without this await, `getByDisplayValue` could not find any selected dropdown option.
await new Promise((resolve) => setTimeout(resolve, 0));

expect(screen.getByDisplayValue("With results")).toBeInTheDocument();
expect(screen.getByDisplayValue("Number of results")).toBeInTheDocument();
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure why this is happening (it could be that some of the VS Code UI toolkit shadow DOM is only rendered on the next tick or something like that), but a slightly more reliable way to solve this is by waiting for the element to start existing:

await waitFor(() => screen.getByText("With results"));

This way we don't depend on the exact tick and it will still fail if it doesn't find the element after some time.

Comment on lines 21 to 36
const postMessage = async (msg: ToVariantAnalysisMessage) => {
await act(async () => {
// window.postMessage doesn't set the origin correctly, see
// https://github.com/jsdom/jsdom/issues/2745
window.dispatchEvent(
new MessageEvent("message", {
source: window,
origin: window.location.origin,
data: msg,
}),
);

// The event is dispatched asynchronously, so we need to wait for it to be handled.
await new Promise((resolve) => setTimeout(resolve, 0));
});
};
Copy link
Member

Choose a reason for hiding this comment

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

Now that we're using this in at least two tests, do you think it would make sense to move this to a separate file and export the function?

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 idea! I wasn't sure where best to put the shared file. Currently in src/view/common/post-message.ts but I'm open to better suggestions 😅

@shati-patel
Copy link
Contributor Author

Thank you for the helpful comments, @koesie10 😍

@robertbrignull
Copy link
Contributor

When pairing on this on Friday, we decided to add the sort/filter information to the setVariantAnalysis message. This was for ease and because we're always already sending one of those messages at the time we want the sort/filter information.

Over the weekend I've thought more and I think it's still unclear what the best approach is, but I'm leaning more in favour of having a new message type and just sending two separate messages one after the other. That way the naming of the messages is more clear, and we don't have the sort/filter state being optional in the message.

What do you think?

These details of the webview messages are purely internal and there's no backwards compatibility concerns, so we could also do this as a followup PR after this one.

@shati-patel
Copy link
Contributor Author

When pairing on this on Friday, we decided to add the sort/filter information to the setVariantAnalysis message. This was for ease and because we're always already sending one of those messages at the time we want the sort/filter information.

Over the weekend I've thought more and I think it's still unclear what the best approach is, but I'm leaning more in favour of having a new message type and just sending two separate messages one after the other. That way the naming of the messages is more clear, and we don't have the sort/filter state being optional in the message.

What do you think?

These details of the webview messages are purely internal and there's no backwards compatibility concerns, so we could also do this as a followup PR after this one.

Thanks, @robertbrignull! That seems like a reasonable suggestion. Doesn't sounds too big, so I'll change that in this PR 👍🏽

Copy link
Contributor

@robertbrignull robertbrignull left a comment

Choose a reason for hiding this comment

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

LGTM from my point of view. @koesie10 do you want to take another look / have any comments or are you happy?

@shati-patel
Copy link
Contributor Author

Thanks for the reviews! I'll merge/fix conflicts once the 1.8.4 release is complete 🚀

Copy link
Member

@koesie10 koesie10 left a comment

Choose a reason for hiding this comment

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

LGTM, I just found one minor inconsistency

extensions/ql-vscode/src/pure/interface-types.ts Outdated Show resolved Hide resolved
extensions/ql-vscode/src/pure/interface-types.ts Outdated Show resolved Hide resolved
@shati-patel
Copy link
Contributor Author

LGTM, I just found one minor inconsistency

Woops! Thanks, @koesie10. Fixed.

@shati-patel
Copy link
Contributor Author

shati-patel commented May 3, 2023

Slight niggle (just discussed with @robertbrignull offline) is that I haven't yet implemented showing "in progress" repos.

If we only display With results by default, then the "in progress" repos are hidden from view when you kick off a variant analysis so it's harder to tell what is being analyzed. If no repos return results, then the view remains empty. See internal linked issue(s)!

Instead of fixing that in this PR, I'm going to change the default back to All here and merge. Then we can think a bit more about the "in progress" filtering in a follow-up.

Sorry for the noise! 🙉

@shati-patel shati-patel marked this pull request as draft May 3, 2023 13:35
@shati-patel
Copy link
Contributor Author

shati-patel commented May 3, 2023

Made All the default again in 006dd7e. There are other changes, like the permissiveFilterSortState in tests, which are no longer strictly necessary. But I'll keep that in, since I think it makes sense to decouple the default filter sort state from those tests.

@robertbrignull, would you mind giving this another look to make sure it matches what we discussed? 🙇🏽‍♀️

@shati-patel shati-patel marked this pull request as ready for review May 3, 2023 14:08
Copy link
Contributor

@robertbrignull robertbrignull left a comment

Choose a reason for hiding this comment

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

Yep, this matches what I thought we discussed.

I also tried running it and it works well. I'd be happy to ship this.

@shati-patel shati-patel enabled auto-merge (squash) May 3, 2023 14:48
@shati-patel shati-patel merged commit 71611e0 into main May 3, 2023
@shati-patel shati-patel deleted the shati-patel/sorting-config branch May 3, 2023 14:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants