Hello, hello. So FormKit just came out with this brand new plugin to support Zod validation with FormKit Forms. And I just had to add on this bonus video to the course in order to show you how it works. It's a really, really cool feature app.
So first of all, what is Zod? Well, this is a popular TypeScript first schema validation library. And if you aren't already familiar with Zod, we aren't going to go through the details of it in this video, but I encourage you to check out a link in the description below to the Zod documentation. Essentially, it's the go-to way of validating data in JavaScript.
And it comes with static type inference out of the box, so you don't have to define your validations along with separate TypeScript interfaces. It generates those interfaces for you. Okay, awesome. So how does this work in FormKit?
Well, I have a project set up in StackBlitz here that is based around Nuxt. It's basically a brand new Nuxt project, but I have the FormKit Nuxt module installed as well as the Zod plugin for FormKit installed and Zod itself. view where we can find the code that generates this form right over here that is being validated. by Zod.
Great. So down here in the template you can see that we have a form kit form and the plugins prop is set to an array with a single Zod plugin inside of it. Inside the form itself we have a form kit group set up here so we can nest first name and last name fields under a personal info key in the resulting data. Then we have an email field as well as a checkbox where we have several different options specified.
Up in the script section, the first thing I'm doing is importing Create Zod plugin from AppFormKit Zod. So that's why we had to make sure we actually install the plugin. That's where this Create Zod plugin function comes from. Then just here below, we're using the Create Zod plugin function in order to get the Zod plugin that we're passing into the form.
Okay, so that's where the plugin comes into play. But what else is going on? How are we actually defining our validation? Well, that's where ZOD itself comes in.
Here on line three, I'm importing Z from ZOD, and then I'm creating what's known as a ZOD schema. Okay, this basically defines the shape of the data that I want to validate. What I'm saying here is that This payload that comes out of the form should be an object. It should have a key of personal info, which is also an object, that has the keys first name and last name, both of which are strings and have a min and max length.
Also, this payload should have an email property, which is a valid email, and an array min property, which is an array of strings, and there should be at least two items within that array. All this is being captured in a variable called MyFormSchema, and then we're passing MyFormSchema to the CreateZodPlugin function below. So this is how we're connecting our Zod schema to our FormKit form. The schema is being passed in to CreatePlugin, CreatePlugin produces the ZodPlugin, and the ZodPlugin is passed to the form.
Excellent. But what does this other thing return from the CreateZodPlugin function? Well, this is the submit handler that we want to call whenever the form is submitted, and it will only ever run when the data is valid. The definition of that submit handler is found right here as the second argument of the Create Zod plugin.
It receives the validated data from the form, and then we can do whatever we want with it. The big question is, what makes this any different than the built-in validation for FormKit that we learned about earlier? Well, the key is that now we can specify a single Zod schema and use it both on the front end for a very quick snappy user experience in terms of telling them what's wrong with their form. But then we can also use this exact same schema definition on the backend.
And as any backend developer knows, we can't rely on data from the front end, right? We still need to make sure we're doing validation on the backend as well. So what would that look like in Nuxt? How can I take this Zod schema and apply it to both the front end and the back end?
Well over in my file structure, I've already created a folder called Zod. This was totally just a made-up naming convention. You could call this whatever you'd like. ts file.
View. On line 3, I'm exporting it so that we can reuse this module in multiple places. Great. ts file.
Awesome. If I come over here to the right-hand side and try to submit my form, indeed it works just like before. Now though, I can reuse this schema in multiple places. ts file.
If you're unfamiliar with how API endpoints work in Nuxt 3, essentially this is just a quick way to create a function that runs on the server side, and not on the client. Great. Inside here you see I'm importing the exact same schema that I imported and used on the front end. parse in order to get the validated data from the body.
So the return of this is valid data. However, if the data sent in with the request is not valid and does not adhere to the ZOD schema, then we get an error thrown. That error will be an instance of a ZOD error. And if that's the case, we want to throw the status code for invalid data, which is 422.
I believe the technical term is unprocessable entity, but it's a status code commonly used to mean the data you send in is no good. So there you have it. We were able to define our validation in one single place and use it on both the back end and the front end. This is absolutely amazing to me.
I won't take up your time during this video, but in order to prove that the validation is in fact working on the back end, I've left a link to another StackBlitz in the description below so that you can easily test that out. And let me tell you, it works like a charm. All of this is made very simple and possible by the Zod plugin for Formkit. And if you'd like more information on it, I've left a link to the official plugin docs in the description below.
Hello, hello. So FormKit just came out with this brand new plugin to support Zod validation with FormKit Forms. And I just had to add on this bonus video to the course in order to show you how it works. It's a really, really cool feature app.
So first of all, what is Zod? Well, this is a popular TypeScript first schema validation library. And if you aren't already familiar with Zod, we aren't going to go through the details of it in this video, but I encourage you to check out a link in the description below to the Zod documentation. Essentially, it's the go-to way of validating data in JavaScript.
And it comes with static type inference out of the box, so you don't have to define your validations along with separate TypeScript interfaces. It generates those interfaces for you. Okay, awesome. So how does this work in FormKit?
Well, I have a project set up in StackBlitz here that is based around Nuxt. It's basically a brand new Nuxt project, but I have the FormKit Nuxt module installed as well as the Zod plugin for FormKit installed and Zod itself. view where we can find the code that generates this form right over here that is being validated. by Zod.
Great. So down here in the template you can see that we have a form kit form and the plugins prop is set to an array with a single Zod plugin inside of it. Inside the form itself we have a form kit group set up here so we can nest first name and last name fields under a personal info key in the resulting data. Then we have an email field as well as a checkbox where we have several different options specified.
Up in the script section, the first thing I'm doing is importing Create Zod plugin from AppFormKit Zod. So that's why we had to make sure we actually install the plugin. That's where this Create Zod plugin function comes from. Then just here below, we're using the Create Zod plugin function in order to get the Zod plugin that we're passing into the form.
Okay, so that's where the plugin comes into play. But what else is going on? How are we actually defining our validation? Well, that's where ZOD itself comes in.
Here on line three, I'm importing Z from ZOD, and then I'm creating what's known as a ZOD schema. Okay, this basically defines the shape of the data that I want to validate. What I'm saying here is that This payload that comes out of the form should be an object. It should have a key of personal info, which is also an object, that has the keys first name and last name, both of which are strings and have a min and max length.
Also, this payload should have an email property, which is a valid email, and an array min property, which is an array of strings, and there should be at least two items within that array. All this is being captured in a variable called MyFormSchema, and then we're passing MyFormSchema to the CreateZodPlugin function below. So this is how we're connecting our Zod schema to our FormKit form. The schema is being passed in to CreatePlugin, CreatePlugin produces the ZodPlugin, and the ZodPlugin is passed to the form.
Excellent. But what does this other thing return from the CreateZodPlugin function? Well, this is the submit handler that we want to call whenever the form is submitted, and it will only ever run when the data is valid. The definition of that submit handler is found right here as the second argument of the Create Zod plugin.
It receives the validated data from the form, and then we can do whatever we want with it. The big question is, what makes this any different than the built-in validation for FormKit that we learned about earlier? Well, the key is that now we can specify a single Zod schema and use it both on the front end for a very quick snappy user experience in terms of telling them what's wrong with their form. But then we can also use this exact same schema definition on the backend.
And as any backend developer knows, we can't rely on data from the front end, right? We still need to make sure we're doing validation on the backend as well. So what would that look like in Nuxt? How can I take this Zod schema and apply it to both the front end and the back end?
Well over in my file structure, I've already created a folder called Zod. This was totally just a made-up naming convention. You could call this whatever you'd like. ts file.
View. On line 3, I'm exporting it so that we can reuse this module in multiple places. Great. ts file.
Awesome. If I come over here to the right-hand side and try to submit my form, indeed it works just like before. Now though, I can reuse this schema in multiple places. ts file.
If you're unfamiliar with how API endpoints work in Nuxt 3, essentially this is just a quick way to create a function that runs on the server side, and not on the client. Great. Inside here you see I'm importing the exact same schema that I imported and used on the front end. parse in order to get the validated data from the body.
So the return of this is valid data. However, if the data sent in with the request is not valid and does not adhere to the ZOD schema, then we get an error thrown. That error will be an instance of a ZOD error. And if that's the case, we want to throw the status code for invalid data, which is 422.
I believe the technical term is unprocessable entity, but it's a status code commonly used to mean the data you send in is no good. So there you have it. We were able to define our validation in one single place and use it on both the back end and the front end. This is absolutely amazing to me.
I won't take up your time during this video, but in order to prove that the validation is in fact working on the back end, I've left a link to another StackBlitz in the description below so that you can easily test that out. And let me tell you, it works like a charm. All of this is made very simple and possible by the Zod plugin for Formkit. And if you'd like more information on it, I've left a link to the official plugin docs in the description below.