upcoming: [M3-7875] - Linode Create Refactor - Backups#10404
Conversation
|
Coverage Report: ✅ |
abailly-akamai
left a comment
There was a problem hiding this comment.
Looks great! Patterns are solid and consistent
Added a few comments before taking a second pass
| ); | ||
|
|
||
| const hasNoBackups = | ||
| !isFetching && data?.automatic.length === 0 && !data.snapshot.current; |
There was a problem hiding this comment.
I always wonder if there is a risk of API data used in computation being stale right after the re-render in cases like this.
There was a problem hiding this comment.
Do you mean something like this component showing backups for the previously selected Linode? Or the React Query cache being out of date containing stale data?
There was a problem hiding this comment.
Sorry not being very clear. It's frankly something I am always struggling a bit with (and this example is probably just fine). This type of computation in the react world has always been advocated to be done in useEffects cause we can control rendering cycles a bit more granularly. While very happy to move away from using those, I sometimes wonder if (in this case for instance), hasNoBackups gets recalculated properly, when needed.
There was a problem hiding this comment.
In this case, I think we're good. hasNoBackups should always get derived directly from the React Query state on each and every render.
Side note: I removed the isFetching from the condition. It wasn't needed based on how I did the conditional rendering.
| /> | ||
| ))} | ||
| </TableBody> | ||
| </Table> |
There was a problem hiding this comment.
You had previously dismissed a comment about the handling of the radio/label table column in the Stackscripts create flow and it would be nice for those to be consistent (they aren't in Prod either). we have a mix of floating left, extra cell, extra spacing etc
Am in favor of floating everything left without an extra column for the radio but whatever is consistent works for me in the end.
| Stackscript | Backups |
|---|---|
![]() |
![]() |
There was a problem hiding this comment.
I created M3-8041 in the epic so we can follow up, find the best pattern, and implement it on all tables
packages/manager/src/features/Linodes/LinodeCreatev2/Tabs/Backups/BackupsWarning.tsx
Outdated
Show resolved
Hide resolved
| // Always default debian for the distributions tab. | ||
| if (!params.type || params.type === 'Distributions') { | ||
| return 'linode/debian11'; | ||
| } |
There was a problem hiding this comment.
this is probably fine, but could be made as a constant since you are using it down on line 306
nit: I would also argue that we should check that it exists and if not select the first in array via a util. I know it's unlikely we will remove it but it's a small safety net
There was a problem hiding this comment.
Yeah, handling default values has been hard. We can't really "check that it exists" at this point because we don't have images loaded into memory yet. Hoping to find better way to do it and clean up over time. Will make a constant for Debian 11 for now
There was a problem hiding this comment.
Sounds good. I imagine we will want to set defaults via custom hooks so we can hook in the data in memory?
SanPilot
left a comment
There was a problem hiding this comment.
Manual testing and code review both look good. Left some feedback including one possible bug.
packages/manager/src/features/Linodes/LinodeCreatev2/utilities.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Why are we no longer using a common selection table component for backups and clone?
There was a problem hiding this comment.
I wen't ahead and created a new table because this new one is API filtered and ordered. Also, creating a new table allows us to use react-hook-form hooks closer to where they are consumed (less props required). I think these reasons warrant new code but I'm happy to reevaluate if you think I should be using more code from the old flow
packages/manager/src/features/Linodes/LinodeCreatev2/Tabs/Backups/LinodeSelectTable.tsx
Outdated
Show resolved
Hide resolved
| <Paper> | ||
| <Stack spacing={1}> | ||
| <Typography variant="h2">Select Linode</Typography> | ||
| <BackupsWarning /> |
There was a problem hiding this comment.
I'm not opposed to moving the notice below the header but I think UX should be informed of the change
| <SafeTabPanel index={3}> | ||
| <Images /> | ||
| </SafeTabPanel> | ||
| <SafeTabPanel index={4}>Bckups</SafeTabPanel> |
There was a problem hiding this comment.
Finally, this typo has been bugging me 😂
hkhalil-akamai
left a comment
There was a problem hiding this comment.
Whoops, signed into the wrong account 😅
Approved pending feedback from the previous review
| return ( | ||
| <Notice variant="warning"> | ||
| <List sx={{ listStyleType: 'disc', pl: 2.5 }}> | ||
| <ListItem sx={{ display: 'list-item', pl: 1, py: '4px' }}> |
There was a problem hiding this comment.
Would this work?
| <ListItem sx={{ display: 'list-item', pl: 1, py: '4px' }}> | |
| <ListItem sx={{ display: 'list-item', pl: 1, py: 4}}> |
There was a problem hiding this comment.
Yeah! I updated the value to 0.5 instead of 4px. I believe MUI takes ints and multiples them by theme.spacing
abailly-akamai
left a comment
There was a problem hiding this comment.
Approving pending addressing @hkhalil-akamai's suggestions and comments.
Also, agree a shared Linode table for Backups/Clone would be nice if easily doable
| This newly created Linode will be created with the same password and | ||
| SSH Keys (if any) as the original Linode. | ||
| </ListItem> | ||
| <ListItem sx={{ display: 'list-item', pl: 1, py: '4px' }}> |
There was a problem hiding this comment.
same here I agree using ints is always better for spacing values when possible


Description 📝
Preview 📷
How to test 🧪
Prerequisites
Linode Create v2feature flagVerification steps
Note
The API does not support filtering on
backups.enabled, so for now, the table will show all Linodes rather than just Linodes with backups enabled. I will work with the API team to get this sorted!Note
I moved the position of the warning notice. I think the change is tasteful, acceptable, and in-line with our Notice patterns. If anyone has concerns about moving it I can move it to match production.
As an Author I have considered 🤔