In the last video I had mentioned that there might be some little sidekick.
So we have to worry about here around displaying the number of credits.
And I'd also mention that we should probably test and make sure that after user add some number of credits
the total gets updated appear in the header.
So let's give it a shot.
Now when we refreshed the page we can see very easily that we get the correct number of head of credits
inside the header like that is definitely working out correctly.
When ever we refresh the page and it is a reminder this is working out correctly because when we first
load up our application we make a request to get our current user and that current user model contains
the number of credits that we have.
So very easy the instant the application loads up boom.
Here's the number of credits to show inside the header.
Now here's where life gets a little bit more interesting.
You'll recall looking at this diagram right here.
So we kind of looked at this diagram a little bit ago when we were working on our action creator to
actually charge the user some money or send the striped token to our back and API.
And I showed you this diagram saying oh yeah well if our route sends back the updated user model with
the new number of credits somehow the header would just magically stay up to date.
So let's test this out inside of our application and see if things kind of work the way we expect.
And I think you might be surprised that they actually do.
And we're going to very quickly go through the flow of why everything just kind of behaves as the way
we would want it to.
OK.
So click on Add credits and enter in my email to my credit card number and pay the money.
OK.
So there's the Strype request to get the token.
There's our Strype request to actually update the number of credits and then you'll notice that the
credits number right here automatically advanced on to ten credits.
So it definitely appears that everything is just magically updating itself.
So let's just go through the flow to make sure that it's really clear to you exactly why this number
incremented automatically from 5 to 10.
So when we sent out the request to pay that additional money.
So here's the requests to our back and API our API said OK we're going to finalize that charge after
we finalize the charge.
We will add five credits to the user's model to the users account.
We will save that to our database and then respond to the request with the updated user model.
And that's exactly what you'll see right here.
So here's the response to the request that we use to pay in the money.
So it very clearly now says hey you have 10 credits.
OK.
So that part's not too bad.
Right.
But how does the response here somehow update the header.
Well you will recall that the header text for displaying the number of credits that the user has comes
from the property does not start off this stuff start off is being produced by our auth reducer inside
of our reducers directory.
So if we go into that file we can see very plainly.
OK.
Any single time that an action comes across with a type of fetch user.
We return the actions payload.
OK.
Well that makes sense lets go and look at our actual crater now.
So inside of our actions directory index j US is now inside of here.
Here's our action creator to take a token and send it to our back and API.
We know without a doubt that the response to this post request right here is the updated user model
or the user model with the new number of credits.
And then remember we had said that after we get that response we dispatch an action of type fetch user
with that user model.
And so it's solely because we kind of use this same action type between these two action creators and
the fact that our author reducer is watching for this very specific typewrite here.
This is exactly what makes the header just automatically update when we get the response back from the
API.
Okay update the value in the reducer the reducer updates the value it pulls off the new user model because
the author reducers ran and fetched a new piece or created a new piece of states are read ex-state updates
and because the read ex-state updates all the components in our application we render as well with that
new state.
And so now this doc prop's start off contains the new user model that just got returned from our API
and TA-DA the header updates its text as well.
OK.
So that might have seemed like a very obvious flow to you but it also might have been a little bit confusing.
I just want to spend a little time to make sure that it was very clear why the header was updating itself
automatically.
OK.
So at this point I think that everything around billing is pretty much wrapped up inside of our application.
So we have the ability to create a new user.
They have a default number of credits of zero and then we made sure that after user out some money to
their account they actually see the updated total in here as well.
So now that we have billing pretty much worked out let's take a quick break and then continue with our
next feature in the next section.