Skip to content

upcoming: [M3-7875] - Linode Create Refactor - Backups#10404

Merged
bnussman-akamai merged 28 commits intolinode:developfrom
bnussman-akamai:M3-7875-linode-create-refactor-backups
Apr 29, 2024
Merged

upcoming: [M3-7875] - Linode Create Refactor - Backups#10404
bnussman-akamai merged 28 commits intolinode:developfrom
bnussman-akamai:M3-7875-linode-create-refactor-backups

Conversation

@bnussman-akamai
Copy link
Member

@bnussman-akamai bnussman-akamai commented Apr 24, 2024

Description 📝

  • Linode Create Refactor for creating from a backup 💾

Preview 📷

Screenshot 2024-04-25 at 1 20 15 PM

How to test 🧪

Prerequisites

  • Turn on the Linode Create v2 feature flag

Verification steps

  • Check for parity with the existing Linode Create flow backups tab
  • Verify you can deep link to a pre-selected backup from the Linode Details page
  • Verify existing tabs still work as expected
  • Verify the page feel quick and snappy (no lag when making selections)

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 🤔

  • 👀 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

@bnussman-akamai bnussman-akamai marked this pull request as ready for review April 25, 2024 17:24
@bnussman-akamai bnussman-akamai requested a review from a team as a code owner April 25, 2024 17:24
@bnussman-akamai bnussman-akamai requested review from carrillo-erik and jdamore-linode and removed request for a team April 25, 2024 17:24
@bnussman-akamai bnussman-akamai requested review from hkhalil-akamai and removed request for carrillo-erik and jdamore-linode April 25, 2024 17:24
@github-actions
Copy link

github-actions bot commented Apr 25, 2024

Coverage Report:
Base Coverage: 81.82%
Current Coverage: 81.82%

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.

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;
Copy link
Contributor

Choose a reason for hiding this comment

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

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

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?

Copy link
Contributor

Choose a reason for hiding this comment

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

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

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>
Copy link
Contributor

Choose a reason for hiding this comment

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

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
Screenshot 2024-04-26 at 09 21 13 Screenshot 2024-04-26 at 09 21 25

Copy link
Member Author

@bnussman-akamai bnussman-akamai Apr 26, 2024

Choose a reason for hiding this comment

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

I created M3-8041 in the epic so we can follow up, find the best pattern, and implement it on all tables

// Always default debian for the distributions tab.
if (!params.type || params.type === 'Distributions') {
return 'linode/debian11';
}
Copy link
Contributor

@abailly-akamai abailly-akamai Apr 26, 2024

Choose a reason for hiding this comment

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

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

Copy link
Member Author

@bnussman-akamai bnussman-akamai Apr 26, 2024

Choose a reason for hiding this comment

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

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Sounds good. I imagine we will want to set defaults via custom hooks so we can hook in the data in memory?

Copy link
Contributor

@SanPilot SanPilot left a comment

Choose a reason for hiding this comment

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

Manual testing and code review both look good. Left some feedback including one possible bug.

Copy link
Contributor

Choose a reason for hiding this comment

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

Why are we no longer using a common selection table component for backups and clone?

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 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

<Paper>
<Stack spacing={1}>
<Typography variant="h2">Select Linode</Typography>
<BackupsWarning />
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 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>
Copy link
Contributor

Choose a reason for hiding this comment

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

Finally, this typo has been bugging me 😂

Copy link
Member Author

Choose a reason for hiding this comment

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

Same! 😅

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.

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' }}>
Copy link
Contributor

Choose a reason for hiding this comment

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

Would this work?

Suggested change
<ListItem sx={{ display: 'list-item', pl: 1, py: '4px' }}>
<ListItem sx={{ display: 'list-item', pl: 1, py: 4}}>

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah! I updated the value to 0.5 instead of 4px. I believe MUI takes ints and multiples them by theme.spacing

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.

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' }}>
Copy link
Contributor

Choose a reason for hiding this comment

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

same here I agree using ints is always better for spacing values when possible

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