All right.
I don't know whether you remember or not, but some time ago I showcased that we can have two potential
errors when it comes to IDs in parameter.
So, for example, if we have the same syntax but a wrong value, basically the product doesn't exist
in our database or in our case I guess more correctly job, then we get back 404.
Now if we provide invalid syntax, then we get different type of error from the MongoDB.
And this is something that essentially we want to fix.
So we will create another validation middleware.
In this case I'm going to call this validate ID param and in the process we'll cover how to validate
parameters with express Validator.
First, let's navigate to.
Our middleware.
We're looking for validation middleware and if we want to access the values in the body.
Of course we're looking for the body helper, but if we want to get the value from params, we want
to go with params.
So it starts with import.
Yes, those are two different places.
So if we want to validate the params we want to go with params.
So that's the first thing we want to import.
Then let's set up our middleware and honestly most of it is going to be exactly the same, but we'll
just take it to the next level and we'll essentially set up a custom function.
So what am I talking about?
First of all, let's come up with a name.
I'm going to go with validate ID param.
So same deal.
We want to go with validation errors and in here.
We want to pass in what we want to validate.
So first of all, since we have access to parameters instead of body, we're going to go with parameters.
Now, remember the name.
This is very, very important With me, navigate to routes.
What is the name of the parameter?
It's an ID.
Correct.
So it needs to match.
So of course, in here we're going to go with ID and then we have this custom function.
So if we want to access the actual value of the ID that's coming in with the request, we simply pass
in the callback function and then whatever we name the parameter.
So in my case, I'm going to go with value and depending on what we return from the function, either
the request is going to be validated.
So basically we will pass it on to the next middleware, in our case the controller, or we're going
to reject it and we can simply test it out with, let's say, return and let's go with true for now.
Yes, eventually, of course, we'll set up a more complex logic.
But for now I just want to showcase how it works.
And then if there's some kind of error, the message I want to use is following.
I'm just going to say invalid mongo.
The B ID, let's save it.
And now let's navigate to our job router and let's import it.
Correct.
So now we have first middleware and the second one is going to be validate ID param.
So which controllers are using it?
So which routes are using the ID?
Well this one get job update, job and delete job.
So in here, let's go to the first one.
Let's add a comma and then let's look for our validate ID param.
Then we want to set up the same one for update job and of course also for delete job.
Let's save it and let's test it out right now.
So I'm going to send it over here and once we make the request, we can nicely see that we're getting
the correct response from the controller.
So that means that this validation works.
Essentially, if we return true, we're not kicking back the request.
However, if I'm going to change this around and if I'm going to go with false.
Now check it out.
Same request I send and I get back invalid MongoDB.
Again, this just demonstrates that if we return false then we right away.
Invoke this whole validation setup.
So essentially we'll send back the error with invalid MongoDB.
Now if we return true, then everything is going to be correct.
So how we can validate whether it is a valid MongoDB ID?
Well, first of all, we'll need Mongoose.
So we will import Mongoose from Mongoose.
Then let's keep on moving.
And essentially, I can set up the implicit return.
And we want to go here with mangoes, then dot types, then object ID and it has a method of is valid.
So this is going to return either true or false.
And of course the way I access the actual ID is over here.
So if this returns true, then everything is fine.
We pass it on to controller.
If not, if it returns false, then you'll see the error message.
So now let's try it out.
I'm going to first grab the correct ID, So let me navigate right now back to my thunder client.
Get all jobs.
And here, let's send it one more time.
I think I'm going to mess with the coding addict.
At least I'm going to test the coding addict, then get single job.
Let me send it here.
Yeah, everything is correct.
So if I'm going to just mess with the values but keep the syntax the same.
So this is coming from our controller.
We're going to go with 404.
But if I'll start removing the values or adding some extra characters, you'll notice something interesting.
So now we have this bad request, which is exactly what I was expecting.
So if you want to test the params, you want to go with param and also whether it's a value in the body
or param, you can go with your own custom function and just remember if the return is going to be true,
everything is going to be fine.
It's going to be passed on to the controller or to the next middleware.
But if the result of this functionality is going to be false, then of course server is going to send
back the error response.