[React, TS, Formik + Yup, Vite, styled] Multi Step Form
Design comparison
Solution retrospective
First, I made a custom input mask for a phone number without resorting to ready-made solutions from libraries. I also tried my hand at working with regular expressions.
Second, I worked firstly with multi-step forms. I wrote a custom hook for indexing and transition to other pages.
When the challenge was coming to an end, I found out that in the Formik repository in the examples
folder, there are several more multi-step form implementations. And you can't find these examples on the official docs page. Ah, how I wish I had this information earlier. :,)
The difficulties were with the input mask, with regular expressions, with validation of each page as you move through the form. It turned out that Formik supports hot-swapping of validation schemes, so I solved this problem.
What specific areas of your project would you like help with?In my implementation inside the render of the MultiStepForm component, I use Formik, which follows the construct:
{(formikProps) => ( MultiStepFormFields {...formikProps} currentStepIndex={currentStepIndex} goTo={goTo} next={next} back={back} pagesCount={pagesCount} )}
I would certainly prefer to pass MultiStepFormFields only as a prop component
in Formik and not clutter up extra lines of code. I ended up limiting myself with my custom hook, now the page index has to be passed from component to component. I came across another implementation in YouTube that seems to get rid of this limitation. But I'm running out of time to try it, should move next.
Community feedback
- @dylan-dot-cPosted 16 days ago
Well done completing this challenge!
In terms of design most things look alright.
I noticed a few things that could be better
- I'm using MSedge and it seems like on some containers there are some disabled scrollbars all over the form, some are at the labels and the summary container, it could be the overflow scroll you have there and I must ask why. Anyways you could set it to overflow auto so it will only show the scrollbar when there is actually more content there to scroll.
- I see you made the button disabled before the form has been filled out, nothing is wrong and I don't know which is better, pressing the button and seeing required errors or seeing a disabled button and trying to figure out why it's disabled(take it with a grain of salt cause I'm not good enough either way)
- I made this mistake on my solution and I have yet to fixed it(too lazy) but when they reach the summary page, the change button could just automatically change the plan instead of having the user doing it manually.
Other than that everything seems to be alright
I also did this challenge with React, Zustand, TS, TailwindCSS and framer motion, I would appreciate it if you could check it out. I haven't used formik or yup before and I try to stay on a low level of abstraction for some of these challenges as it helps you to figure out how some of these work on a lower level
Anyways take care
1@ErazorWhitePosted 16 days ago@dylan-dot-c thank you for such a detailed review.
some containers there are some disabled scrollbars...
As for the disabled scroll in my solution. I use
overflow: hidden;
in very few places. On the buttons, I decided to disable scroll because the buttons themselves have a margin of their "rubberiness" for expansion. Of course, if you overflow a button very much, part of the text will be invisible inside the button. But you have to turn off common sense to achieve that. I decided that scroll would only make things worse because when you try to click a button you will just scroll text in it.I also applied
overflow-y: hidden;
to the header on each page. If you fill the header with a stream of characters with no spaces, you will be able to scroll horizontally. If you overfill it with text with spaces, the text will simply wrap over to the next line and the scroll will never appear. In the extreme case, the form itself will simply stretch along the vertical axis and then the browser itself will provide you with a vertical scroll for the whole form. So there is nothing to worry about here either.I also disabled scroll on elements with the .visually-hidden class, no need for comments here, I guess. These elements should be invisible.
Scroll is disabled on styled-component called CheckmarkIconWrapperOuter. This component is needed to render the icon on the
Thank You!
page, so an overflow is hardly possible in this scenario.In all other places, scrolling is enabled by default. I've run overflow tests and generally, all content is displayed within reason.
I see you made the button disabled
Yes, I decided to do that only because I didn't find on the figma layout what the validation errors should look like on the second page with plan selection. What should happen if we don't select a plan, click the "next" button and what should it look like? The designer didn't foresee this behavior, so I just turned off the button until the form was validated successfully.
change button could just automatically change the plan instead of having the user doing it manually
Perhaps this behavior is described somewhere in the README of this challenge, but I found it easier to just send the user to the plan selection page to change their mind if they want it. If this button would change the choice between the two options offered, I'd probably make the plan switch automatically on click.
Thank you again for your feedback, I'd love to see how you solved this challenge.
Take care
0
Please log in to post a comment
Log in with GitHubJoin our Discord community
Join thousands of Frontend Mentor community members taking the challenges, sharing resources, helping each other, and chatting about all things front-end!
Join our Discord