Parameter & Query Validators

[00:00:00]
>> Speaker 1: That's the validate schema Validate params and validate query are quite literally the same thing The only reason I didn't combine them into one function is so that you can see them three different times, but we could have just combined them into one function and changed just one line, and it would have been fine

[00:00:00]
I want you to see them three times I'm just going to copy that one and paste it and change it from validate body to validate params Validate params is quite literally the same thing, except we're not going to be validating on request.body, we're going to be validating on request.params, and instead of doing a request.body attachment, we're not going to do that at all

[00:00:00]
We're not actually going to attach anything here The reason why we're not attaching anything here is because parameters are always strings no matter what It's not like an object payload that we're pushing up on a POST request where we can modify fields and do stuff and coerce them

[00:00:00]
A parameter in a URL is always a string no matter what you do You can't escape that fact Now, you can take a query parameter and try to parse that out as JSON to do something, and that's what validate query might do, but as far as a parameter is concerned, it's always a string

[00:00:00]
This is why I hate using incremental IDs in my database because I know at some point I'm going to be parsing somewhere to get a number from a string in the URL I hate doing it, so I always try to use UUIDs, which come with their own problems around indexing speed and stuff like that, but I'm aware of those issues

[00:00:00]
So that's validate params For validate query, I'll change the error message to "Invalid params" or whatever you want to put there And for the query, it's quite literally the same thing Validate query, instead of params, is going to do this other thing called query

[00:00:00]
We didn't really talk about query, but query is the same thing you already use in React It's an object with all the query variables as keys, that's it It's literally what it is - key-value pairs We'll do the same thing, and then here we'll say "Invalid query" or whatever you want to put

[00:00:00]
Great Now we have these three helper middleware functions that we can use, and we can stack these For instance, for a route like a delete or post route, we can add validate params because it has an ID, and then validate body for a POST request For params, the way that would work is basically you would pass in params, which is an object with parameters as keys

[00:00:00]
So I could create a complete params schema using Zod, saying it's an ID that's a string This might seem somewhat redundant because Express pretty much guarantees that if somebody passes something in, it's going to be there and it's going to be a string

[00:00:00]
Express might guarantee it's there, but what if I wanted to add a minimum or maximum length Express won't do that In our example, it might seem redundant, but if you get more advanced with validation, it's much better So you can validate and pass the complete params schema, just like we did with the create habit schema

[00:00:00]
If we go back to a POST route for habits and put in an ID, and we want the ID validation to fail, we could add a maximum length of 3 characters Any questions on creating custom middleware We've got local middleware, which is right on the route being used, global middleware at the top of the app, and technically routes are middleware too

[00:00:00]
You might even say controllers are middleware because they have a next function, though I don't recommend using it If you're adding next inside your handler, you've likely written your routes wrong There's always a better way to do what you're doing.