bad UX. Just a few issues off the top of my head: 1. Imagine you have a long form and there's an error on a random field. Server-only validation means the user has to wait for the server callback before they get any indication that anything was wrong, and potentially the form state has changed since the submit button was pressed (imagine filling out an address field that uses google maps, etc.). 2. Imagine there's "password," and "password again" inputs. If you do server-side only, you wouldn't be able to return the user's password because it'd be a huge security flaw, so they'd have to reenter password (or any other sensitive data) if ANY other field has issues.
Yeah RHF on its own is pretty cool, but to be honest his example shows how a production ready application form handling would like. Forms in a well structured React apps do look like this usually, whether you are using shadcn components or not.
Partially agree because I had my own inputs using just RHF but I have improved them a lot just by using shadcn form components internally. For example it handles each input id in the recommended React way using the useId hook. It also keeps the internal input control in context and the accesibility props properly setup, which is tedious to implement correctly
The improvement with client side validation isn’t just UX. ideally you should never send dirty data to your server/api. The validation on the server action should be a final step that ideally never fails as the client side validation is ensuring the correct data is sent.
Genuine question - people started using these safe server action wrappers that looks pretty much exactly like tRPC procedures. So at this point, why not just use tRPC? And it comes with react query built in so it manages loading states and caching as well.
You briefly mentioned conform for server validation. But it actually does both the client and server form validation, it does everything you need a form libeary to do and the code will be much cleaner and more concise than RHF on the client and zsa on the server.
But not so long ago you were recommending the next safe action. You change libraries every week. PS. I've tried NSA - it's very crude. Even the author tries to fix all upcoming issues I'm not sure if it's a better approach instead of your own boilerplate
The problem is the React/NEXT community they change there mind every week, never get anything done because they always in the middle of findjng the best way, while the Lavavel/Django dev put 10 sites online 😅
This is why you should always try things yourself and validate libraries on your own. UA-camrs/influencers can show you something interesting, but it's up to you to validate if it works for your use case.
You can still do progressive enhancement with all the client-side bells & whistles RHF provides. You would need to use both the action and onSubmit props on the form element (use e.preventDefault for onSubmit). Two slight issues with this approach 1) the extra formStates in the return useForm object are now wrong and need to be manually implemented 2) Loading states using isSubmitting from RHF or useFormStatus don't work, but I fixed this with a custom hook that is basically the same as the upcoming/beta useActionState react hook. For 99% of use cases this approach should be more good enough. Nice point on the type safety of the server actions, I guess some might overlook the fact that they are still exposed endpoints. I personally used schema.parse from zod to validate my inputs and outputs which worked out pretty well (sending back errors + earlier states as well).
At 4:27 if you use the required attribute aka client side validation won’t it instantly notify the user and to my knowledge the warning goes away when the user starts typing or clicks away? Thus why not use client side validation and server side validation with next actions boom problem solved
I have some server actions in my nextjs app that doesn't really need a form. For example delete. Do i need to create a form around that action on my client button to handle loading states and such. Im currently trying to build a ActionButton that takes a server action as prop, showing a spinner when the action is executing, but i want to show both success message and error messages when done. Should i build all my actions so they return a object of like { message: string, status: 'success' | 'error'}?
Neat. I've done my own back and forth with forms. Now that SolidStart is releasing stable, I wanna figure out whats the best way to make forms in solid.
Hi, I really enjoy learning from your tutorials!👋 Can you please make next.js 15rc + drizzle + lucia + zod + react-hook-form + shadcn lesson. Authorization, registration, double authentication by email code, users browsing the site without authorization and adding/editing entries of an authorized user with Admin role. Thank you very much!!! ❤
any server log should be showing up only in the vscode terminal. If you saw a log from the action show up in the UI, either you were confusing logs or I forgot to add 'use server' at the top of my action
@@WebDevCody Strange, at 11:00 I can see you're using 'use server' at the top and you can see just previous to that the log is coming through in the console on the browser
Not trynna be mean or anything but why would you need to validate your output if your the one writing the output? Like just don't return process.env.API_SECRET right?
because humans make mistakes, and leaking user's emails on accident because you typed return users instead of return users.map(user => user.name) can be a big issue
@@WebDevCody if you type your return types you wouldn't need to install the extra package though? You can also use branded types to make sure that you pass the right string type.
@@BlazeShomida I’d say I’d agree if this was go or another strongly typed language. Typescript I honestly don’t trust the type system. You can return more data than what is typed on an object and typescript won’t complain
3:09 you probably misspoke: "oh wait, you can't, because you can't have a server action defined inside of a useFormState" - what you probably meant to say was that you can't have a server action inside of a client component
I like tanstack form as well but I also feel it's a little verbose and not sure how well it's maintained. Other than that it seems to work just fine. It doesn't seem like a good idea to me to have validation traverse through a server action
@cody what do you think about using client side validation/sanitizer that is instantaneous and on submit validate the Jason that is sent to the server? This accomplishes both, right? Very little client side js is needed to validate your inputs on the client side. WDYT?
1:30 also you can disable html5 validation , i use it a lot to see what i am writing in password input , by changing the type from password to text hahaha
The ergonomics of all the built in React 19 stuff is so bad. The Remix stuff is so much better but I think they're going to embrace server actions too. Might as well go back to API calls at this point
You could use the register from rhf tho, styling your own input component is never that hard. Plus you could use the isPending from tanstack query's mutation to disable the button and show the loading svg inside it. I have worked with loads of forms in my projects. I will be working on a package that uses rhf, tanstack and zod to maximize the dx about these 3 awesome packages
@@BenMargolius if you plan to use RSC, you’ll eventually end up needing to call revalidatePath to trigger next to rerender the component tree. Obviously you could just do all queries and mutations against your tRPc api. I guess ultimately I like server actions and the RSC approach to next.hs
SaaS owners: Would you pay for an AI chatbot that answers new customers' questions, handles marketing, and directs them to the checkout page when they're ready to subscribe?
I've spent forever building a wrapper around shadcn ui + react hook form which fixes the DX You literally just pass and it uses context to pass all the form stuff into the fields Creating the field is as easy as writing Ive been using this internally for the past year and it works very well so I want to publish it as an open source extension of shadcn If you also find the shadcn + react hook form DX to be annoying verbose then id really love to hear your feedback and help in publishing the library I haven't published the code yet because I've been busy with work and not sure how to set up the shadcn like CLI if anyone is able to help with setting up the docs/CLI that would super helpful to publishing all the code for everyone to benefit :)
Ive used shadcn forms with zod before for a project. Yes its very cool to have but man it sucks to write all this code every fucking time you want to create a form. So boring
Coming from a place of ignorance as someone who's never used React and Next and has only ever developed Vue and Nuxt, this looks nightmare-level tedious. Can someone explain why React/Next is better?
In nuxt you’re doing the same thing. You’re defining an api endpoint, then you’re probably validating the user inputs. React will always be more verbose compared to vue because vue uses signals and has the bind directive.
Forms are tricky in general. Slap on the way Next renders pages and the abstractions it provides to avoid writing APIs and you’re in for a ride. But like anything you just get used to it
dangg you summarize my sufferingg trying to work with nextjs forms these week
often times I just throw a required attribute on the inputs, and have zod validate the input on the server. I like the simplicity of that.
shouldn't you also do validation on the server? can't client side validation be spoofed?
@@hyperbrug9328 Yes, you should. That's what he said, validate the input on the server using zod.
bad UX. Just a few issues off the top of my head: 1. Imagine you have a long form and there's an error on a random field. Server-only validation means the user has to wait for the server callback before they get any indication that anything was wrong, and potentially the form state has changed since the submit button was pressed (imagine filling out an address field that uses google maps, etc.). 2. Imagine there's "password," and "password again" inputs. If you do server-side only, you wouldn't be able to return the user's password because it'd be a huge security flaw, so they'd have to reenter password (or any other sensitive data) if ANY other field has issues.
You’re looking at the shadcn forms which is lot more boilerplate than it needs to be. RHF on its own is pretty simple imo
Yeah RHF on its own is pretty cool, but to be honest his example shows how a production ready application form handling would like. Forms in a well structured React apps do look like this usually, whether you are using shadcn components or not.
You’d be surprised. By the time you do it all yourself, the code isn’t much shorter
Partially agree because I had my own inputs using just RHF but I have improved them a lot just by using shadcn form components internally. For example it handles each input id in the recommended React way using the useId hook. It also keeps the internal input control in context and the accesibility props properly setup, which is tedious to implement correctly
@@angelhodar8888 what’s the recommended react way to handle inputs? Also having a context per each FormField may not be the best thing is it not?
The improvement with client side validation isn’t just UX. ideally you should never send dirty data to your server/api.
The validation on the server action should be a final step that ideally never fails as the client side validation is ensuring the correct data is sent.
Hello. I don't understand why you don't use basic zod validation for the server action, and instead use libs like zsa. What am I missing ?
Both approaches work, but using a library reduces the amount of code you need to to type
Genuine question - people started using these safe server action wrappers that looks pretty much exactly like tRPC procedures. So at this point, why not just use tRPC? And it comes with react query built in so it manages loading states and caching as well.
TRPC does not support RSC at the moment. Typing issues.
@@IvanKleshnin It does support it in v11, I've been using it in production for about 6 months now it's pretty stable
@@euanmorgann I see, good to know.
Old good tRPC structure. Didn't found something to move from it yet, just perfect for almost anything
You briefly mentioned conform for server validation. But it actually does both the client and server form validation, it does everything you need a form libeary to do and the code will be much cleaner and more concise than RHF on the client and zsa on the server.
But not so long ago you were recommending the next safe action. You change libraries every week. PS. I've tried NSA - it's very crude. Even the author tries to fix all upcoming issues I'm not sure if it's a better approach instead of your own boilerplate
It’s almost as if he learned new things and found better options.
I'm experimenting and learning new things so that you don't have to
The problem is the React/NEXT community they change there mind every week, never get anything done because they always in the middle of findjng the best way, while the Lavavel/Django dev put 10 sites online 😅
This is why you should always try things yourself and validate libraries on your own. UA-camrs/influencers can show you something interesting, but it's up to you to validate if it works for your use case.
he is not a tech influencer, he is a dev that is learning and documenting it
what is your keyboard setup? sounds so satisfying
I would like to know too
Thank you for the informative clips Cody 👍
Thank you for this video. I know forms aren’t the sexiest bit of web tech but I feel like the form patterns for react ui are in a huge transition.
This is the coolest thing ever! The creator seems very smart!
Your keyboard sounds so yum
You can still do progressive enhancement with all the client-side bells & whistles RHF provides. You would need to use both the action and onSubmit props on the form element (use e.preventDefault for onSubmit). Two slight issues with this approach 1) the extra formStates in the return useForm object are now wrong and need to be manually implemented 2) Loading states using isSubmitting from RHF or useFormStatus don't work, but I fixed this with a custom hook that is basically the same as the upcoming/beta useActionState react hook. For 99% of use cases this approach should be more good enough.
Nice point on the type safety of the server actions, I guess some might overlook the fact that they are still exposed endpoints. I personally used schema.parse from zod to validate my inputs and outputs which worked out pretty well (sending back errors + earlier states as well).
At 4:27 if you use the required attribute aka client side validation won’t it instantly notify the user and to my knowledge the warning goes away when the user starts typing or clicks away? Thus why not use client side validation and server side validation with next actions boom problem solved
Because when you client asks for custom looking client validation that idea goes out the window
@@WebDevCody ahhh i see, makes sense
I have some server actions in my nextjs app that doesn't really need a form. For example delete. Do i need to create a form around that action on my client button to handle loading states and such. Im currently trying to build a ActionButton that takes a server action as prop, showing a spinner when the action is executing, but i want to show both success message and error messages when done. Should i build all my actions so they return a object of like { message: string, status: 'success' | 'error'}?
Neat. I've done my own back and forth with forms. Now that SolidStart is releasing stable, I wanna figure out whats the best way to make forms in solid.
Nice thing here is you can share the zod schema across frontend and backend too
What's the name of the VS Code theme you're using?
bearded theme stained blue
@@WebDevCody Thank you sm!
next-safe-action vs. zsa? What to use?
What Is that theme?
What keyboard do you have?
Hi, I really enjoy learning from your tutorials!👋
Can you please make next.js 15rc + drizzle + lucia + zod + react-hook-form + shadcn lesson. Authorization, registration, double authentication by email code, users browsing the site without authorization and adding/editing entries of an authorized user with Admin role.
Thank you very much!!! ❤
Because that action is ran on the server, how is the log even coming through to the browser at the end?
any server log should be showing up only in the vscode terminal. If you saw a log from the action show up in the UI, either you were confusing logs or I forgot to add 'use server' at the top of my action
@@WebDevCody Strange, at 11:00 I can see you're using 'use server' at the top and you can see just previous to that the log is coming through in the console on the browser
Not trynna be mean or anything but why would you need to validate your output if your the one writing the output? Like just don't return process.env.API_SECRET right?
because humans make mistakes, and leaking user's emails on accident because you typed return users instead of return users.map(user => user.name) can be a big issue
A lot of frameworks use DTO for that reason, you need to transform and send the exact data to the user needs and/or sanitize the output.
@@neociber24 yeah DTO is one approach. Technically zsa uses zod which acts as your dto mapper
@@WebDevCody if you type your return types you wouldn't need to install the extra package though? You can also use branded types to make sure that you pass the right string type.
@@BlazeShomida I’d say I’d agree if this was go or another strongly typed language. Typescript I honestly don’t trust the type system. You can return more data than what is typed on an object and typescript won’t complain
Good job babe!
respectfully asking who are u, i see this comment every time. it is cute btw
@@gerkim62 I am his wife and the mother of his children :)
@@gerkim62 my sexy wife
Which VSCode theme are you using? Looks neat.
Bearded theme stained blue
@@WebDevCody thx man 🙌
I admire your perfect beard growth. Share some tips.
Have you tried hair food😂
the tip is don't shave 😃
@@WebDevCody Well first you need proper growth
@@codinginflow I had done some research on this matter, minoxidil seems to be most effective approach
Current solution: Form Validation & Handling - Maybe rather use React Hook Forms, Zod for validation and ZSA for parsing.
What is the theme you are using?
Bearded theme stained blue I think
Every time I come back to see where forms are at I feel like I should have become a particle physicist instead.
🤣🤣🤣🤣 I feel you
@@YALW0506 haha thank you!
How to get that keyboard sound on windows
Use a physical keyboard instead of the on-screen keyboard
I'd recommend you to check out Mantine and Mantine forms
3:09 you probably misspoke: "oh wait, you can't, because you can't have a server action defined inside of a useFormState" - what you probably meant to say was that you can't have a server action inside of a client component
Yeah probably mispoke
very similiar for next js documentation
What about TanStack Form?
I like tanstack form as well but I also feel it's a little verbose and not sure how well it's maintained. Other than that it seems to work just fine. It doesn't seem like a good idea to me to have validation traverse through a server action
Next-Safe-Action added support for output schemas.
Niceee
@cody what do you think about using client side validation/sanitizer that is instantaneous and on submit validate the Jason that is sent to the server? This accomplishes both, right? Very little client side js is needed to validate your inputs on the client side. WDYT?
1:30 also you can disable html5 validation , i use it a lot to see what i am writing in password input , by changing the type from password to text hahaha
The ergonomics of all the built in React 19 stuff is so bad. The Remix stuff is so much better but I think they're going to embrace server actions too. Might as well go back to API calls at this point
You could use the register from rhf tho, styling your own input component is never that hard. Plus you could use the isPending from tanstack query's mutation to disable the button and show the loading svg inside it. I have worked with loads of forms in my projects. I will be working on a package that uses rhf, tanstack and zod to maximize the dx about these 3 awesome packages
why can't you just use trpc + react hook form?
TRPc doesn’t work with server actions / revalidate path from what I understand
@@WebDevCody Why are sever actions an advantage in this case? Like what do they provide that a tRPC+RHC experience doesn't?
@@BenMargolius if you plan to use RSC, you’ll eventually end up needing to call revalidatePath to trigger next to rerender the component tree. Obviously you could just do all queries and mutations against your tRPc api. I guess ultimately I like server actions and the RSC approach to next.hs
Do a video on AWS Amplify Gen 2, it works like Drizzle+Trpc+SST now and generates forms automatically too based on the data models
SaaS owners: Would you pay for an AI chatbot that answers new customers' questions, handles marketing, and directs them to the checkout page when they're ready to subscribe?
I think a lot of people already built applications like this, so yes I think there is a market for it. It may just be a bit saturated maybe?
@@WebDevCody thank you for your response, it means a lot
I still belive that using html input validation give you the best of the two worlds
I been using react-aria-components, it's nice but the package is heavy AF
src code? thank i needed this advice
Frontend validation for UX, server side validation for correctness.
Why not just use tRPC?
I think tRPc uses a separate api endpoint approach and doesn’t hook into server actions for when calling revalidatePath
I've spent forever building a wrapper around shadcn ui + react hook form which fixes the DX
You literally just pass and it uses context to pass all the form stuff into the fields
Creating the field is as easy as writing
Ive been using this internally for the past year and it works very well so I want to publish it as an open source extension of shadcn
If you also find the shadcn + react hook form DX to be annoying verbose then id really love to hear your feedback and help in publishing the library
I haven't published the code yet because I've been busy with work and not sure how to set up the shadcn like CLI
if anyone is able to help with setting up the docs/CLI that would super helpful to publishing all the code for everyone to benefit :)
That sounds interesting. Send a message if you end up publishing it and maybe I’ll check it out
Ive used shadcn forms with zod before for a project. Yes its very cool to have but man it sucks to write all this code every fucking time you want to create a form. So boring
Coming from a place of ignorance as someone who's never used React and Next and has only ever developed Vue and Nuxt, this looks nightmare-level tedious. Can someone explain why React/Next is better?
In nuxt you’re doing the same thing. You’re defining an api endpoint, then you’re probably validating the user inputs. React will always be more verbose compared to vue because vue uses signals and has the bind directive.
Forms are tricky in general. Slap on the way Next renders pages and the abstractions it provides to avoid writing APIs and you’re in for a ride. But like anything you just get used to it
I'm trying to learn React because of the market share, but yes it's a hell compared to Vue and Svelte, but at the end it's personal preference!!
thanks
You just got my code 😢... The same way am doing in my Next template with tailwind
Imma just stick to zod + react-hook-form.
Nice video, but feels like too much to setup for form imo😅
tldr: react forms still suck