We've now got a fully functional user model.
I know writing out these interfaces and understanding that generic syntax is really nasty stuff.
But the good news is we really only had to do this the one time.
Now any time we start to create a model in the future it's really just gonna be kind of a copy paste
of what we already did inside of your.
So now that we've got our user model we can get back on track with our sign up process as a reminder.
Anytime someone makes a request to our sign up root handler we're going to first check and see if someone's
already using that email address if they are we will respond with an air after that.
If the email is not in use we will make sure that we store the password with a hash password or the
user with the hash password.
Eventually we will save that user to the database.
Let's go over to our sign up ro handler and start to implement some of the stuff inside my roots directory.
I'll find the sign up dot test file at the very top.
I'm going to immediately import the User model from up one directory models user or me not user model
but just user by itself.
Then go down to my root handler.
Here it is right here.
Now we've got some logic inside of your already around handling request validation.
That stuff is all good and we want to keep it but everything after it was really just some testing code.
So I got delete the console log the throw and the resort sent that entire database connection.
Everything was really just kind of a test.
Anyways we're not going to use that inside the threat handler anymore anyways so I got to delete the
important statement for it.
At the very top of the file and then back down here if we get past that initial request validation step
will then go through this workflow.
So first we need to do is see if a user inside of our database already exists with that same exact email
so to check for that we're really just going to do a query of our user collection and see if someone
has that matching email address.
I'm going to first hold the email off of the wrecked body property I'll then define a new variable called
existing user and I'm going to run a query over my user collection by using the user model.
So I'll say a weight user dot find one with that same exact email address.
If we find another user with this e-mail then that user that we found inside of our database will be
assigned to this variable.
Otherwise if we do not find somewhat that email existing user it will instead be no it's all we really
have to do is check and see if this validly assuming this variable is null if it is.
That means we can create the user.
Otherwise if it is not null then we need to return early and send back in error to the user inside of
you're going to say if existing user is defined
I'll do a console log that says email in use I going to return early.
And right now it's going to send back an empty response.
We don't really have any way to test this just yet because we are not creating any users.
Secondly this as is for just a moment we're going to add in the ability to actually create a user and
then we'll come back and add in some better error handling code inside their OK.
So if we get past that step in theory we need to start to hash the password hash and the password is
a complicated little process and we've been doing a lot of really in-depth stuff.
So right now we're going to very temporarily skip the step and go directly on to creating a new user
and saving them to our database.
So we are going to implement password hashing because you absolutely have to have that.
But very briefly we're just going to skip down to actually create the user so if we get past that step
right there we then need to create our user and save them to the database.
So for that we're going to do a honest user.
And remember how we create a new user document.
We call user dot built and we're gonna pass on the attributes or this user that we're trying to create.
So we'll pass in the email and the password.
We have not defined password inside of here.
Remember password is on the body of the request.
We already did validation on that password.
During this earlier validation step up here so in addition to pulling off email I will also pull off
Astrid so we are building the user just building them does not actually save them to the database to
see them to the database.
We have to do and await user dot save that will persist them too.
Margot D.B. after saving them to the database we should send back to whoever made this request a cookie
or a Jason web token or something.
That's another step that will figure out in just a moment.
Right now let's just respond to this request.
Say that the user was created and sent back the user model or the user documents we'll do a resident
status of two a one which indicates that a record was created as opposed to a two hundred and I'll send
back the entire user case.
This looks at least somewhat reasonable right now.
Let's go ahead and try to do a little test I'm going to open up postman I still have postman open from
when we are working with it earlier.
So I'm making a post request to ticketing that Dev flash API users sign up.
I've got a header of content type application Jason my body is set to raw.
That sounds really awkward.
I've got a valid e-mail a valid password and I've selected Jason over here as well.
I'm gonna go ahead and send in this request all right.
There we go.
So it looks like I have successfully created a user and sent them back to whoever made this request
in this case our postman client.
Now in theory this user has been saved to our Mongo database we can now start to test out the workflow
where we tried to sign up with a duplicated email address.
Let's try to send this exact request once again hopefully we will get back some kind of empty response
that's going to tell us that sorry the user was not created if I tried to send the exact same request
I get back an empty object and if I go to my terminal I'll see a console log right there of email in
use.
All right let's say that this initial flow that we put together looks pretty good but there's definitely
a couple of things we need to fix up we need to make sure that we hash that password.
You'll notice that when we sent a response back when a user was created I'm going to put in a unique
e-mail right here and then send it when we sent the user back the password was included which we definitely
do not want to do and if the email was already in use we are sending back just an empty object which
is not appropriate as well.
There's still a little bit of stuff to work on.
Let's start working on this in the next video.