All right.
And once are all middleware functionality is complete.
Next, I want to work in the update user where essentially we're going to be looking for four properties
in the body.
And I'll cover this one in more detail once we actually start setting us up.
Essentially, what I'm looking for for.
What if one of them is missing?
We're going to go with police, provide of ours pretty much like we did in the logging one and the register
one, I believe, as well.
And then in here, we want to go with find one.
So that's the method.
And on the user, I'm going to check for any user who's I.D. matches that of the wreck user and then
user already.
So I showed you in the last video that we have Rick user and I'll simply grab the user whose I.D. matches.
And then one by one, I'll update the property of ours.
So email all the way to location, and then we'll use the instant method that is available on all the
documents.
And that one is dot save.
And some say there's a synchronous.
We go with 08, so we get back our instance.
And then I just call user Darksaber and I'm purposely not using, for example, find one by ID and update
and all that because I want to show guys how this one will trigger, not preach, save hook we already
set up in the user model.
And as a result, there's actually going to be an error when we try to update our user info with our
current set up.
But don't worry in next video we'll fix it.
And then we have this interesting question.
Now do we need to create another JWT?
Like we did already in the register and log in one.
Well, let's take a look.
So in the user model, what are we passing in here?
We're passing in as far as the payload just user.
Correct.
Now are we changing any of these hours over here?
Are we changing the I.D. in this list?
And the answer is no.
So this is really up to you as far as the required.
No, it's not required.
You can technically just send back the user and location.
So essentially, those are the two things that we are potentially changing here.
Now, as far as my preference, I still prefer setting up token from the scratch because I like the
fact that now I set up a new expiration.
Keep in mind that since we're building this project together, I will be expecting this on a frontend.
So yes, this is the case where as far as why we're building this project, you will have to send back
the token just like me.
Otherwise you'll have the box.
But.
When it comes to your own project, remember that technically you don't have to.
So if you were changing some properties that you're setting up here in the token, when you're setting
up the payload, then yes, it's a very, very, very good idea to issue a new token simply because
otherwise you'll have this token that has some old data.
But in this case, technically it is optional, but it's still my preference to issue that new token.
So let's get cracking, and I want to start here in the off controller.
I want to get my update user.
And yes, I will discuss why I'm looking for all four properties, so I'm going to go here to email,
then name one last name and then also a location.
And all of that is coming from Rick and body.
So that is coming in.
What's next?
Well, let's quickly check whether we have all the values and in this case, our email and password
now.
We're not going to be checking for password because this is not update password that is very, very
important.
I simply want to look for name, email as well as the last name and location.
And if one of them is missing, then we throw the error.
So let's add another or and we're looking for the location.
Now you're probably wondering, OK, well, if last name and location are not required and we right
away have some default values?
Well, why are we sending this up?
Well, let's take a look at the user model.
Let's keep on scrolling.
Yep.
So name is required and the same goes for email password again.
We're not updating the password, but it's important to mention that.
But then when it comes to last name and location, we already have them as defaults.
And again, it really comes down to my preference, where essentially if the user is trying to submit
the empty form value were already right away, this play the alert where say, Hey, listen, please
provide all the values.
And since we're doing that already on front end, I might as well do the same thing on the back end
then.
Is that a big deal gnome?
But that is at least my preference.
And just to give you another hand, technically if this is empty.
The request won't come in here anyway, because we will right away stop it on the front end.
So then we want to grab the user who's I.D. matches.
So we're going to go here with concert.
I get the user now that is equal to weight and then we go with a user and then find one.
And then let's take a look at the user who ID.
So underscore karate matches, rec user and then user I.D. So once I get the user now one by one, I'll
update those values, so I get back my object.
Now I just want to go user email, not as equal to an email.
Then we can copy and paste and we can right away set up architectures.
And in this case, we're looking for the name again.
Copy and paste.
If we want to go for last name, I believe that was my property value and then the last one will be
location.
So we provide all of the values we update and then remember, we are going to go with user or not say,
serve the user.
Now I'm not going to go over the various set ups again.
I hope that I convey that message in the very beginning, and let's create a new token.
So I'm going to go token, then user, then create and create the waiting time was the function and
then let's send the response.
And since I already have pretty much everything set up here, minus we'll copy this line of code and
just be disabled, but where I'm going to remove the console.log and allow the user token location,
as well as the user location.
And then this is the case where remember, password is select false.
So if everything is correct?
The password shouldn't be here in the user object.
So let's test everything out.
Where I'm going to navigate back to my postman before I do anything, I just want to make sure that
I have the valid token.
And then let's come up with whatever updates we want to make.
And in order again, to speed this up, I'll just grab the name, email, last name and location and
we'll just change one.
So we're going to go to update.
User authorization is in place and we want to go with body roar and we're looking for Jason.
What's the object?
Let's set up the properties, and let's say that I'll change my name to a beta.
So let's send it here.
And once we send, like I just said, we're going to get back the error.
So we'll discuss that error in more detail in next video.
For now, simply what I want you to do is go to the user schema where we have this pretty safe, OK,
and just comment these two stickers out.
So these two lines of code and I'll discuss everything in greater detail in the next video.
And then once we do that now, once we send, check it out.
First, we successfully updated the user.
So we went from named John to a name beta and second notice how in our response, we don't have the
password.
So that underscores something that I have been pretty much repeating for many, many videos that if
we go with password and we set it equal to select false, what is going to happen when we use, for
example, query find one, the password won't be returned.
Hopefully this makes sense.
And then now we can start working on the modified Barth's functionality.
And essentially, we'll take a look at why we got back this error where we were sending the initial
request.