Hey, did everyone had a shower?
And welcome to another new section.
Now, in this section, we are going to focus purely on the users and will create some models of it,
some of the pre functions for it, some hooks for it, controllers routes and all about the users that
we need to do.
Let's go ahead and get started with that.
For that, obviously, we'll go into the models first.
So let's go up there and inside the model.
We need to create a simple file.
So we are calling it as models.
Let's right click and click on the new file and this one is going to be simple user.
So call it with the uppercase or lowercase, doesn't really matter.
It's your personal preference, but make sure you are consistent around that.
And once we are done with that, this is the section where we are going to also learn a bit about the
validator and its use case as well.
So first, let's go ahead and bring in the mongoose because that is going to be the main structure that
will help us to do almost everything.
So we're going to say, Hey, Mongoose, please come in by saying, Hey, Mongoose, just require the
mongoose.
There we go.
Since we'll be using the validator, it's good that we bring it up here.
I'll show you how to use that.
It's really, really simple.
Once you see that at one time, it is going to be super easy for you after after every single time after
that.
So Validator is going to be coming up from require validator.
Okay.
Now how do we do that?
The basic we have already seen it one time.
So this is going to be a nice revision for you.
So let's call this one as user schema.
This is kind of a good practice that whatever you are naming your file, just add a schema after that.
And at the very end of it, import time, we just properly name that.
So that's how we do it.
And we are going to go ahead and say, Hey, Mongoose, give me a method that says a schema.
And in the schema we go ahead and write all the schema.
So this is the basics of it.
Now once you are done with that, what are the things that you need to write after that?
At the very end of it, we always go ahead and export the schema.
So we're going to say module dot x sports.
That is going to be equal to mongoose dot model.
So Mongoose will take this schema and convert it into a model.
So how is it going to do it?
We usually write this as uppercase user.
This is just our own personal preferences.
Mongoose doesn't actually follow too much there, and we have to provide what schema to follow for this
particular model, which is user schema.
Now again mentioning this, although we have discussed this quite a lot in the past as well, that Mongoose
will actually take this user will convert it into a lowercase that will be user and in the database
itself it will add it as users.
So whatever the plural, it is able to find it in its own dictionary.
It will able to it will just do that pretty simple.
Nothing much more that we haven't seen already.
Now, after that, we need to provide all these properties, so we're going to go ahead and get started
with name.
We already had a long discussion about name, email, password, photo role, forgot password token,
forgot password expiry and of course created add.
So we just need to provide all of that.
Now coming on to that, you can go ahead and say name string and that's it.
This is a perfectly valid, 100% valid schema.
This will add a field into the mongoose that, hey, whenever the name comes in it is going to come
up as a part of a string.
Now this is okay, this is totally fine.
In fact, for some of the cases we are going to do it.
But in this case, the name is a little bit more complex and requires a bit more field.
So in that case, we provide an object just like this, and we go ahead and say, Hey, the type is
going to be string.
What is the difference between this and the first one?
Nothing at all.
Nothing.
No difference at all.
This is another way kind of another constructor that you can use.
But the reason why we are providing an object, because we need to provide more fields so we can actually
mark any field as required as true or anything similar to that.
So you can go ahead and just say required as true.
This is again totally 100% fine.
But if you just go ahead and pass on an error here and say that first property is true, the second
property is the error message.
When somebody doesn't pass me this error message, I'm automatically going to provide an error message
here.
So what that error message is going to be, please provide a name.
So in this way, I'm not only just providing that what fields are required, but I'm also providing
that what error message should go up when this field is not being passed to us?
This is one of the thing where mongo is actually shine a lot that you don't have to craft some different
messages and keep that in to file that, hey, what happens when name is not parsed and all of that?
Everything is just provided right into the models, which I think is a great way of getting started.
After that, we can also go ahead and provide that what could be the max length of the name.
Now again, if you want to provide, go ahead, provide.
If you don't want to go ahead and provide that, it's up to you.
I'll say that 40 characters are more than enough for a name, but maybe there are some names which can
be more than 40.
But we are expecting that, hey, somebody needs to acronym that name and all of that.
So we're going to go ahead and provide error message that name should be under.
Characters.
Hopefully I wrote everything correctly.
Okay, so this is the basics of how you define that.
Do we have more properties than this?
Yes, of course you'll read.
You have to read the Mongoose documentation for that.
But there is a whole lot of that.
Now, next, we are going to use this validator because we could have used the validator inside the
name itself.
But let's go ahead and use that onto the next field, which is email.
So I'll copy this and paste it up here.
Now, this time, this field is email.
Again, if I can write that email now this is going to be a type of string.
The required is true and we're going to go ahead and change that.
That please provide an email.
So that is going to be better.
Now, this time we don't have any maxlength or something.
We are going to be using validator in this case.
So let's go ahead and use validator for that.
So we actually have a property in the mongoose itself, which is validate.
Now this is where Validator actually shines and you can write your own validators as well.
There is no big issue.
They are pretty fairly easy to write there as well.
So this is where I'm going to go ahead and say, hey, validator, which we brought in from Validator
and as soon as I put a dot, you can see there is a whole lot of things that it can do for you.
It can check a whole lot of user schema and all of that.
But if I go ahead and say is email notice, we just saw in the documentation in earlier videos that
it can check for the data you are by email and a whole bunch of other things.
This is exactly how you do that.
And after that, you can provide an error message that please enter email in correct format.
There we go.
So now this is going to be pretty basic.
That email needs to be in the correct format as well.
Now, one more thing, which is really fantastic and really good about the mangoes that it gives us.
There is a field unique and I can turn this on as true.
Now Mongoose will automatically look into the database before saving it that whether this email already
exists in my database or not, although I will check it onto the my back end part itself.
But it's really great to have another step of protection that I'm getting all the unique emails while
signing up the user or making it fresh record.
So that is always a fantastic thing that comes in.
Now let's go ahead and after email, we're going to go ahead and have another field, which is going
to be password.
So let's go up here.
And yes, I duplicated just that.
So this one is going to be password.
And remember, we never, ever, ever save the password, confirm field in the database no matter what
language you are writing in.
This is how we go work with that.
So again, required is true and we are going to say please provide a password as we definitely can use
kind of a validate to check whether somebody is providing a complex and all of that.
I wouldn't be doing that.
You can actually go ahead and do that.
I wouldn't be providing that.
Definitely.
We don't need unique, so we're going to go ahead and remove that.
We can actually go ahead and say that it should be a minimum length.
So for protection sake, you can go ahead and say, hey, there should be at least six, seven or ten,
whatever the characters you are looking for.
So we will say that similar to this, we'll say password should be at least six cat.
I'm going to make it short character for care from now onwards.
Okay, one more thing, which is really, really important and it depends on how you are flowing actually
your application.
We saw that when once we were doing these authentication, all of that, that our password was also
going whenever we we were bringing the user.
So we had to just say that a user dot password equals to undefined and all of that because password
was coming in as default whenever we were bringing the user model itself.
Now what you can do is you can provide a field here which says select false.
So now what will happen is whenever you are going to select any model or any particular user and we'll
try to bring in the password field will not come there.
In case you want to have the password field, you have to explicitly mention that that, hey, this
time I'm changing some password or comparing the password or something.
Please give me that password.
Field So this is kind of a flow again, some people like to just put it undefined at that time.
Some people like to put it here as select false depends on the flow.
And again, all of them are correct.
There is no such thing as bad or good or something like that.
Okay, let's go ahead and select this.
And after that, we are going to go ahead and bring in the role.
So we discussed that there is going to be a role of every single user and we don't need this much of
data for the role.
We can actually go ahead and remove this.
So the role is going to be type of string and we need to provide a default for the role as well because
as soon as the user signs up, we need to provide him some role because that's how our functionality
is going to work on.
We'll say that the default is user, but we will provide a functionality later on to the admin that
hey, this is how you can go ahead and make this user as admin and user whatever you like.
Again, the very first user who is going to be admin, we cannot make him admin just like anything.
We have to go into the database, change the field manually via through MongoDB, Command Shell or via
their UI interface.
However, the first user needs to be made admin explicitly and you have to mention that part.
Okay.
So this is the basics of it.
What else we are missing?
Let's check that we have got name, email, password.
We are missing photo.
We have got through the role so we need to check out the photo that how we are going to do with that.
Okay.
Let's go ahead and make a copy of this and call this one as simply photo.
Photo.
There we go.
Okay.
So this photo is a little bit different because inside this photo we obviously have an object.
This is not an airfield field, so this is fine, but we are containing two fields inside the photo.
The first is ID itself, which we'll get back from the cloud entry.
Second is the secure URL, which we started at the time.
We were uploading a whole lot of photos.
So let's go ahead and call this one as ID.
So ID further is going to be done as a property.
If it is just one for something like this string, you can go ahead and do and you can just get away
with that, something like this.
And again, same thing goes here.
You can go ahead and provide this field something like this.
So I'm going to mention that this is of type string and this is a required field.
So required is going to be true.
There we go.
Now, same thing will happen to the secure security URL.
So let's go ahead and make a copy of this one.
And we are going to go ahead and click on here and we'll say this is secure, underscore URL.
So again, we get this from the cloud.
No big deal.
We'll be storing that as a string format.
Required is true.
Definitely 100%.
So this is all the basics of photo.
And let me go ahead and minimize.
Actually, I need to copy this.
Or I can copy the roll.
Actually, that's much better.
This is what we need.
Okay, let's get.
Grab that and I'll shrink this one.
Okay.
So after that, what we were having is let's check that we we're having this a reset password.
Token I'm going to call this as forgot password token because I think that makes a bit more sense to
me.
So let's go ahead and call this one as.
Forgot password.
Feel free to name it.
Anything that says really the least bothering case I guess for any one of us.
Now this password token is definitely a is a simple type of string, so we don't need this much of thing.
Again, I can go ahead and call this one as date.
Remove this 100%, totally a valid syntax.
But in case when you have just the type that you have to mention, this is not a type date.
This is type A string.
Getting ahead of myself, I was thinking about forgot password expiry.
So again, sorry.
So again, this is totally a fine thing, but in case when you have just the type to be mentioned,
I think it is a better approach to go ahead and come up here and simply say that this is going to be
a string.
There we go.
That's it.
Now, once we have this one, obviously, let's mention the forgot password expiry as well.
So let's go ahead and say that expiry and this is of a format of date.
That's it.
Okay.
These are the basic fields that we got.
Let's see what else we are missing up, created out, of course.
Let's go ahead and add that.
So at the very end of it, I'm going to go ahead and say, hey, we have a field at, created, at and
in this field, let's go ahead and add a date.
So this is going to be type of date.
That's fine.
And we don't want to actually work on this created date.
Every single time we work on the back end, we just want to auto populate it.
So for this, we are going to set a default value to this.
So default is going to be day dot now.
Now again, please don't mention data now like this.
We don't want to run it as this time.
We want to run it whenever this field is getting executed.
So let's save this and quickly have a thing that how we are actually managing this.
So let me shrink all of them.
So let's make it will make much more sense to you.
And there you go.
So this is our model.
Totally.
It's really simple, really basic.
We got the name, email, password, role photo and forgot password, forgot password, expiry created
add.
So this is the very basic model, really teeny tiny that we have worked on.
And I told you when we were discussing about the brainstorming, it looked like we were doing so much,
but it's not too much.
Once you are totally focused on what you really need to do.
So that's what we got.
Now, once the course actually finishes up, you can just go ahead and add more entries.
Maybe you want to add a person's address or something directly up here so you can go ahead and do that.
But I think we are going to stay with the this much of the basics.
So this is all what we have done.
Again, this part is all done.
Now it works.
We need to work on this, all these methods, and I'll show you some of the interesting stuff.
This is the part we are going to learn something new and something interesting up here.
Let's go ahead and catch up in the next video.