1 00:00:00,660 --> 00:00:05,150 Our application now has two pieces of state that e-mail and the password. 2 00:00:05,160 --> 00:00:09,980 So in theory once a user enters these we're ready to actually sign them into our application. 3 00:00:10,050 --> 00:00:14,260 So the next thing we need to work on is figuring out how do we actually sign in a user right. 4 00:00:14,430 --> 00:00:18,550 Well as we figure out in the past we use firebase to authenticate our user. 5 00:00:18,900 --> 00:00:25,200 But thinking about authentication I just kind of thinking about it in general I'm starting to think 6 00:00:25,200 --> 00:00:30,960 that maybe our author reducer is going to need to maintain a couple of their properties in here beyond 7 00:00:30,960 --> 00:00:32,850 just email and password. 8 00:00:32,880 --> 00:00:38,370 So let's check out a mock up on the left hand side is what our state currently is like what it looks 9 00:00:38,370 --> 00:00:41,610 like when we run our application we have just e-mail and password and nothing else. 10 00:00:41,610 --> 00:00:42,930 That's it. 11 00:00:43,050 --> 00:00:47,280 What I'm going to propose for our application state. 12 00:00:47,280 --> 00:00:54,660 We're going to propose our author douceur comes in to responsibility for is a loading flag an error 13 00:00:54,660 --> 00:00:57,180 message and a user model. 14 00:00:57,240 --> 00:01:00,710 So let's talk about each of these really quick where we know what the e-mail password are. 15 00:01:00,720 --> 00:01:03,520 Those are just the strings that the user is entering. 16 00:01:03,520 --> 00:01:05,030 How about the loading flag here. 17 00:01:05,190 --> 00:01:07,560 This Ludi flag is to me just like the one we previously had. 18 00:01:07,560 --> 00:01:09,630 It's going to be a boolean either true or false. 19 00:01:09,660 --> 00:01:14,220 And it's just going to record whether or not we are currently trying to authenticate the user. 20 00:01:14,220 --> 00:01:16,930 So the purpose of loading right here is just so we can show spin. 21 00:01:17,010 --> 00:01:17,370 That's it. 22 00:01:17,370 --> 00:01:19,230 Nothing crazy. 23 00:01:19,230 --> 00:01:22,050 The air flag again is just is a string. 24 00:01:22,080 --> 00:01:26,430 It's going to record whether or not there is a error in authentication. 25 00:01:26,430 --> 00:01:31,080 So just the strings can say something like authentication failed or whatever. 26 00:01:31,110 --> 00:01:36,480 We feel like getting a message to now the last one is a little bit more interesting user. 27 00:01:36,660 --> 00:01:41,320 So user here is going to be the user model that is supplied by firebase. 28 00:01:41,370 --> 00:01:43,920 So we'll learn a lot more about this in just a little bit. 29 00:01:43,920 --> 00:01:49,290 For right now just take my word for it that this user property is going to be an object that tells us 30 00:01:49,290 --> 00:01:54,060 stuff like here's what the currently signed in user's username and ideas. 31 00:01:54,060 --> 00:02:00,570 So just a short description is an object as a short description of our user who is signed in. 32 00:02:00,570 --> 00:02:06,350 So all in all I am suggesting that we expand the properties of a producer Orsini the properties that 33 00:02:06,360 --> 00:02:09,250 reduce or mix by adding in these last three on here. 34 00:02:09,640 --> 00:02:16,200 That is what I'm suggesting that we do so of course because we want to update our application state. 35 00:02:16,200 --> 00:02:22,320 We're going to need to toss in some action creators and types and all that other good stuff to manage 36 00:02:22,320 --> 00:02:26,720 these properties right so we can like actually change the loading flag an error flag in the user like 37 00:02:26,730 --> 00:02:28,510 all that kind of good stuff. 38 00:02:28,530 --> 00:02:33,930 So now that we know what the properties we want to maintain Are we can start to think about when we 39 00:02:33,930 --> 00:02:35,720 want to update each of them. 40 00:02:36,130 --> 00:02:36,580 OK. 41 00:02:36,750 --> 00:02:41,130 Want to think about when we're going to update each of those flags. 42 00:02:41,130 --> 00:02:42,210 So email and password. 43 00:02:42,210 --> 00:02:45,210 We've already done and those two are kind of obvious right. 44 00:02:45,210 --> 00:02:50,310 Whenever user types something in the email field I want to update my email whenever the user types something 45 00:02:50,310 --> 00:02:54,190 the password field I want to update my password password piece of state. 46 00:02:54,420 --> 00:02:55,900 But these new three down here. 47 00:02:55,910 --> 00:02:58,770 Well they're a little bit different weren't they. 48 00:02:58,770 --> 00:03:00,380 They're a little bit different. 49 00:03:00,400 --> 00:03:05,160 The loading flag will probably start off as something like null because or false because by default 50 00:03:05,190 --> 00:03:07,730 when the user first starts the application up. 51 00:03:07,890 --> 00:03:10,210 Yeah you know we're not actually loading anything just yet. 52 00:03:10,290 --> 00:03:13,740 So probably start to false or whatever. 53 00:03:13,740 --> 00:03:19,020 But once an authentic quake authentication request starts we're going to flip it over to true and then 54 00:03:19,020 --> 00:03:23,400 very importantly this is like the real world and trying to hammer in here what I'm trying to get at 55 00:03:23,970 --> 00:03:28,530 is when the request is complete when like the signing request is complete we're going to flip it back 56 00:03:28,530 --> 00:03:29,540 to false. 57 00:03:29,940 --> 00:03:30,510 OK. 58 00:03:30,510 --> 00:03:35,640 So when the request is complete I want to change this value of this piece of state right here. 59 00:03:37,470 --> 00:03:38,730 Same thing with the error message. 60 00:03:38,730 --> 00:03:40,380 By default I mean empty string. 61 00:03:40,560 --> 00:03:46,050 But when the error or when the authentication request is complete I want to get an error message and 62 00:03:46,050 --> 00:03:48,710 maybe you know update this to show the user an error message. 63 00:03:48,960 --> 00:03:50,660 And the same with the third one here as well. 64 00:03:50,670 --> 00:03:54,270 By default it might be like nold to say no user is signed in right now. 65 00:03:54,570 --> 00:04:01,140 But when the authentication request is complete I want to put the user model in there as this property 66 00:04:02,690 --> 00:04:10,810 so the common the common theme here the goal with these last three poverty's is that after a user or 67 00:04:10,820 --> 00:04:16,030 after we make a request to the firebase server we want to update our application state. 68 00:04:16,050 --> 00:04:16,680 OK. 69 00:04:16,840 --> 00:04:18,290 That's the goal. 70 00:04:18,770 --> 00:04:20,040 But no problem with that. 71 00:04:20,090 --> 00:04:20,780 Right. 72 00:04:20,800 --> 00:04:23,080 Like we know how to update our application state. 73 00:04:23,090 --> 00:04:26,450 We make an action Creator and we return in action. 74 00:04:26,780 --> 00:04:29,350 And our end user updates something like Whatever. 75 00:04:29,450 --> 00:04:30,770 What's the big deal here. 76 00:04:31,190 --> 00:04:34,340 Well maybe it's not so simple. 77 00:04:34,340 --> 00:04:37,550 I want to point out some little little issue here. 78 00:04:37,550 --> 00:04:42,050 So first just to make sure everything is crystal clear about this kind of set up this prep I'm trying 79 00:04:42,050 --> 00:04:43,210 to do here. 80 00:04:44,000 --> 00:04:49,970 I want to just be very clear very direct with you whenever user presses out logon button right there 81 00:04:50,060 --> 00:04:51,390 when they press it. 82 00:04:51,500 --> 00:04:56,760 We're going to call something like a log in user action creator with email and password and that creator 83 00:04:56,850 --> 00:05:00,660 is going to make a request to sign that user and I like to log them in. 84 00:05:00,800 --> 00:05:05,480 Now that were the again the part them trying to make real quick crystal clear right here is that this 85 00:05:05,480 --> 00:05:10,400 action creator must by definition be making an Ajax request. 86 00:05:10,400 --> 00:05:11,510 Right. 87 00:05:11,600 --> 00:05:13,700 So it's going to make an Ajax request. 88 00:05:13,710 --> 00:05:18,230 And until that request succeeds or fails until it completes. 89 00:05:18,230 --> 00:05:23,060 We don't really know what action we want to return from that action creator and that's what I'm really 90 00:05:23,060 --> 00:05:24,240 trying to get here. 91 00:05:24,290 --> 00:05:30,860 So I'm really trying to get at by default whenever we like as all the acting creators we've proved so 92 00:05:30,860 --> 00:05:33,530 far behave when we call an action creator. 93 00:05:33,600 --> 00:05:34,650 It runs. 94 00:05:34,810 --> 00:05:35,870 We return in action. 95 00:05:35,870 --> 00:05:36,210 Boom. 96 00:05:36,210 --> 00:05:36,700 Here's the Ox. 97 00:05:36,710 --> 00:05:40,430 We call it runs it get the action back toss off to the producer. 98 00:05:40,550 --> 00:05:44,240 Instantaneous no delay whatsoever. 99 00:05:44,480 --> 00:05:51,710 But with this new idea this new request that I want to make things behave a little bit differently when 100 00:05:51,710 --> 00:05:59,480 we call the action Creator it runs we make a request to firebase and say wait a minute we don't actually 101 00:05:59,480 --> 00:06:01,000 have anything to return yet. 102 00:06:01,310 --> 00:06:04,450 Remember Ajax requests are asynchronous. 103 00:06:04,490 --> 00:06:08,290 So inside that action creator we have no value no action return. 104 00:06:08,290 --> 00:06:12,680 Nothing to say like hey here's the user the user is going to come in a minute. 105 00:06:12,680 --> 00:06:16,760 Like just hold on don't actually return to the action yet like we don't know what it is yet. 106 00:06:16,850 --> 00:06:20,860 Only at some time in the future when the request is complete. 107 00:06:20,870 --> 00:06:23,850 Can we actually return an action that is when trying to get out here. 108 00:06:24,050 --> 00:06:31,070 So when we have action creators that make Ajax requests things behave a little bit differently and our 109 00:06:31,070 --> 00:06:37,190 existing pattern of call the action create or in turn action starts to break down because when we make 110 00:06:37,190 --> 00:06:41,460 an Ajax request we don't immediately have anything to return from this function. 111 00:06:41,510 --> 00:06:48,310 And remember in javascript there is no such thing as like sleep or weight or anything like that. 112 00:06:48,380 --> 00:06:53,230 When this action creator runs it's going to execute the coding side of it and then immediately return. 113 00:06:53,240 --> 00:06:55,530 And there is nothing you can do to stop that. 114 00:06:55,620 --> 00:07:01,160 So there's no fancy way that we can somehow like say oh make Ajax request a write up here but don't 115 00:07:01,160 --> 00:07:02,520 return anything just yet. 116 00:07:02,530 --> 00:07:05,650 Like just give me a minute to like figure out what this value should be. 117 00:07:05,750 --> 00:07:13,010 So clearly our existing pattern for action creators is not going to work when it comes to making Ajax 118 00:07:13,010 --> 00:07:13,760 requests. 119 00:07:13,760 --> 00:07:16,770 Clearly we need some new methodology here. 120 00:07:16,860 --> 00:07:22,220 We need some new way of handling action crater's that's going to help us to make an Ajax request and 121 00:07:22,220 --> 00:07:27,830 then at some point in the future maybe dispatching action to say loading is complete. 122 00:07:27,980 --> 00:07:29,750 Here's the error message if there is one. 123 00:07:29,870 --> 00:07:30,920 And here is the user. 124 00:07:30,920 --> 00:07:37,750 If there is one OK so when I saw I'm just condenses all down to a single sentence give you the summary. 125 00:07:37,760 --> 00:07:43,230 The big problem here is that we've been writing synchronous action creators that instant return in action 126 00:07:43,430 --> 00:07:49,370 but we need to be to write an asynchronous action creator that will return an action at some point in 127 00:07:49,370 --> 00:07:50,260 the future. 128 00:07:50,570 --> 00:07:53,300 So of course this is not an original problem. 129 00:07:53,300 --> 00:07:57,800 Like I didn't just stumble across this redux has our back on this one. 130 00:07:57,830 --> 00:08:01,210 Let's discuss how we're going to solve this in the next section.