We just picked up a couple of odds and ends around our payments component and the head.
We're now ready to take the token that we got back from Strype and send it to our express server which
will be responsible for following up with stripe.
Now in the last video recall that I had mentioned that this last step right here of add credits to users
account we had clarified this part and said when we say users account we're really talking about the
user model that is stored inside of our database.
So we're going to eventually add on another property to the user model.
Remember that right now it really just has that google id property and we will add that property and
that will specify how many credits a user has to spend.
Now this is kind of important because it's going to directly affect exactly how we put together this
next step right here.
So let me kind of break this down and make sure this kind of clear a little kind of trick or a little
kind of shortcut I should say that we're going to take.
It's going to make our application work a little bit better.
OK.
So we go back to our mockup.
I want to remind you that in the header the end result of a user kind of pain some money into their
account or sending us money.
Yes we're going to build their credit card.
We're going to update the number of credits that the user has.
But the real end result that a user will expect to see after they have paid us money is that they'll
expect to see the header update in some fashion.
Remember the header is going to have the number of credits that the user currently has inside their
account.
So really when we really think about it after we successfully bill a user we want to somehow update
the number of credits they have and display that inside the header.
Now let's take these two kind of aspects together that we just discussed we said on the one hand I want
to make sure that the user sees the number of credits that they now have after they successfully submit
some billing.
So that's kind of fact number one.
Now Fact number two is that the object that will store the user's credits is the user model.
Now kind of fact number three that we're going to draw in here if you recall when our application first
boots up we fetch the current user model and we save it inside of that author reducer thing.
So these three items are very closely related.
In other words fetching the current user or getting the current user model which will very shortly contain
the number of credits that the user has is going to directly affect how we show the number of credits
up in the head right here.
So hey what am I getting at.
Let's let's kind of get to it.
Here's what I'm getting at.
When our application first boots up we are currently fetching the current user model.
Now very shortly it will have the number of credits that the user owns inside that model.
And so an application boot up time when our app first boots up we will know exactly how many credits
to display inside the header.
Now what I'm seeing here the trick that we're going to use the little shortcut we're going to use We're
going to say that whenever a user pays us some money and we take that token and send it to our back
the API the API will do the follow up request with Strype And then after the user has been successfully
charged the server will update the number of credits that the user has.
And it will send back the current user model with the new number of credits that it contains.
And that way we can always look to that author reducer.
So remember the author reducers what stores the user model.
We can always look at the author reduce or take the user model out there and say hey how many credits
do you have.
And that number should always be up to date.
So essentially we're just doing a little bit of a shortcut here to make sure that the header is always
up to date by reusing a little bit of infrastructure that we already have in our app.
So we don't have to put together a separate like billing reducer or a separate like credits reducer
or anything like that.
We're going to reuse some information that is already going to be picked up by the author reducer to
update the header.
OK.
So I just want you to keep that in mind because it's going to directly affect some of the code that
we're just about to write.
So at this point we're going to take that token.
We're going to send it to our back in API.
And remember any time you want to communicate something to the back and API you are always going to
make that request inside of an action creator.
So let's now create the actual creator.
And when we do and when we start to talk about the return type of the action or the type of the action
that we dispatch from that action creator all this discussion about the user model stuff is going to
very quickly make sense.
All right.
So I need to change back over to my code editor I need to find my actions index.
File inside if you're really going to create a new action creator and we'll assume that's called something
like.
How about on our own we're basically taking a token here and sending to the backend.
So let's call it handle token.
So we will assume that this action creator will be called with the token that we just got back from
our Strype API.
Now this is going to be another asynchronous action creator just like the one we had created up here.
So we're going to use the same general type of structure for the actual creator itself.
So we'll have the first arrow function that returns in a sync function and that function will be called
with the dispatch method.
So we'll say async dispatch and then the body of our real action creator.
OK so now inside of here I want to make a post request to our back and server.
We are specifically making a post request because we want to send some information along with the request
to the backend.
So we will say Konst rez equals a weight CEOs dot post again because we want to make a post request
to send some information.
Now we don't have a route handler set up on our back and server just yet.
I'm going to assume that we are going to very shortly create a route handler called something like Slash
API slash stripe remember that the names of these routes don't make a big difference.
I'm just kind of arbitrarily saying you know what.
This is handling straight payments what's called an API.
Then as a second argument we're going to pass along the entire token that we got back from Strype ourselves.
OK so now comes the second part after this line of code right here has been completed.
That means that we have successfully made a post request to our back and server and we've gotten a response
that I don't know says something inside of it right.
So the question now is in the response back from the server what type of action are we going to dispatch.
All this goes back to exactly what we were just talking about.
If we assume that the backend server sends back the current user model with the updated number of credits
then we can reuse the exact same patch user type that we made that we created previously.
Remember if we dispatch an action with type fetch user and that contains a payload of the user model
the author douceur will automatically pick it up.
And then in theory anything inside of our application that depends upon the user model will be automatically
updated.
And so the idea is that if we make sure that the head or component looks at the user model to display
the number of credits that the user has when the author news or picks up the updated user model boom
updated hatter.
All right.
So back inside of our action creator after the request is complete we will dispatch an action of type
fetch user with a payload of redstart data just like before because we're going to assume that we get
back the exact same user model as up here and we will assume that we want to dispatch the exact same
action type to update the user model inside of the author douceur.
Now at this point you might look at these two action creators and say Hey Stephen is there any way that
we can like dry up this code a little bit.
My response would be you know yeah they have similar structures like the code looks the same very much
but the requests that we are sending this off to is very different and that is kind of hard to generalize
between the two.
In addition this action Kreator itself we can very easily imagine a case in which either fecche user
or handled tokin might want to do some other stuff like we could imagine a case in which they handled
token action creator after successfully making the request.
Maybe we want to redirect the user to some like thank you page that says Hey thanks for giving us money.
You can now create a survey and heres how to do it.
So yes they look similar but I don't know I feel a little bit uneasy trying to dry up this code any
more.
OK.
So that should basically be it.
I think that our code will now successfully take the token that we get back from Strype and send it
to the backend server.
Weve got the actual creator put together.
Now the last thing we have to do is hook this action creator up to our head or examine our payments
J.S. component.
So let's take a quick break and then take care of that in the next section.