1 00:00:00,510 --> 00:00:05,000 We just picked up a couple of odds and ends around our payments component and the head. 2 00:00:05,250 --> 00:00:10,080 We're now ready to take the token that we got back from Strype and send it to our express server which 3 00:00:10,080 --> 00:00:12,930 will be responsible for following up with stripe. 4 00:00:13,440 --> 00:00:18,630 Now in the last video recall that I had mentioned that this last step right here of add credits to users 5 00:00:18,660 --> 00:00:23,880 account we had clarified this part and said when we say users account we're really talking about the 6 00:00:23,880 --> 00:00:26,790 user model that is stored inside of our database. 7 00:00:27,000 --> 00:00:31,000 So we're going to eventually add on another property to the user model. 8 00:00:31,050 --> 00:00:36,270 Remember that right now it really just has that google id property and we will add that property and 9 00:00:36,270 --> 00:00:40,190 that will specify how many credits a user has to spend. 10 00:00:40,530 --> 00:00:45,630 Now this is kind of important because it's going to directly affect exactly how we put together this 11 00:00:45,630 --> 00:00:46,490 next step right here. 12 00:00:46,530 --> 00:00:51,660 So let me kind of break this down and make sure this kind of clear a little kind of trick or a little 13 00:00:51,720 --> 00:00:55,220 kind of shortcut I should say that we're going to take. 14 00:00:55,320 --> 00:00:58,120 It's going to make our application work a little bit better. 15 00:00:58,620 --> 00:00:58,970 OK. 16 00:00:58,990 --> 00:01:00,260 So we go back to our mockup. 17 00:01:00,270 --> 00:01:06,390 I want to remind you that in the header the end result of a user kind of pain some money into their 18 00:01:06,390 --> 00:01:08,010 account or sending us money. 19 00:01:08,220 --> 00:01:10,080 Yes we're going to build their credit card. 20 00:01:10,080 --> 00:01:13,050 We're going to update the number of credits that the user has. 21 00:01:13,230 --> 00:01:19,650 But the real end result that a user will expect to see after they have paid us money is that they'll 22 00:01:19,650 --> 00:01:22,590 expect to see the header update in some fashion. 23 00:01:22,590 --> 00:01:27,240 Remember the header is going to have the number of credits that the user currently has inside their 24 00:01:27,240 --> 00:01:28,180 account. 25 00:01:28,560 --> 00:01:35,940 So really when we really think about it after we successfully bill a user we want to somehow update 26 00:01:35,940 --> 00:01:40,000 the number of credits they have and display that inside the header. 27 00:01:40,230 --> 00:01:45,780 Now let's take these two kind of aspects together that we just discussed we said on the one hand I want 28 00:01:45,780 --> 00:01:51,600 to make sure that the user sees the number of credits that they now have after they successfully submit 29 00:01:51,600 --> 00:01:52,290 some billing. 30 00:01:52,290 --> 00:01:54,250 So that's kind of fact number one. 31 00:01:54,250 --> 00:02:01,430 Now Fact number two is that the object that will store the user's credits is the user model. 32 00:02:01,760 --> 00:02:06,300 Now kind of fact number three that we're going to draw in here if you recall when our application first 33 00:02:06,300 --> 00:02:12,630 boots up we fetch the current user model and we save it inside of that author reducer thing. 34 00:02:12,630 --> 00:02:15,570 So these three items are very closely related. 35 00:02:15,570 --> 00:02:21,120 In other words fetching the current user or getting the current user model which will very shortly contain 36 00:02:21,120 --> 00:02:27,380 the number of credits that the user has is going to directly affect how we show the number of credits 37 00:02:27,390 --> 00:02:28,800 up in the head right here. 38 00:02:28,830 --> 00:02:30,060 So hey what am I getting at. 39 00:02:30,060 --> 00:02:31,570 Let's let's kind of get to it. 40 00:02:31,950 --> 00:02:34,240 Here's what I'm getting at. 41 00:02:34,740 --> 00:02:39,960 When our application first boots up we are currently fetching the current user model. 42 00:02:40,230 --> 00:02:44,720 Now very shortly it will have the number of credits that the user owns inside that model. 43 00:02:44,730 --> 00:02:50,220 And so an application boot up time when our app first boots up we will know exactly how many credits 44 00:02:50,220 --> 00:02:52,110 to display inside the header. 45 00:02:52,500 --> 00:02:57,330 Now what I'm seeing here the trick that we're going to use the little shortcut we're going to use We're 46 00:02:57,330 --> 00:03:03,330 going to say that whenever a user pays us some money and we take that token and send it to our back 47 00:03:03,390 --> 00:03:09,870 the API the API will do the follow up request with Strype And then after the user has been successfully 48 00:03:09,870 --> 00:03:14,570 charged the server will update the number of credits that the user has. 49 00:03:14,760 --> 00:03:21,960 And it will send back the current user model with the new number of credits that it contains. 50 00:03:22,350 --> 00:03:25,530 And that way we can always look to that author reducer. 51 00:03:25,560 --> 00:03:28,540 So remember the author reducers what stores the user model. 52 00:03:28,650 --> 00:03:33,990 We can always look at the author reduce or take the user model out there and say hey how many credits 53 00:03:33,990 --> 00:03:34,680 do you have. 54 00:03:34,800 --> 00:03:37,460 And that number should always be up to date. 55 00:03:37,470 --> 00:03:42,030 So essentially we're just doing a little bit of a shortcut here to make sure that the header is always 56 00:03:42,030 --> 00:03:46,930 up to date by reusing a little bit of infrastructure that we already have in our app. 57 00:03:47,100 --> 00:03:53,790 So we don't have to put together a separate like billing reducer or a separate like credits reducer 58 00:03:53,790 --> 00:03:54,870 or anything like that. 59 00:03:54,870 --> 00:04:00,180 We're going to reuse some information that is already going to be picked up by the author reducer to 60 00:04:00,240 --> 00:04:01,370 update the header. 61 00:04:01,650 --> 00:04:02,000 OK. 62 00:04:02,010 --> 00:04:06,330 So I just want you to keep that in mind because it's going to directly affect some of the code that 63 00:04:06,330 --> 00:04:08,300 we're just about to write. 64 00:04:08,310 --> 00:04:11,760 So at this point we're going to take that token. 65 00:04:11,760 --> 00:04:13,630 We're going to send it to our back in API. 66 00:04:13,650 --> 00:04:17,940 And remember any time you want to communicate something to the back and API you are always going to 67 00:04:17,940 --> 00:04:20,640 make that request inside of an action creator. 68 00:04:20,640 --> 00:04:22,310 So let's now create the actual creator. 69 00:04:22,320 --> 00:04:27,510 And when we do and when we start to talk about the return type of the action or the type of the action 70 00:04:27,510 --> 00:04:32,520 that we dispatch from that action creator all this discussion about the user model stuff is going to 71 00:04:32,640 --> 00:04:35,090 very quickly make sense. 72 00:04:35,100 --> 00:04:35,340 All right. 73 00:04:35,340 --> 00:04:39,840 So I need to change back over to my code editor I need to find my actions index. 74 00:04:40,040 --> 00:04:45,870 File inside if you're really going to create a new action creator and we'll assume that's called something 75 00:04:45,870 --> 00:04:46,790 like. 76 00:04:46,890 --> 00:04:51,620 How about on our own we're basically taking a token here and sending to the backend. 77 00:04:51,780 --> 00:04:53,780 So let's call it handle token. 78 00:04:54,360 --> 00:04:59,070 So we will assume that this action creator will be called with the token that we just got back from 79 00:04:59,070 --> 00:05:00,430 our Strype API. 80 00:05:00,810 --> 00:05:05,610 Now this is going to be another asynchronous action creator just like the one we had created up here. 81 00:05:05,730 --> 00:05:10,600 So we're going to use the same general type of structure for the actual creator itself. 82 00:05:10,710 --> 00:05:18,030 So we'll have the first arrow function that returns in a sync function and that function will be called 83 00:05:18,030 --> 00:05:20,040 with the dispatch method. 84 00:05:20,370 --> 00:05:27,340 So we'll say async dispatch and then the body of our real action creator. 85 00:05:27,460 --> 00:05:32,550 OK so now inside of here I want to make a post request to our back and server. 86 00:05:32,550 --> 00:05:37,800 We are specifically making a post request because we want to send some information along with the request 87 00:05:38,070 --> 00:05:39,660 to the backend. 88 00:05:39,660 --> 00:05:47,970 So we will say Konst rez equals a weight CEOs dot post again because we want to make a post request 89 00:05:48,210 --> 00:05:50,820 to send some information. 90 00:05:50,820 --> 00:05:54,930 Now we don't have a route handler set up on our back and server just yet. 91 00:05:54,930 --> 00:06:00,180 I'm going to assume that we are going to very shortly create a route handler called something like Slash 92 00:06:00,240 --> 00:06:06,030 API slash stripe remember that the names of these routes don't make a big difference. 93 00:06:06,030 --> 00:06:08,480 I'm just kind of arbitrarily saying you know what. 94 00:06:08,490 --> 00:06:12,830 This is handling straight payments what's called an API. 95 00:06:14,350 --> 00:06:22,860 Then as a second argument we're going to pass along the entire token that we got back from Strype ourselves. 96 00:06:22,870 --> 00:06:28,060 OK so now comes the second part after this line of code right here has been completed. 97 00:06:28,060 --> 00:06:33,100 That means that we have successfully made a post request to our back and server and we've gotten a response 98 00:06:33,460 --> 00:06:36,350 that I don't know says something inside of it right. 99 00:06:36,370 --> 00:06:42,900 So the question now is in the response back from the server what type of action are we going to dispatch. 100 00:06:43,300 --> 00:06:46,420 All this goes back to exactly what we were just talking about. 101 00:06:46,510 --> 00:06:53,260 If we assume that the backend server sends back the current user model with the updated number of credits 102 00:06:53,650 --> 00:07:01,370 then we can reuse the exact same patch user type that we made that we created previously. 103 00:07:01,520 --> 00:07:08,020 Remember if we dispatch an action with type fetch user and that contains a payload of the user model 104 00:07:08,470 --> 00:07:10,990 the author douceur will automatically pick it up. 105 00:07:11,200 --> 00:07:16,780 And then in theory anything inside of our application that depends upon the user model will be automatically 106 00:07:16,780 --> 00:07:17,770 updated. 107 00:07:18,160 --> 00:07:25,000 And so the idea is that if we make sure that the head or component looks at the user model to display 108 00:07:25,000 --> 00:07:30,730 the number of credits that the user has when the author news or picks up the updated user model boom 109 00:07:30,900 --> 00:07:32,640 updated hatter. 110 00:07:32,800 --> 00:07:33,180 All right. 111 00:07:33,280 --> 00:07:39,370 So back inside of our action creator after the request is complete we will dispatch an action of type 112 00:07:40,590 --> 00:07:49,330 fetch user with a payload of redstart data just like before because we're going to assume that we get 113 00:07:49,330 --> 00:07:56,200 back the exact same user model as up here and we will assume that we want to dispatch the exact same 114 00:07:56,200 --> 00:08:00,950 action type to update the user model inside of the author douceur. 115 00:08:00,970 --> 00:08:05,710 Now at this point you might look at these two action creators and say Hey Stephen is there any way that 116 00:08:05,710 --> 00:08:08,250 we can like dry up this code a little bit. 117 00:08:08,260 --> 00:08:13,990 My response would be you know yeah they have similar structures like the code looks the same very much 118 00:08:14,290 --> 00:08:19,210 but the requests that we are sending this off to is very different and that is kind of hard to generalize 119 00:08:19,210 --> 00:08:20,440 between the two. 120 00:08:20,440 --> 00:08:28,480 In addition this action Kreator itself we can very easily imagine a case in which either fecche user 121 00:08:28,480 --> 00:08:35,020 or handled tokin might want to do some other stuff like we could imagine a case in which they handled 122 00:08:35,020 --> 00:08:38,700 token action creator after successfully making the request. 123 00:08:38,770 --> 00:08:44,130 Maybe we want to redirect the user to some like thank you page that says Hey thanks for giving us money. 124 00:08:44,170 --> 00:08:47,220 You can now create a survey and heres how to do it. 125 00:08:47,260 --> 00:08:53,480 So yes they look similar but I don't know I feel a little bit uneasy trying to dry up this code any 126 00:08:53,480 --> 00:08:54,500 more. 127 00:08:55,240 --> 00:08:55,620 OK. 128 00:08:55,660 --> 00:08:57,690 So that should basically be it. 129 00:08:57,700 --> 00:09:03,010 I think that our code will now successfully take the token that we get back from Strype and send it 130 00:09:03,010 --> 00:09:03,930 to the backend server. 131 00:09:03,940 --> 00:09:05,890 Weve got the actual creator put together. 132 00:09:05,920 --> 00:09:10,990 Now the last thing we have to do is hook this action creator up to our head or examine our payments 133 00:09:10,990 --> 00:09:12,400 J.S. component. 134 00:09:12,400 --> 00:09:15,830 So let's take a quick break and then take care of that in the next section.