-
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
feat: [M3-7806] - Linode Create Refactor - Part 1 #10268
feat: [M3-7806] - Linode Create Refactor - Part 1 #10268
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.
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
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.
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.
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.
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.
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 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
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.
This is the root of the new create flow!
type: string; | ||
region: string; |
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.
This was a major oversight. type
and region
are the two required values to create a Linode
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.
😮 thx for catching
Did you consider creating a v2 type and not touch at all the existing flow?
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.
We could do that, but I think it's fair to fix the primary type.
<Stack gap={3}> | ||
<Tabs |
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 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.
Coverage Report: ✅ |
<Error /> | ||
<Region /> | ||
<Plan /> | ||
<Summary /> |
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'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
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.
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?
type: string; | ||
region: string; |
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.
😮 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; |
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.
there are new hooks to handle those permissions. useIsResourceRestricted
& useRestrictedGlobalGrantCheck
. am thinking we may want to start/keep using those for consistency
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.
Ahh yes. Thank you! I couldn't remember the names of these!
const { watch } = useFormContext<CreateLinodeRequest>(); | ||
const { field, fieldState } = useController<CreateLinodeRequest>({ | ||
name: 'type', | ||
}); |
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.
this looks like a very useful API - will learn about useController
more
</Notice> | ||
</Paper> | ||
); | ||
}; |
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.
Love it - can formState.errors
be an array of errors?
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 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.
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.
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)}> |
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 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
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 comments @abailly-akamai - This is an amazing start @bnussman and is looking clean! 👍
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.
react-hook-form
🔘Preview 📷
Screen.Recording.2024-03-08.at.3.14.17.PM.mov
How to test 🧪
As an Author I have considered 🤔