-
Notifications
You must be signed in to change notification settings - Fork 364
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
upcoming: [M3-8021] - Manage Image Regions Drawer #10617
Conversation
There was a problem hiding this 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; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 status
es because we'll be polling for updates.
useEffect(() => { | ||
if (open) { | ||
resetForm({ regions: imageRegionIds }); | ||
reset(); | ||
} | ||
}, [open]); |
There was a problem hiding this comment.
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?
Coverage Report: β
|
There was a problem hiding this 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this 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/manager/src/features/Images/ImagesLanding/ImageRegions/ImageRegionRow.tsx
Show resolved
Hide resolved
packages/manager/src/features/Images/ImagesLanding/ImageRegions/ImageRegionRow.tsx
Outdated
Show resolved
Hide resolved
useEffect(() => { | ||
resetForm({ regions: imageRegionIds }); | ||
reset(); | ||
}, [imageRegionIds, open]); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
β¦gionsPayload` instead of `regions: string[]`
<Drawer | ||
onClose={() => setIsManageRegionsDrawerOpen(false)} | ||
open={isManageRegionsDrawerOpen} | ||
title={`Manage Regions for ${selectedImage?.label}`} | ||
> | ||
<ManageImageRegionsForm | ||
image={selectedImage} | ||
onClose={() => setIsManageRegionsDrawerOpen(false)} | ||
/> | ||
</Drawer> |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
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? |
@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? |
UX would like to continue with the current approach |
There was a problem hiding this 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', | ||
}); |
There was a problem hiding this comment.
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{' '} |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<Drawer | ||
onClose={() => setIsManageRegionsDrawerOpen(false)} | ||
open={isManageRegionsDrawerOpen} | ||
title={`Manage Regions for ${selectedImage?.label}`} | ||
> | ||
<ManageImageRegionsForm | ||
image={selectedImage} | ||
onClose={() => setIsManageRegionsDrawerOpen(false)} | ||
/> | ||
</Drawer> |
There was a problem hiding this comment.
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.
Description π
Manage Regions
option on an Image's action menu πPreview π·
How to test π§ͺ
Prerequisites
Verification steps
Manage Regions
drawerAs an Author I have considered π€