In the last video we tried to assign this current user property to the request object and typescript
is unhappy about that because typescript has a type definition file for express that defines exactly
what a request is and that type definition file says that request does not have a property of current
user.
So we need to somehow augment the definition of what a request is.
That's exactly what we're going to do.
We're going to add in an additional property to the type definition of what a request is.
So let me show you how we're going to do that to get started.
We're not gonna worry about the current user stuff just yet.
Instead I want to go back up to a line right above it whenever we call verify we are going to get back.
If we mouse over payload either a string or an object that's going to be whatever information is stored
inside the on web token.
The first thing we're going to do is apply a more precise definition of exactly what we are getting
back from this verify call.
So remember we are going to get back the payload we had stored inside of our Jason Webb token and as
we recall inside that payload we have an I.D. property that has a string and an email that has a string.
So we're gonna first create an interface that precisely describes exactly what payload is.
So let's do that backup here at the very top of the file.
I'm going to add in a new interface of user payload I'm going to say that this has an I.D. that is a
string and an email that has a string and then going to use this interface and tell typescript that
what we get back out of this verify call is going to be equal to this interface or it's gonna have the
same structure as that interface.
So to do so at the very end of the JWT dot verify line I can write out as user payload
now if I'm also a payload typescript understands Oh okay.
Coming out of that verify call we get back an object that will have an idea that has a string and an
email that is a string so now if we go down to where we have a recurrent user we still have that same
error that says Property current user doesn't exist on there but now we have clarified or at least added
in a little bit more information about what we are trying to assign to that property.
If we mouse over payload we have added in enough information for typescript to understand that we are
trying to assign something of type user payload to recurrent user so now we're going to add in or augment
the definition of what a request object is we're going to tell typescript that it should have a current
user property that can optionally be defined and if we define it it will be of type user payload because
that's what we are trying to assign to it.
Let me show you how we're going to do that.
Once again back up at the top we're going to write out a little bit of mystery code up here.
I say mystery because it's gonna be a little bit strange.
We'll say declare global namespace express interface request and then we will say current user with
the question mark is of type user payload like some.
So this is how we can reach into an existing type definition and make a modification to it.
Notice that we did not have to extend an existing interface or anything like that we did not have to
do that if we ever want to modify an existing interface or add in some new properties to it.
We just write out the same interface same exact name and then we add in whatever properties we want
to augment the existing interface with.
So in this case we are telling typescript that inside of the Express project find the interface of request
that was already defined inside there.
Take that interface that was already created and we want to add in this additional property to it.
So we want to have a property called current user that might be defined.
So it may or may not be defined in the reason it may or may not is because the user might not be logged
in of course but if we do define the current user property on the request object we are going to set
it to type user payload.
Now if we go back down to the bottom we'll see that the air has gone away.
If I mouse over recurrent user we see OK whenever we tried to access current user we're going to get
back either user payload or undefined and that's it OK.
So we've now got this middleware but together anytime a user comes into a route with this current user
middleware being applied to it this thing is going to attempt to find whether or not the user is logged
in if they're not we're just going to continue on in which case current user will be undefined but if
they have a data on a Web token we will try to extract the payload and then set it on current user so
it can be used by our other middle wears or the actual request handler now to actually test this out
going to save the file and go back over to our current user root handler.
Remember we have two different files called current user.
I'm now inside of the root handler called current user so we've essentially moved a lot of the logic
that was inside of here over to that middleware.
Let's import the middleware.
We're going to wired up to this root handler and then we should be able to remove a lot of the logic
inside of here and just rely upon the middleware instead so the very top I'm going to import user from
up one directory.
Middleware is very user than inside of my rep handler.
Right after that you are l I'll put in current user.
So that's my middleware it's now inside the request handler itself.
Well we are doing the check to see whether or not the user is logged in inside the middleware.
So we don't need that.
We are doing the GOP to decode inside the middleware.
So we don't really need that.
We don't need pretty much any of that stuff that's inside there.
All we really need is to take the information off that current user property on request object so we
will just do a resort sense of rec dot current user remember current user is going to be the actual
Jason payload in our previous implementation we had just a moment ago we actually in the response had
a nested objects we sent back an object that said current user id it had a value of whatever the payload
was.
So we should probably just make sure that we keep that same kind of structure right there.
So in other words we're going to end up with an object in here of current user and we'll say recurrent
user.
The other thing that we might want to be concerned about in the version we had just a moment ago the
user was not logged in.
We sent back a current user of No.
Whereas right now if the user is not logged in this is going to be undefined.
So we might want to put in recurrent user or null.
So we don't send back undefined.
Instead we will send back all OK.
So long story short let's say that as is we'll go back over to postman and do a quick test tobacco over
here.
I don't recall whether or not I'm logged in right now.
I think I'm not logged in.
So let's go ahead and send this off my get request to current user looks I'm like I'm not logged in
I'm going to go back over to my tab that allows me to sign into the application I'll send that off.
Now in theory I am logged in if I go back over to their get request tab I'll send that again.
And there we go.
Exact same thing we had previously.
Awesome.
Now the benefit to this Middleware is of course anytime that we have a root handler that needs to know
who the current user is.
Well we'll just make use of this middleware.
Now of course we did define this as a middleware inside of our project but I had said previously that
we are probably going to want to use this for other services inside of our project.
So we probably are going to want to extract this middleware at some point time early somehow figure
out how to reuse it among other services that we create but we will handle that and just a little bit.
So right now let's take a quick break.
We're going to come back the next video and put together our other middleware.