Thank you Ryan, I really appreciate the calm and clear manner with which you teach! I am newer to Zod and I decided instead of fumbling with the API, I'd find some videos to help me understand it from first principles. This definitely helped!
I'm not sure if we can do it in prisma but in drizzle orm you can create zod schema from your models. Add in react hook form and you've basically got end-to-end type safety with your db model as the single source of truth!
@@roguesherlock I recommend that you don’t do this. It’s really important when building scalable applications to create an abstraction layer (your business logic) between your client and your database. You should be able to make changes to your database without touching your client.
That's awesome. I really need to give drizzle a try, how are you liking it? One thing about defining the schema in the action (vs using the database generated zod schema), is that you might have a different form for admins vs non-admins, so you'd want a more restrictive schema for the non-admins. Though having an auto generated schema that you can quickly get access to sounds pretty awesome. I think my next project will use drizzle :)
Awesome video! Working with server actions has been refreshing. I think it's important to note that Zod will throw Errors which will shut down the Node process if they make it to the main event loop. You can prevent this by wrapping dot parse in try/catch or calling the server action with a then/catch chain. This can get pretty verbose. I prefer to use dot safeParse. You can destructure { success, data, error } and handle success and failure accordingly. This makes it convenient to validate forms with Zod and display error messages you've defined in the schema.
One small optimization I'd recommend is to place the definition of the Zod schema outside of that function so memory doesn't need to be reallocated each time the function is called, since the schema will never change over time.
Hi @KoenVerheyen! No specific UI library, but I do use Tailwind to style everything. Here's a twitter thread on how I built the submit button: twitter.com/ryantotweets/status/1676625909351153671
That's a topic deserves a whole other video :) Basic idea you pass the server action into a client component that invokes the action and keeps track of any errors it returns. If it errors then the client component can set state displaying those errors.
Thank you Ryan, I really appreciate the calm and clear manner with which you teach! I am newer to Zod and I decided instead of fumbling with the API, I'd find some videos to help me understand it from first principles. This definitely helped!
Great to hear!
Awesome content Ryan. Please bring more of these.
Simply amazing content.
Thanks so much!
If you use react-hook-form with the zod resolver you can share the schema on the frontend and backend.
Awesome! That's great to know
I'm not sure if we can do it in prisma but in drizzle orm you can create zod schema from your models. Add in react hook form and you've basically got end-to-end type safety with your db model as the single source of truth!
@@roguesherlock I recommend that you don’t do this. It’s really important when building scalable applications to create an abstraction layer (your business logic) between your client and your database. You should be able to make changes to your database without touching your client.
@@grunklejp yeah probably. It's mostly for small stuff where you have a tight control over your inputs and outputs.
That's awesome. I really need to give drizzle a try, how are you liking it?
One thing about defining the schema in the action (vs using the database generated zod schema), is that you might have a different form for admins vs non-admins, so you'd want a more restrictive schema for the non-admins.
Though having an auto generated schema that you can quickly get access to sounds pretty awesome. I think my next project will use drizzle :)
Awesome video! Working with server actions has been refreshing.
I think it's important to note that Zod will throw Errors which will shut down the Node process if they make it to the main event loop. You can prevent this by wrapping dot parse in try/catch or calling the server action with a then/catch chain.
This can get pretty verbose. I prefer to use dot safeParse. You can destructure { success, data, error } and handle success and failure accordingly. This makes it convenient to validate forms with Zod and display error messages you've defined in the schema.
Awesome, great advice!
You can put a + in front of the value to convert the form.id to a string. Exp: +form.id. It will be shorter.🙂
Great video, clear and comprehensive. Thanks!
Great explanation thanks for making this.
Thank you!
One small optimization I'd recommend is to place the definition of the Zod schema outside of that function so memory doesn't need to be reallocated each time the function is called, since the schema will never change over time.
awesome, code is so cleannnn
either use try catch or use safeparse incase if empty input avoid page error. nice video 3>
Thank you so much
Are you using a specific UI library? The loading button is cool!
Hi @KoenVerheyen! No specific UI library, but I do use Tailwind to style everything. Here's a twitter thread on how I built the submit button: twitter.com/ryantotweets/status/1676625909351153671
How do you show errors to the UI so the users can fix?
That's a topic deserves a whole other video :)
Basic idea you pass the server action into a client component that invokes the action and keeps track of any errors it returns. If it errors then the client component can set state displaying those errors.
@@RyanToronto that sounds like a great follow up video as I’m trying to wrap my head around it! Thanks!!
What i am missing, and was hoping to see in this video, is error handling with zod and displaying the error messages client side.
That's coming up in a future video!
I think you can parse the id as number directly with zod.
z.coerce.number()
Mano tu parece o Jim do the office tlg?
Doing db operations without any proxy is hella raw and insecure. Why not use a rest endpoint to handle all that stuff?
How about validations with zod?