Optional, Nullable, & Coercion

[00:00:00]
>> Steve Kinney: Um, so now we have this post schema, and when whatever comes in here, right, let's call it possible post. I can say return Post schema dot parse Possible post. And just to make a point, I'm going to save it to a variable so you can see some, you don't have to do this, uh, and I'll return the post. And now, this was any, I sent it through the schema. We know for a fact that it is an object that has an ID that is a number, a title that is a string, and a body that is a string.

[00:00:47]
Otherwise this will throw. Right? And like throwing errors, not to like sound like the Primeogen or anything like that, throwing errors, we all think is a bad thing. Throwing errors and catching the error when you meant to instead of like trying to put like if is undefined all throughout your codebase is not the worst thing in the world cause like, it wasn't what you expected, you should do with that early on.

[00:01:12]
Um, and so now it will throw, we can have an error boundary around that component. We can do some other fun stuff. Um, but we can now make sure at this point, from the earliest point, we know. In fact, I could even get rid of this. Right? It's still the type, I think, because like we validated that it was, right? And we can even, you can kind of do this in two different ways, and I'll show you both really like the answer is it depends on which one came first.

[00:01:46]
If we wanted to say, hey, I'm going to make a post schema, and then, um, I wanted to make the post type off of that schema, so we'll get rid of that for a second. I can do type post equals z.infer, and this is why I end up using types because like, it's a little bit tricky to do it with an interface, uh, type of post schema. So basically, the z.infer is a utility type that will take the type of this post schema and give me back the same post type.

[00:02:24]
Right, so now these are kind of like tied with each other, and like now that's the type I'm using here, and I know from the outside world that this will always now be a post, or it will have thrown pretty early on. And I'll show you some other tricks you can do with this in a second. But this is incredibly powerful because now I have both compile time safety and I also have runtime safety. Right, if I get in data types that are not what I think, I no longer have to, you know, I never have to worry, like I can get rid of this ever, like.

[00:02:59]
You still don't have the value at this point, so it's got to be something. The thing you can do here is like you could theoretically make like an empty post and then like, show a loading state, but I at least do know that like this will always actually be a post, cause like, this thing could have sent back like, uh, like a 404 webpage of like HTML as a string, and then we would have tried to like JSON parse it and like it would have been a mess.

[00:03:26]
Uh, we will know that it's a post and I'll show you some. We'll get rid of this in a second too, right? But the Zod schemas are incredibly powerful. Let's say hypothetically, you had the post type already, and you wanted to make sure that you were making a Zod schema that matched that, cause you know, you're still hoping that like, I didn't mess up with this Zod schema, right? So remember how we imported posts before?

[00:03:55]
Uh, so we'll import it again. If we wanted to make sure that we were making a schema that would legit be the type that we thought it was, we could also do, um, hey, this should satisfy. Except you gotta spell satisfies, right? Right, that this satisfies z.ZodType of post, right, that's just another utility type. And so then if for some reason I decided this was number. Like, why? I don't know. Uh, it no longer satisfies that.

[00:04:36]
So if you start, if you have the type already, and you're trying to make schemas that validate the type, this will at least make sure that they do correctly match each other. If you start with the schema and you wanted to infer a type from it, you can do that as well. The correct answer is, what one do you have currently? Right. Or like, and you can kind of go both ways, right, and figure it out from there.

[00:05:02]
But there's a bunch of other incredibly useful, um, things you can do with these Zod schemas, right? This was a pretty simple object. I'm going to take away this satisfies for a second just to kind of show you some of the things that you can do. Um, because this is also incredibly powerful for form validation, right? Because that's another place where you are getting stuff from the outside world that may not be what you think it is.

[00:05:28]
And you can do a lot of stuff in the input fields, like, uh, make sure it validates to a pattern, but still, you don't know that that value is what you think it is in your code, right? Um, so you can use this for form validation, you can use this for API requests, you can use this for local storage, right? Like you're hoping when you do like local storage.set and use an object that like that's what you get when you get it back out.

[00:05:57]
And luck, sure, but you don't control that environment. So having Zod schemas is anytime you are touching something that is like outside of your actual codebase, then enforces the fact that it is what you think it is and saves you so much headache. But let's look at some other features as well. Um, and I'm going to go back and do it the other way so we can see how the type shoots out the other end.

[00:06:27]
Um, so we'll say that, uh, type post in this case is going to be z.infer type of post. Uh, oh, post schema. The one question that I will not answer. You're going to ask me, is, should you capitalize like this or do it like that? I have done it both ways, and I don't, I haven't decided which way I like more. So I don't know. I, today I like this. In some codebases I've gone the other way. It's my worst habit, so.