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

feat: [M3-7806] - Linode Create Refactor - Part 1 #10268

Merged

Conversation

bnussman-akamai
Copy link
Member

@bnussman-akamai bnussman-akamai commented Mar 8, 2024

Description 📝

This begins the refactor of the Linode Create flow. The goal is to build a new create flow from scratch using modern practices so that the Linode create flow is better and more maintainable. The goal is for this new create flow to be "backwards compatible", meaning we can flip the feature flags and customers have the exact same experience.

  • Initial PR of the Linode Create Refactor 🎉
    • Introduces react-hook-form 🔘
      • We are doing this for the type-safety, performance, and flexibility (in comparison to formik)
    • Setups up initial scaffolding and feature flag 🚩
    • Begins incorporating some existing components (region select and plan selection)

Preview 📷

Screen.Recording.2024-03-08.at.3.14.17.PM.mov

How to test 🧪

  • Check out this PR
  • Use our local dev tools 🔧 and enable the new create flow feature flag
  • Test the new create flow
  • Look at my code and be critical
  • Verify I didn't break anything with the existing Linode create flow components

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 self-assigned this Mar 8, 2024
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'm going to make it my goal to not touch the old create flow as I build out this new one, but I might make some exceptions

Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed! That's ok, but also we could go without those to tighten scope and have reviewers only test the new flow.

Just like the type change, It makes things more complicated to ship/merge since we have to worry about production code being affected and not being behind the flag. It's such a crucial flow we want to be a bit strict about it.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeahhh. My original intention was to do exactly that.

I wanted to do the type change (CreateLinodeRequest) because either way it should to be fixed for the sake of correctness and consumers of @linode/api-v4

Going forward I'll force myself to be more strict. I'm not too stressed about breaking the existing flow because we have some testing coverage for it, but it definitely could still happen.

Copy link
Contributor

Choose a reason for hiding this comment

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

I still feel like this could go in its own PR, but if not, can we at least get two changesets?

  • one upcoming for v2 refactor
  • one change for APIv4

Copy link
Member Author

Choose a reason for hiding this comment

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

This is the root of the new create flow!

Comment on lines +353 to +354
type: string;
region: string;
Copy link
Member Author

Choose a reason for hiding this comment

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

This was a major oversight. type and region are the two required values to create a Linode

Copy link
Contributor

Choose a reason for hiding this comment

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

😮 thx for catching

Did you consider creating a v2 type and not touch at all the existing flow?

Copy link
Member Author

Choose a reason for hiding this comment

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

We could do that, but I think it's fair to fix the primary type.

@bnussman-akamai bnussman-akamai marked this pull request as ready for review March 8, 2024 20:31
@bnussman-akamai bnussman-akamai requested review from a team as code owners March 8, 2024 20:31
@bnussman-akamai bnussman-akamai requested review from cliu-akamai, mjac0bs and jaalah-akamai and removed request for a team March 8, 2024 20:31
Comment on lines +495 to +496
<Stack gap={3}>
<Tabs
Copy link
Member Author

@bnussman-akamai bnussman-akamai Mar 8, 2024

Choose a reason for hiding this comment

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

I just added a Stack so that we could remove the margin from each component and control the spacing with a Stack in the new create flow.

Copy link

github-actions bot commented Mar 8, 2024

Coverage Report:
Base Coverage: 81.39%
Current Coverage: 81.39%

Comment on lines +42 to +45
<Error />
<Region />
<Plan />
<Summary />
Copy link
Member Author

@bnussman-akamai bnussman-akamai Mar 8, 2024

Choose a reason for hiding this comment

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

I'm not sure how well these component names will scale, but for now, I'm just trying to keep things dead simple. We can adjust as we build this 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.

So nice! Super clean implementation so far and nice to see the introduction of React Forms.

Can we consider not modifying the existing flow at all?

Comment on lines +353 to +354
type: string;
region: string;
Copy link
Contributor

Choose a reason for hiding this comment

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

😮 thx for catching

Did you consider creating a v2 type and not touch at all the existing flow?

const regionId = watch('region');

const hasCreateLinodePermission =
grants === undefined || grants.global.add_linodes;
Copy link
Contributor

Choose a reason for hiding this comment

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

there are new hooks to handle those permissions. useIsResourceRestricted & useRestrictedGlobalGrantCheck. am thinking we may want to start/keep using those for consistency

Copy link
Member Author

Choose a reason for hiding this comment

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

Ahh yes. Thank you! I couldn't remember the names of these!

const { watch } = useFormContext<CreateLinodeRequest>();
const { field, fieldState } = useController<CreateLinodeRequest>({
name: 'type',
});
Copy link
Contributor

Choose a reason for hiding this comment

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

this looks like a very useful API - will learn about useController more

</Notice>
</Paper>
);
};
Copy link
Contributor

Choose a reason for hiding this comment

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

Love it - can formState.errors be an array of errors?

Copy link
Member Author

@bnussman-akamai bnussman-akamai Mar 11, 2024

Choose a reason for hiding this comment

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

I don't think formState.errors would ever be an array. errors will match the shape of the form type (CreateLinodeRequest in this case).

For example formState.errors.interfaces?.[0]?.ipv4?.nat_1_1?.message is valid and typesafe, so arrays are supported. This is great because formik supported arrays, but struggled with getting the type safety correct.

Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed! That's ok, but also we could go without those to tighten scope and have reviewers only test the new flow.

Just like the type change, It makes things more complicated to ship/merge since we have to worry about production code being affected and not being behind the flag. It's such a crucial flow we want to be a bit strict about it.


return (
<FormProvider {...methods}>
<form onSubmit={methods.handleSubmit(onSubmit)}>
Copy link
Contributor

Choose a reason for hiding this comment

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

I get why you named it onSubmit, it just departs from our convention of naming the handler handleSubmit... maybe we need to revise what we do

Copy link
Contributor

@jaalah-akamai jaalah-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 comments @abailly-akamai - This is an amazing start @bnussman and is looking clean! 👍

@bnussman-akamai bnussman-akamai added the Approved Multiple approvals and ready to merge! label Mar 12, 2024
@bnussman-akamai bnussman-akamai merged commit aa59941 into linode:develop Mar 12, 2024
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Approved Multiple approvals and ready to merge! Linode Create Refactor
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants