Skip to content
This repository has been archived by the owner on Jul 2, 2024. It is now read-only.

EVG-19921: Allow unhiding patch card #2092

Merged
merged 20 commits into from
Nov 10, 2023
Merged

Conversation

SupaJoon
Copy link
Contributor

@SupaJoon SupaJoon commented Oct 6, 2023

EVG-19921

hidden.mov

Evergreen PR

evergreen-ci/evergreen#7116

@cypress
Copy link

cypress bot commented Oct 6, 2023

Passing run #13734 ↗︎

0 601 7 0 Flakiness 0
⚠️ You've recorded test results over your free plan limit.
Upgrade your plan to view test results.

Details:

fix copy
Project: Spruce Commit: a87d9a3cdf
Status: Passed Duration: 19:05 💡
Started: Nov 8, 2023 5:50 PM Ended: Nov 8, 2023 6:09 PM

Review all test suite changes for PR #2092 ↗︎

@SupaJoon SupaJoon requested a review from a team October 9, 2023 14:53
@SupaJoon
Copy link
Contributor Author

I'd like to discuss this feature in the design sync before making more changes.

@SupaJoon
Copy link
Contributor Author

I'll close this PR for now and reopen when it's ready for review

@SupaJoon SupaJoon closed this Oct 11, 2023
@SupaJoon SupaJoon reopened this Oct 16, 2023
@SupaJoon
Copy link
Contributor Author

This feature is similar to the "Include commit queue"

Comment on lines 177 to 179
> button {
margin-left: ${size.xs};
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Since this is already using flexbox, you can use the gap property instead

Suggested change
> button {
margin-left: ${size.xs};
}
gap: ${size.xs};

Comment on lines 198 to 200
const StyledCheckbox = styled(Checkbox)`
padding-left: ${size.xs};
`;
Copy link
Contributor

Choose a reason for hiding this comment

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

Similar note as above, you can add a gap to CheckboxContainer instead of creating a specialized checkbox.

e: React.ChangeEvent<HTMLInputElement>
): void => {
setIsIncludeHiddenCheckboxChecked(e.target.checked);
Cookies.set(INCLUDE_HIDDEN_PATCHES, e.target.checked ? "true" : "false");
Copy link
Contributor

@sophstad sophstad Oct 30, 2023

Choose a reason for hiding this comment

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

When I load this page with this cookie set to true, the checkbox is checked but hidden patches are not visible in the list (i.e. the state is set but the query does not include the hidden parameter).

Tbh I don't know how helpful a cookie is for this setting. Unlike the commit queue, it's probably something that would be looked at in special circumstances, not every time a user visits this page. But if you think it's worth including then the bug should be fixed!

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 was able to fix the issue with initial state. I decided to include the cookie to keep consistency with the commit queue checkbox and pagination buttons and also because it's more likely to be helpful than annoying/intrusive

): void => {
setIsIncludeHiddenCheckboxChecked(e.target.checked);
Cookies.set(INCLUDE_HIDDEN_PATCHES, e.target.checked ? "true" : "false");
// eslint-disable-next-line no-unused-expressions
Copy link
Contributor

Choose a reason for hiding this comment

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

I see this is also disabled above but I'm confused as to why. Can we get rid of it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's not necessary and I accidentally copied it in.

@@ -136,12 +160,14 @@ export const usePatchesInputFromSearch = (search: string): PatchesInput => {
PatchPageQueryParams.Statuses,
[]
);
const [hidden] = useQueryParam(PatchPageQueryParams.Hidden, false);
Copy link
Contributor

Choose a reason for hiding this comment

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

nit. Can we break this out into a separate file in this folder similar to what we do for other exported hooks.
image

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for sorting!

@@ -7,6 +7,7 @@ type Action =
| { name: "Click Patch Link" }
| { name: "Click Variant Icon"; variantIconStatus: string }
| { name: "Filter Commit Queue" }
| { name: "Filter Hidden" }
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 update this analytics event to include what he hidden state is? So that it becomes a little more useful.

const { sendEvent } = usePatchAnalytics(patchId);
const [setPatchVisibility] = useMutation<
SetPatchVisibilityMutation,
SetPatchVisibilityMutationVariables
>(SET_PATCH_VISIBILITY, {
onCompleted: () => {
dispatchToast.success("This patch was successfully hidden");
dispatchToast.success("Successfully updated patch visibility.");
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm actually not a fan of this verbiage, It isn't as clear as the old one. If you update the SET_PATCH_VISIBILITY mutation to also return the hidden state then you should be able to conditionally render a more tailored success message.

onCompleted: (d) => {
dispatchToast.success(
`This patch was successfully ${
d.setPatchVisibility?.[0].hidden ? "unhidden" : "hidden"
Copy link
Contributor

Choose a reason for hiding this comment

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

nit. Can you destructure this instead of deeply nesting?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

setPatchVisibility is used in the outer scope so it can't be destructured in the onCompleted function argument.
The alternative is to do something like this:
const { hidden } = d.setPatchVisibility?.[0] ?? {};
I think this is a lot more busy than what I have originally considering there is an extra assignment and ternary for a variable that's only used once. Instead I can move the copy calculation out of the string literal.

> button {
margin-left: ${size.xs};
}
gap: ${size.xs};
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice

const [hidden] = useQueryParam(PatchPageQueryParams.Hidden, false);
const statuses = rawStatuses.filter((v) => v && v !== ALL_PATCH_STATUS);
return {
limit: getLimitFromSearch(search),
Copy link
Contributor

Choose a reason for hiding this comment

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

Since you refactored this hook. Can we just use the useQueryParam hook for everything instead of relying on these older getLimitFromSearch and getPageFromSearch functions. I would like to eventually get rid of them in favor of the hooks.

Copy link
Contributor Author

@SupaJoon SupaJoon Nov 2, 2023

Choose a reason for hiding this comment

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

I think this should be done in a separate ticket because it's not a straightforward refactor and I think the two functions serve their purpose. getLimitFromSearch and getPageFromSearch have reuseable logic that validate and map the query param to a valid value. If these two functions are removed, useQueryParam should accept a validation function that determines whether the default value is returned. Otherwise, it may be worth to create a usePagination hook that includes logic from usePageSizeSelector and calls into useQueryParam since page and limit are reserved for the pagination feature and used in a bunch of places.

@@ -128,10 +130,12 @@ export const PatchCard: React.FC<Props> = ({
<TaskBadgeContainer>{badges}</TaskBadgeContainer>
</Center>
<Right>
{hidden && <Badge data-cy="hidden-badge">Hidden</Badge>}
Copy link
Contributor

Choose a reason for hiding this comment

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

Was this discussed at the design sync it seems a little out of place? I wonder if we can use something else to represent hidden patches?
Like opacity?
image

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We discussed the Hidden badge at the design sync but not the placement. I prefer the badge instead of opacity because opacity gives the patch card a filter effect and makes it more difficult to read. This is against the users intention to show hidden items.
I aligned Hidden badge next to the menu items because that's where the state is updated.

Copy link
Contributor

Choose a reason for hiding this comment

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

nit. Can we move this into the PatchCard folder.

@SupaJoon SupaJoon requested a review from khelif96 November 2, 2023 18:49
@SupaJoon
Copy link
Contributor Author

SupaJoon commented Nov 2, 2023

evergreen retry

@SupaJoon
Copy link
Contributor Author

SupaJoon commented Nov 8, 2023

evergreen retry

@khelif96 khelif96 removed their request for review November 9, 2023 21:56
@SupaJoon SupaJoon merged commit fa2cf39 into evergreen-ci:main Nov 10, 2023
5 checks passed
@SupaJoon SupaJoon deleted the EVG-19921 branch November 10, 2023 18:17
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants