1
00:00:00,810 --> 00:00:04,250
In the last video I had mentioned that there might be some little sidekick.

2
00:00:04,260 --> 00:00:07,710
So we have to worry about here around displaying the number of credits.

3
00:00:07,830 --> 00:00:12,180
And I'd also mention that we should probably test and make sure that after user add some number of credits

4
00:00:12,480 --> 00:00:15,100
the total gets updated appear in the header.

5
00:00:15,120 --> 00:00:16,860
So let's give it a shot.

6
00:00:16,860 --> 00:00:22,980
Now when we refreshed the page we can see very easily that we get the correct number of head of credits

7
00:00:22,980 --> 00:00:25,770
inside the header like that is definitely working out correctly.

8
00:00:25,790 --> 00:00:32,160
When ever we refresh the page and it is a reminder this is working out correctly because when we first

9
00:00:32,160 --> 00:00:38,370
load up our application we make a request to get our current user and that current user model contains

10
00:00:38,370 --> 00:00:40,450
the number of credits that we have.

11
00:00:40,470 --> 00:00:43,780
So very easy the instant the application loads up boom.

12
00:00:43,800 --> 00:00:46,430
Here's the number of credits to show inside the header.

13
00:00:46,500 --> 00:00:49,010
Now here's where life gets a little bit more interesting.

14
00:00:49,320 --> 00:00:51,950
You'll recall looking at this diagram right here.

15
00:00:52,200 --> 00:00:57,630
So we kind of looked at this diagram a little bit ago when we were working on our action creator to

16
00:00:58,170 --> 00:01:02,390
actually charge the user some money or send the striped token to our back and API.

17
00:01:02,580 --> 00:01:10,260
And I showed you this diagram saying oh yeah well if our route sends back the updated user model with

18
00:01:10,260 --> 00:01:15,650
the new number of credits somehow the header would just magically stay up to date.

19
00:01:15,660 --> 00:01:20,970
So let's test this out inside of our application and see if things kind of work the way we expect.

20
00:01:20,970 --> 00:01:23,240
And I think you might be surprised that they actually do.

21
00:01:23,430 --> 00:01:27,930
And we're going to very quickly go through the flow of why everything just kind of behaves as the way

22
00:01:27,930 --> 00:01:29,320
we would want it to.

23
00:01:29,870 --> 00:01:30,230
OK.

24
00:01:30,240 --> 00:01:39,410
So click on Add credits and enter in my email to my credit card number and pay the money.

25
00:01:39,710 --> 00:01:39,950
OK.

26
00:01:39,950 --> 00:01:42,610
So there's the Strype request to get the token.

27
00:01:42,640 --> 00:01:47,960
There's our Strype request to actually update the number of credits and then you'll notice that the

28
00:01:47,960 --> 00:01:53,060
credits number right here automatically advanced on to ten credits.

29
00:01:53,060 --> 00:01:57,410
So it definitely appears that everything is just magically updating itself.

30
00:01:57,440 --> 00:02:02,780
So let's just go through the flow to make sure that it's really clear to you exactly why this number

31
00:02:02,780 --> 00:02:06,850
incremented automatically from 5 to 10.

32
00:02:06,980 --> 00:02:11,110
So when we sent out the request to pay that additional money.

33
00:02:11,120 --> 00:02:17,000
So here's the requests to our back and API our API said OK we're going to finalize that charge after

34
00:02:17,000 --> 00:02:18,450
we finalize the charge.

35
00:02:18,470 --> 00:02:22,520
We will add five credits to the user's model to the users account.

36
00:02:22,520 --> 00:02:28,530
We will save that to our database and then respond to the request with the updated user model.

37
00:02:28,730 --> 00:02:30,470
And that's exactly what you'll see right here.

38
00:02:30,470 --> 00:02:34,990
So here's the response to the request that we use to pay in the money.

39
00:02:35,270 --> 00:02:39,210
So it very clearly now says hey you have 10 credits.

40
00:02:39,570 --> 00:02:39,850
OK.

41
00:02:39,890 --> 00:02:41,220
So that part's not too bad.

42
00:02:41,270 --> 00:02:41,740
Right.

43
00:02:41,870 --> 00:02:45,380
But how does the response here somehow update the header.

44
00:02:45,710 --> 00:02:52,310
Well you will recall that the header text for displaying the number of credits that the user has comes

45
00:02:52,310 --> 00:03:00,770
from the property does not start off this stuff start off is being produced by our auth reducer inside

46
00:03:00,770 --> 00:03:02,280
of our reducers directory.

47
00:03:02,570 --> 00:03:06,240
So if we go into that file we can see very plainly.

48
00:03:06,430 --> 00:03:06,930
OK.

49
00:03:06,980 --> 00:03:11,500
Any single time that an action comes across with a type of fetch user.

50
00:03:11,690 --> 00:03:14,200
We return the actions payload.

51
00:03:14,540 --> 00:03:14,850
OK.

52
00:03:14,870 --> 00:03:18,230
Well that makes sense lets go and look at our actual crater now.

53
00:03:18,230 --> 00:03:22,990
So inside of our actions directory index j US is now inside of here.

54
00:03:23,030 --> 00:03:28,040
Here's our action creator to take a token and send it to our back and API.

55
00:03:28,040 --> 00:03:34,060
We know without a doubt that the response to this post request right here is the updated user model

56
00:03:34,140 --> 00:03:36,820
or the user model with the new number of credits.

57
00:03:36,980 --> 00:03:43,730
And then remember we had said that after we get that response we dispatch an action of type fetch user

58
00:03:44,240 --> 00:03:45,910
with that user model.

59
00:03:46,100 --> 00:03:52,280
And so it's solely because we kind of use this same action type between these two action creators and

60
00:03:52,280 --> 00:03:57,360
the fact that our author reducer is watching for this very specific typewrite here.

61
00:03:57,410 --> 00:04:02,770
This is exactly what makes the header just automatically update when we get the response back from the

62
00:04:02,780 --> 00:04:03,480
API.

63
00:04:03,620 --> 00:04:10,580
Okay update the value in the reducer the reducer updates the value it pulls off the new user model because

64
00:04:10,580 --> 00:04:17,660
the author reducers ran and fetched a new piece or created a new piece of states are read ex-state updates

65
00:04:17,750 --> 00:04:22,730
and because the read ex-state updates all the components in our application we render as well with that

66
00:04:22,730 --> 00:04:23,800
new state.

67
00:04:23,840 --> 00:04:30,020
And so now this doc prop's start off contains the new user model that just got returned from our API

68
00:04:30,560 --> 00:04:33,940
and TA-DA the header updates its text as well.

69
00:04:35,060 --> 00:04:35,730
OK.

70
00:04:36,410 --> 00:04:41,560
So that might have seemed like a very obvious flow to you but it also might have been a little bit confusing.

71
00:04:41,570 --> 00:04:46,430
I just want to spend a little time to make sure that it was very clear why the header was updating itself

72
00:04:46,490 --> 00:04:47,910
automatically.

73
00:04:48,620 --> 00:04:49,010
OK.

74
00:04:49,010 --> 00:04:55,120
So at this point I think that everything around billing is pretty much wrapped up inside of our application.

75
00:04:55,190 --> 00:04:58,050
So we have the ability to create a new user.

76
00:04:58,130 --> 00:05:05,360
They have a default number of credits of zero and then we made sure that after user out some money to

77
00:05:05,360 --> 00:05:10,090
their account they actually see the updated total in here as well.

78
00:05:10,130 --> 00:05:14,780
So now that we have billing pretty much worked out let's take a quick break and then continue with our

79
00:05:14,810 --> 00:05:16,730
next feature in the next section.