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-7872] - Linode Create Refactor - StackScripts #10367

Conversation

bnussman-akamai
Copy link
Member

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

Description 📝

Note

Because of the amount of work involved to implement StackScripts on the new Linode Create flow, it will be broken up into a few PRs. You can consider this Part 1. There will be a part 2. Maybe a part 3.

This PR begins to implement the "StackScripts" section of the new Linode Create flow 🎉

Main features ➕

  • This is all new code. I considered hooking up the old code but it was way too crusty. 👎🏼 We'll be better with fresh code. 🧼
  • Begins to React Query-ify StackScripts. This allows us to use nice things like infinite queries. Eventually we we refactor all of the StackScripts pages to use React Query, but there is no hurry to do so. 🧹
  • Adds the ability to select a community or account StackScript and deploy it to a Linode ➕
  • Properly resets form when tab is changed to match behavior of existing flow
  • Fixes deep linking when clicking "Deploy to new Linode" from the Images Landing Page
  • Adds deep linking when clicking "Deploy new Linode" from the StackScripts Landing Page

Features that will come in Part 2

  • Re-add the Search field 🔍
  • Add User Defined Fields (UDFs) ⌨️

Preview 📷

Screenshot 2024-04-10 at 4 16 53 PM

How to test 🧪

Prerequisites

  • Turn on the Linode Create v2 feature flag using the local dev tools

Verification steps

  • Check for basic functionality
  • Verify you can select an account StackScript
  • Verify you can select a community StackScript
  • Verify you can click "Deploy New Linode" on the StackScripts landing page and it auto-fills the Linode Create form
  • Verify Query Params work and update as expected
  • Compare functionality to https://cloud.linode.com

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 11, 2024 20:51
@bnussman-akamai bnussman-akamai requested a review from a team as a code owner April 11, 2024 20:51
@bnussman-akamai bnussman-akamai requested review from dwiley-akamai and hana-akamai and removed request for a team April 11, 2024 20:51
Copy link

github-actions bot commented Apr 12, 2024

Coverage Report:
Base Coverage: 81.81%
Current Coverage: 81.83%

@jaalah-akamai
Copy link
Contributor

jaalah-akamai commented Apr 12, 2024

  • ✅ Skeleton loading and caching when switching between tabs is much nicer
  • ✅ When re-ordering community stackscripts many times, we no longer get "Too many requests"
  • ✅ Better section separation between Create From: and Select an Image

When selecting an account stackscript, it appears the endpoint we're hitting is different between prod and this:

Prod Refactor
Screenshot 2024-04-12 at 9 51 10 AM Screenshot 2024-04-12 at 9 51 17 AM

@jaalah-akamai
Copy link
Contributor

jaalah-akamai commented Apr 12, 2024

If there is only one image to select from, in Prod we're pre-populating "Choose an Image" dropdown - do we want to maintain this?

@jaalah-akamai
Copy link
Contributor

Do we want to maintain the bolding we have stackscripts?
Screenshot 2024-04-12 at 9 57 42 AM

@jaalah-akamai
Copy link
Contributor

jaalah-akamai commented Apr 12, 2024

In Prod, the linode label is pre-populated with the selected stackscript name, is that something we want to keep? I know you had opinions about that in the past.

@bnussman-akamai
Copy link
Member Author

@jaalah-akamai

  • ✅ If there is only one image to select from, pre-repopulate "Choose an Image" dropdown
  • ✅ Re-add bolding to label
  • The different API requests should be no worry. As long as behavior is the same, we should be good!
  • Linode label auto-generation will be handled at at later point

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 on this so far! I agree with a fresh approach to the StackScripts components. Will continue my review next week.

Copy link
Contributor

Choose a reason for hiding this comment

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

Noticing that the StackScripts Image selection lives in its own card in contrast to prod where it shares a card with the StackScript Selection

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 believe that was a regression, so sections will now be spaced out

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.

Super nice refactor! left some minor code and style comments to improve a few things, stick to conventions and consider visual regression/changes

if (
filteredOptions?.length === 1 &&
props.onChange &&
selectIfOnlyOneOption
Copy link
Contributor

Choose a reason for hiding this comment

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

Aren't filteredOptions?.length === 1 & selectIfOnlyOneOption doing the same thing?

Do we need the selectIfOnlyOneOption optional prop?

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 added the selectIfOnlyOneOption prop so that the functionality is op-in. I don't think it should be the default behavior

<Table>
<TableHead>
<TableRow>
<TableCell sx={{ width: 20 }}></TableCell>
Copy link
Contributor

Choose a reason for hiding this comment

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

I personally prefer the older table header rendering without an extra cell for the radio. Not a big deal either way, but that's a regression from previous layout, even if meant as an improvement.

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 did it this way to match our other selectable tables like Plan selection and Service Transfers. I'd be happy to rework this so that it is one single table cell if this is too much of a breaking change.

onOpenDetails={() => setSelectedStackScriptId(stackscript.id)}
onSelect={() => field.onChange(stackscript.id)}
stackscript={stackscript}
/>
Copy link
Contributor

Choose a reason for hiding this comment

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

on mobile PROD we wrap the "show details" CTA which leaves more room for the title

Copy link
Member Author

@bnussman-akamai bnussman-akamai Apr 15, 2024

Choose a reason for hiding this comment

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

Yep. I think I'd have to rework this so that it is one single table cell if we want this behavior. The wrapping looked kind of wacky to me, so that's why I went the route of using 3 table cells. I'd be happy to re-work this back to a single table cell if you think that's better

<TableCell actionCell sx={{ minWidth: 120 }}>
<InlineMenuAction actionText="Show Details" onClick={onOpenDetails} />
</TableCell>
</TableRow>
Copy link
Contributor

Choose a reason for hiding this comment

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

As mentioned in other comments, typography is a a bit different here. It's not really pretty originally with the bolding so not sure what is best. A quick UX back and forth could be helpful to clean that up

image: null,
stackscript_data: null,
stackscript_id: null,
}));
Copy link
Contributor

Choose a reason for hiding this comment

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

nice 👍

history.push({ search: newParams.toString() });
};

const params = {
imageID: rawParams.imageID as string | undefined,
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
imageID: rawParams.imageID as string | undefined,
imageId: rawParams.imageId as string | undefined,

Copy link
Member Author

@bnussman-akamai bnussman-akamai Apr 15, 2024

Choose a reason for hiding this comment

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

Yeah, I debated that change. I did imageID because that is how it is represented in the query params (which we can't change because we need to keep feature parity), but I can change this variable to imageId if we'd prefer that. I think imageID helps the reader understand that it matches the query param, but I'm also cool with strictly following our camel case rule.

history.push({ search: newParams.toString() });
};

const params = {
imageID: rawParams.imageID as string | undefined,
stackScriptID: rawParams.stackScriptID
Copy link
Contributor

Choose a reason for hiding this comment

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

same, would be nice to stick to our Id convention here and below

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.

Tested:

✅ Selecting account and community stackscripts
✅ Viewing stack script details
✅ Actually creating the Linode from stackscript
✅ Code review 🧼

Really nice work on this. Approved pending some minor tweaks raised by @abailly-akamai.

@bnussman-akamai bnussman-akamai merged commit cffa916 into linode:develop Apr 18, 2024
18 checks passed
mjac0bs pushed a commit to mjac0bs/manager that referenced this pull request Apr 18, 2024
…0367)

* initial work

* filter options based on stackscript compatibility

* implement complex preselection logic

* clean up a bit

* implement details dialog

* fix some query param logic

* lots of behavior changes to match production

* fix image select clear behavior and fix table waypoint console error

* improve validation for when image is `null`

* first unit tests

* add lots of unit testing

* add stackscript event handler

* hook up validation packages for realtime validation

* use default validation behavior

* Revert "hook up validation packages for realtime validation"

This reverts commit f56e4ad.

* handle resets when switching tabs

* add changesets

* add some comments

* bold label and pre-select if only one option

* improve ux

* fix unit tests

* add comment

---------

Co-authored-by: Banks Nussman <banks@nussman.us>
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