Know that we are successfully building our users for some amount of money we need to follow up and make
sure that we actually give them credit and say OK we accept that you paid us some money.
Thanks for that.
And now we're going to give you some number of credits.
So in order to record some number of credits with each and every user We're going to add another property
to our user model class.
Remember our user model class currently has a google id property and nothing else assigned to it.
We are going to add in another property to the model called credits.
We'll make sure that we start off the credits as a default of 0.
So by default nobody has any credits you have to actually pay us some amount of money to get some.
And then after a user is successfully built we will add in five additional credits.
So let's get to it.
We'll first start off by finding our models directory inside of there is the user G-S file.
We haven't touched this thing in a while but you'll recall that we created a new mongoose model inside
of here.
We made a new user schema where we specified that this user model would have a google id property that
would start off as a string.
So we're now going to add in this other property this credit's property.
So we'll say credits and then we want to specify that the type of field that this is is going to be
a number.
Because of course you're going to have save 5 credits or four or three or two or zero or one or whatever
it might be.
And then the other thing that we have to do here is make sure that we somehow initialize or default
the value of credits to specifically zero because again we want to make sure that everyone starts off
with no credits.
You have to pay us money to send out any surveys now to both tell this credit's property that it's going
to be of type number.
But also tell it that it needs to have a default value of zero.
We're going to assign it an object to provide both those little pieces of configuration.
So whenever you are defining a schema you can either just assign the type of field it is or if you want
to also specify some other configuration you'll assign an object to it and then pass a couple of different
options into the subject.
So the first option that we want to specify is the type of field that this is.
And so remember last time we had said that the Google idea is going to be a string.
The credits is going to be a number like the next we need to default the value of credits to be zero.
And to do so with say default of 0.
So I think that both of these option names are here are pretty clear pretty straightforward.
There's a whole variety of other option names you could pass to a property and you can check out the
mongoose documentation to get a good sense of what those other options are.
Some of them end up being quite useful depending on the actual application that you're building.
OK.
So now that our user model is aware that it has a credit's property that is in number and starts off
as zero.
We can now go back over to our building routes file.
So you're building around us and we'll say that after we successfully applied a charge to the user's
credit card right after that we're going to then take the user model or the modeled representing the
person who just made this request.
We will add five credits to them and then we'll send the user model back to the client.
So we will essentially respond to the request with the newly updated user model.
Okay.
So first challenge we need to somehow get a reference to the current user model the person who just
made this request or just attempted to pay some money into their account.
You'll recall that whenever we are making use of passport and user has signed into our application we
can access the current user model as rec dot user so request dot user this is set up automatically by
passport.
Remember we had wired up passport inside of our next guest file with a passport initialize and password
that session calls right here.
OK.
So this is our user model right here.
Now we're going to add five credits to their credits property or five units I guess to their credit
property.
We will then persist the user.
So we will save them back to the database.
And then after we get the user back or after we successfully commit that save We'll then send the update
the user back to have made the request.
So to update the number of credits that a user has with say rect-Al user of dot credits plus equals
five that's pretty much it.
We then have to save the user.
So remember that will be user Dotts save.
That's one of the methods or functions that we have on a user model to actually take the model and persist
it to our database just modifying the user.
Right.
It doesn't actually save any changes to our database so we have to actually call Save on this.
Make sure that these changes get persisted so we'll say Reyk user save.
Remember that whenever we save a model it is an asynchronous request.
It's something it takes some amount of time.
So just like we did before with the Awake key word up here we'll put a wait in front of save.
And then whenever the Save process is complete it will return the updated user model.
So we'll say Consta user equals a wait.
Right.
These are not safe.
Now at this point you might say again.
So even if you already have the user model right here as like user why are we taking the result of save
and assigning it to user.
We'll just be clear.
Yes.
These are essentially kind of in theory they represent the same user.
However whenever we save a user model by convention we usually from that point on make reference to
the copy of the model or the copy of the user that we just got back from the database.
So it could be that now at this point in time after making the save this record user copy of the user
a copy of the model might be like old or stale it might have outdated information inside of it.
So just to make sure that we are always using the most possible are the most up to date as possible
model at any given time.
We make use of the user model that got returned from the Save request but again at the end of the day
these really represent the same user.
They are however two completely separate objects in memory.
So they are completely separate even though they do represent the same user just calling saver here
does not intrinsically like somehow update all the properties on the user.
OK so now that we've got the user back the last step is to make sure that we actually respond to the
request with the updated user.
So remember any song we want to respond to requests would just say redstart send using the response
object right here and we send back the data that we want to communicate back to the browser.
So at the very bottom has got send and we'll send back the user like so
OK so that is pretty much it.
I think that we will take a quick break.
We'll come back in the next section we'll test this out.
I will ask you to make sure that your server is running.
Let's do that right now.
I'm in sodomised server directory.
I'm going to ensure that the server is running so I'll start that up right now.
And by the time everything warms up we'll continue in the next section and test this out.
So I'll see you in just a minute.