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

upcoming: [M3-8021] - Manage Image Regions Drawer #10617

Merged

Conversation

bnussman-akamai
Copy link
Member

@bnussman-akamai bnussman-akamai commented Jun 26, 2024

Description πŸ“

  • This is for Image Service Gen2 βœ¨πŸ’Ύ
  • Adds drawer for Manage Regions option on an Image's action menu 🌐

Preview πŸ“·

Screenshot 2024-06-26 at 2 01 00β€―PM

How to test πŸ§ͺ

Prerequisites

  • Turn on the MSW

Verification steps

  • Test the Manage Regions drawer
    • Note that the whole "e2e" flow won't work perfect using the MSW

As an Author I have considered πŸ€”

  • πŸ‘€ Doing a self review
  • ❔ Our contribution guidelines
  • 🀏 Splitting feature into small PRs
  • βž• Adding a changeset
  • πŸ§ͺ Providing/Improving test coverage
  • πŸ” Removing all sensitive information from the code and PR description
  • 🚩 Using a feature flag to protect the release
  • πŸ‘£ Providing comprehensive reproduction steps
  • πŸ“‘ Providing or updating our documentation
  • πŸ•› Scheduling a pair reviewing session
  • πŸ“± Providing mobile support
  • β™Ώ Providing accessibility support

Copy link
Contributor

@hkhalil-akamai hkhalil-akamai left a comment

Choose a reason for hiding this comment

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

Great work so far, this is shaping up nicely!


export const ManageImageRegionsDrawer = (props: Props) => {
const { image, onClose } = props;
const open = image !== undefined;
Copy link
Contributor

Choose a reason for hiding this comment

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

Noticing a flash of content when closing the drawer since image becomes undefined -- one workaround is using usePrevious(image) like in EditImageDrawer.tsx

Copy link
Member Author

Choose a reason for hiding this comment

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

I think this might be addressed by bfccbd4

I updated how state is handled in ImagesLanding so that the whole Image object is no longer store in state. It is now derived directly from the React Query data. I did this because we'll want the ManageImageRegionsDrawer to show the latest statuses because we'll be polling for updates.

@bnussman-akamai bnussman-akamai marked this pull request as ready for review June 27, 2024 17:41
@bnussman-akamai bnussman-akamai requested a review from a team as a code owner June 27, 2024 17:41
@bnussman-akamai bnussman-akamai requested review from carrillo-erik and abailly-akamai and removed request for a team June 27, 2024 17:41
Comment on lines 54 to 59
useEffect(() => {
if (open) {
resetForm({ regions: imageRegionIds });
reset();
}
}, [open]);
Copy link
Member Author

Choose a reason for hiding this comment

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

Is there a better way to do this?

Copy link

github-actions bot commented Jun 27, 2024

Coverage Report: βœ…
Base Coverage: 82.18%
Current Coverage: 82.18%

@bnussman-akamai bnussman-akamai requested a review from a team as a code owner June 27, 2024 21:39
@bnussman-akamai bnussman-akamai requested review from cliu-akamai and hkhalil-akamai and removed request for a team June 27, 2024 21:39
Copy link
Contributor

@hkhalil-akamai hkhalil-akamai left a comment

Choose a reason for hiding this comment

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

All functionality looks great when tested under the MSW. Thank you for adding comprehensive unit and integration tests.

βœ… Opening the drawer from the regions list and actions menu
βœ… Viewing existing regions and their statuses
βœ… Adding new regions
βœ… Saving updates (image service is not live yet)

<Stack spacing={1}>
{values.regions.length === 0 && (
<Typography py={1} textAlign="center">
No Regions Selected
Copy link
Contributor

Choose a reason for hiding this comment

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

Based on the UX mockups, there should always be at least one region selected -- should we disable the option to remove the region is there is only 1 left? I'm not sure how this endpoints works on the API side: can an image be moved to a completely new set of regions or does there have to be at least one previous region when replicating?

Copy link
Contributor

Choose a reason for hiding this comment

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

If not, can we add a unit test to ensure this message displays when no regions are selected?

Copy link
Member Author

@bnussman-akamai bnussman-akamai Jul 3, 2024

Choose a reason for hiding this comment

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

should we disable the option to remove the region is there is only 1 left

We could. Currently I built it so that the form validates that >= 1 region is selected. I put this empty state here for that case and for robustness.

I think using form field validation is fine because it gives the user good context when it says you must have at least one region selected.

Copy link
Contributor

@abailly-akamai abailly-akamai left a comment

Choose a reason for hiding this comment

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

Implementation looks great! Now (unrelated to your work)...

I think this UI is unfortunate and quite frankly unacceptable. A user starts selecting from a multi select which populates a lit below the user can't even see.

Screen.Recording.2024-06-28.at.10.54.49.mov

This is just bad and i believe we had decided to stay away from this pattern in favor of just using the multi select, just like for multicluster access key

Screen.Recording.2024-06-28.at.11.00.50.mov

I think we need to push back on UI to go that route, stay consistent and provide better experience for our users

packages/api-v4/src/images/images.ts Show resolved Hide resolved
useEffect(() => {
resetForm({ regions: imageRegionIds });
reset();
}, [imageRegionIds, open]);
Copy link
Contributor

Choose a reason for hiding this comment

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

you should use the onExited here too

Copy link
Member Author

Choose a reason for hiding this comment

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

I guess that would work, but what if the regions change while the drawer is closed? It would show stale data when reopened. Not sure if that's something we should account for or not.

Copy link
Contributor

Choose a reason for hiding this comment

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

hmm - I see what you mean. On the other hand if we were worried that the regions would change why the drawer is closed maybe it points out that the fetching should be in the drawer?

It's not a big deal either way, I just can't fathom why there isn't an onOpen for the drawer...

reading further, onTransitionEnd would work for both opening and closing perhaps
mui/material-ui#36728

again, that useEffect seems rather inoffensive tho we've had surprises in the past

Copy link
Member Author

Choose a reason for hiding this comment

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

It's kind of a new pattern for us, but let me know what you think about the changes in 9d8c0d6.

It changes how the Drawer's contents are mounted and it uses react-hook-form's values option to react to the Image's regions changing

Comment on lines +582 to +591
<Drawer
onClose={() => setIsManageRegionsDrawerOpen(false)}
open={isManageRegionsDrawerOpen}
title={`Manage Regions for ${selectedImage?.label}`}
>
<ManageImageRegionsForm
image={selectedImage}
onClose={() => setIsManageRegionsDrawerOpen(false)}
/>
</Drawer>
Copy link
Member Author

@bnussman-akamai bnussman-akamai Jun 28, 2024

Choose a reason for hiding this comment

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

I don't love how this looks, but it gives us the benefit of not having to worry about resetting the form onOpen or onClose. ManageImageRegionsForm gets unmounted when isManageRegionsDrawerOpen is false, which resets the form and is probably better for performance in general anyway.

I'm wondering if we should be doing Drawers this way more often

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't know how I feel about this. The pattern does not look very intuitive or developer friendly to me (esp a form taking an onClose since a form can technically be reusable outside of a drawer). The reset on a form state has the benefit of being very explicit while this solution obscures the logic

Copy link
Contributor

Choose a reason for hiding this comment

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

Not blocking this PR, but I am still not convinced here - functionality is good but developer experience would need to be improved if this is a pattern we'd start using more.

@bnussman-akamai
Copy link
Member Author

@abailly-akamai

A user starts selecting from a multi select which populates a lit below the user can't even see.

Just so we're on the same page, the regions are not added to the lower list until the Multi-Select popover is closed.

I assume this don't change much, but does your UX feedback still stand?

@abailly-akamai
Copy link
Contributor

@bnussman-akamai it does still stand since the visual end result is the same. No progress on getting UX to reconsider and provide a similar solution for what we have done for the multicluster access key?

@bnussman-akamai
Copy link
Member Author

UX would like to continue with the current approach

Copy link
Contributor

@abailly-akamai abailly-akamai left a comment

Choose a reason for hiding this comment

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

Nice work! While i don't approve of the UI approach, functionality/code is solid from my vantage point.

Approving pending a couple questions βœ…


enqueueSnackbar('Image regions successfully updated.', {
variant: 'success',
});
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we mean to not close the drawer when saving regions?

<Notice text={errors.root.message} variant="error" />
)}
<Typography>
Custom images are billed monthly, at $.10/GB. Check out{' '}
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we usually display $.10/GB rather than $0.10/GB??

my initial glance read 10/GB so wanted to make sure

Copy link
Contributor

Choose a reason for hiding this comment

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

Am still curious about this one

Copy link
Contributor

Choose a reason for hiding this comment

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

my initial glance read 10/GB so wanted to make sure

I saw this and had the same thought, so came here! We should keep $0.10/GB, as we have elsewhere.

image

Comment on lines +582 to +591
<Drawer
onClose={() => setIsManageRegionsDrawerOpen(false)}
open={isManageRegionsDrawerOpen}
title={`Manage Regions for ${selectedImage?.label}`}
>
<ManageImageRegionsForm
image={selectedImage}
onClose={() => setIsManageRegionsDrawerOpen(false)}
/>
</Drawer>
Copy link
Contributor

Choose a reason for hiding this comment

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

Not blocking this PR, but I am still not convinced here - functionality is good but developer experience would need to be improved if this is a pattern we'd start using more.

@abailly-akamai
Copy link
Contributor

I will also just leave this here for legacy 😒

Screenshot 2024-07-03 at 13 21 20

@bnussman-akamai bnussman-akamai merged commit c7842f0 into linode:develop Jul 3, 2024
19 checks passed
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.

5 participants