As promised in this video it's going to be up to you to set up an HDTV endpoint for updating a task
by its I.D. similar to what we've done here for users.
That's going to come down below and they'll start us off with some challenge comments describing what
I'd like you to do.
So the goal is to allow for task updates.
We want people to be able to change the description of a task as what they need to do changes.
And obviously we want them to be able to change that completed value to mark a task as either complete
or incomplete.
So step one is to set up the root handler.
Once you have that structure in place you're going to see if there are any unknown updates like we did
up above.
For example if they're trying to update email for a task we should probably let them know that that's
not something they're going to be able to change since the task model doesn't track an email.
Next up you want to attempt to update the task using find by I.D. and update you want to handle the
case where no task is found with that I.D. You want to make sure to handle the validation errors and
finally handle success cases.
Last up test your work.
Fire off the given a request a few different times with both valid and invalid data and make sure you
get the response back that you are expecting.
You can go ahead and knock that or out right here.
Take some time to get that done pause the video and when you're done come back and click play
how that go.
Let's kick things off by setting up the route itself.
We'll be using app dot patch once again and then you are real structure will be the same as what we
had up above for reading an individual task.
We want to update the task by its I.D..
So for me that would be forward slash tasks forward slash colon I.D. then we set up that async function
where we get access to the request and response parameters down below we can focus on what we actually
want to do.
Now the first thing we're going to do is make sure that we're not allowing those unknown updates.
So like we did up above with users we want to make sure to add similar code to validate which updates
are being performed down below.
Let's go ahead and knock that out.
First up I need to know what's being updated.
I'll create the updates array for that and using object keys.
I will convert request dot body from an object to an array of properties.
Next up which properties are you allowed to update.
We could always pull open the task model if we've forgotten we have description and we have completed.
So back over in index dot J S I'll create a new constant I'll call this allowed updates I'll set it
equal to an array of strings.
The first being.
Description.
And the second being completed.
Excellent.
Now as we add more properties or remove them from any given model we can adjust the code here as well.
The next thing we'll go ahead and do is figure out if this is valid or not.
So const is valid operation.
We'll go ahead and once again use updates dot every to figure that out for each individual update is
it included in the array.
So right here we will use allowed updates dot includes and we'll check if the individual update is listed
inside of there.
The last thing we need to do a four step number two is send back the error if it exists.
So right here if it is not a valid operation what do we want to do.
We want to go ahead and send back that 400.
So I'll return.
I'll be using response dot sadness to set the 400 status code.
And like we did for users we can always send an error message back right here sending back an error
property with the text of invalid updates.
Excellent.
Now once we have that in place we can move on to Step number three and actually attempt to update things.
I will use try catch for that.
Making sure that we handle those errors correctly while still being able to take advantage of async
await.
Now right here what we need to do is create a variable for the task so const task equals we'll be using
a wait.
Once again this time though with task dot find by I.D. and update as opposed to user dot find by I.D.
And update now once we have that call in place we have to provide those three arguments we had before.
The first is the idea of the thing we're trying to update for Quest dot parameter dot I.D. contains
that value for us.
It comes from the U R L parameter right here.
Next up the updates we're trying to apply that is request dot body.
And finally those two options we had talked about setting new equal to true and setting run validators
equal to true as well.
Now once we have that call in place we can go ahead and see if we actually found a task to update if
there is no task.
We're gonna go ahead and send back a 4 0 4.
So right here we will use return to stop the function execution.
I'll use response dot status to set up the forum for and send sending nothing back.
But the status response.
Next up if things went well we'll just send the task back response dot send task last up.
If there was some sort of validation error down below we want to make sure to send something back for
that as well right here response dot status.
Setting up a four hundred and sending back the error.
Excellent.
Now that we have this in place we're gonna go ahead and actually test things out.
So we've handled those three cases that we listed under attempt to update the task and the final step
is to test our work.
So I'll remove the challenge comments and bring the code we just wrote back into view.
I'm going to make sure to save the script before heading over to postmen now over in postman.
We will set up the new request and then run it a few different ways.
Over here we have our task app collection.
I'll go ahead and add a new request to that and I'll call this update task now as always the first thing
we need to do is click on that and update the method and the U.R.L. in this case we want to switch over
to patch once again which is the method that we set up to support right here and then back over and
man.
We can go ahead and configure the you are out now to update a task we do need the I.D. of a task that's
actually in our database.
I can always run read tasks to get one right here I'll pull all of the tasks from the database and I'll
just pick the I.D. for one of them.
I'll go ahead and grab this one right here and we'll try to change it from false over to true.
I'll head back over to that request I created and set you are out.
That'll be local host on port three thousand forward slash users.
Excuse me the forward slash tasks forward slash the I.D. that we just copied from the other request.
We also need to provide our updates.
So over here we do have our body will switch over to raw and then we'll switch from text to Jason once
again and we'll go ahead and change that completed value.
So right here I will be setting completed equal to the Boolean true.
Now when I fire this off I would expect a two hundred response which is exactly what I'm getting and
down below I can see the task has changed.
I went from learn the amount goose library having the completed value of false to true.
And now we can go ahead and update other things if we wanted to.
Now we could also try to update something that doesn't exist like completed with 2D.
Let's say we made a typo.
Down below we can see we do get a bad request and we are seeing invalid updates showing up.
So there we go.
We have c r and you for the crud operations.
The last thing we need to be able to do with our H TTP endpoints is D for delete.
I want to be able to delete users and delete their tasks.
We're going to start that process in the next video with users.
So let's go ahead and jump right at.