feat: [M3-7806] - Linode Create Refactor - Part 1#10268
feat: [M3-7806] - Linode Create Refactor - Part 1#10268bnussman-akamai merged 8 commits intolinode:developfrom
Conversation
There was a problem hiding this comment.
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.
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.
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.
I still feel like this could go in its own PR, but if not, can we at least get two changesets?
- one
upcomingfor v2 refactor - one
changefor APIv4
There was a problem hiding this comment.
This is the root of the new create flow!
| type: string; | ||
| region: string; |
There was a problem hiding this comment.
This was a major oversight. type and region are the two required values to create a Linode
There was a problem hiding this comment.
😮 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.
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.
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.
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
abailly-akamai
left a comment
There was a problem hiding this comment.
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.
😮 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.
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.
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.
this looks like a very useful API - will learn about useController more
| </Notice> | ||
| </Paper> | ||
| ); | ||
| }; |
There was a problem hiding this comment.
Love it - can formState.errors be an array of errors?
There was a problem hiding this comment.
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.
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.
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
jaalah-akamai
left a comment
There was a problem hiding this comment.
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 🤔