1 00:00:01,080 --> 00:00:06,020 All right we've got our code working but clearly this is a real nasty bug to find and fix. 2 00:00:06,030 --> 00:00:09,900 So in this video I want to give you a couple of tips on how we could have avoided getting in this scenario 3 00:00:09,900 --> 00:00:11,400 in the very first place. 4 00:00:11,430 --> 00:00:15,630 Now just so you know the tips that I'm going to share with you are coming from the REACT team themselves 5 00:00:15,640 --> 00:00:19,200 like the actual react developers if you open up the react documentation. 6 00:00:19,200 --> 00:00:24,150 They've actually got a section on hooks where they kind of go over this problem of dependencies changing 7 00:00:24,390 --> 00:00:29,220 and not really noticing it inside of helper functions we're inside of using fact functions as well. 8 00:00:29,850 --> 00:00:33,780 So let me show you some diagrams to essentially summarize the tips that they give. 9 00:00:33,790 --> 00:00:34,080 All right. 10 00:00:34,090 --> 00:00:35,810 So here's tip number one. 11 00:00:35,910 --> 00:00:41,740 Anytime that we have a use effect function that references a piece of states props or a context value 12 00:00:41,950 --> 00:00:44,410 we need to end them add them to our dependency list. 13 00:00:44,920 --> 00:00:49,570 So in this diagram let's imagine that we've got some prop called like track I.D. a piece of state called 14 00:00:49,570 --> 00:00:55,870 value or a piece of context called recording if we reference any of those inside of our U.S. fact function 15 00:00:56,110 --> 00:00:58,670 we should add them to our dependency array. 16 00:00:58,720 --> 00:01:03,350 So in other words this would be kind of ideal right here if we are referencing those values. 17 00:01:03,370 --> 00:01:05,710 Let's just make sure that we add them to the dependency right. 18 00:01:05,770 --> 00:01:10,600 So if they ever change we're going to get access to those latest values inside of our use effect function 19 00:01:11,470 --> 00:01:13,870 as a quick side note if we're making use of state. 20 00:01:13,960 --> 00:01:18,550 Remember when we initialize a state value we get both a value and a setter as well. 21 00:01:18,550 --> 00:01:21,760 So a setter like say set value these functions. 22 00:01:21,770 --> 00:01:26,750 These setter functions we do not have to add to that dependency list because the setter is actually 23 00:01:26,780 --> 00:01:30,500 a consistent function in memory unlike this value. 24 00:01:30,500 --> 00:01:33,960 Right here the setter is a very consistent function. 25 00:01:33,980 --> 00:01:38,670 We're not actually recreating that variable again and again and again. 26 00:01:38,720 --> 00:01:43,440 So this is a very easy way to avoid getting into the scenario we're just in if we ever reference proper 27 00:01:43,460 --> 00:01:44,480 context or state. 28 00:01:44,510 --> 00:01:47,460 Just make sure to add them to the dependency list. 29 00:01:47,510 --> 00:01:48,310 Tip number two. 30 00:01:48,320 --> 00:01:53,300 And this one's a little bit more applicable to us any time that we've got a helper function being defined 31 00:01:53,330 --> 00:01:55,340 inside of our component. 32 00:01:55,340 --> 00:02:00,770 Well we can very easily have that helper function reference say a prop or a piece of state or a piece 33 00:02:00,770 --> 00:02:02,090 of context. 34 00:02:02,210 --> 00:02:08,180 We do not want to generally add in functions like this outside of a use effect statement because it 35 00:02:08,450 --> 00:02:14,000 ends up with us having a very similar scenario where the helper function might be referencing some prop 36 00:02:14,030 --> 00:02:16,360 that's going to change over time. 37 00:02:16,400 --> 00:02:19,360 Now this just to be clear is kind of bad. 38 00:02:19,370 --> 00:02:23,270 Let me show you the solution to this and you're going to see why this is not necessarily something that 39 00:02:23,270 --> 00:02:28,610 we don't want to do is just something that is very easy to have us eventually introduce a bug into our 40 00:02:28,610 --> 00:02:29,780 code. 41 00:02:29,780 --> 00:02:35,270 So rather than defining a helper function inside of our component body we should instead define helper 42 00:02:35,270 --> 00:02:39,770 functions that get called from use effect inside of use effect. 43 00:02:39,770 --> 00:02:44,570 If we define these functions inside of use effect then that makes it really easy for you and I to do 44 00:02:44,570 --> 00:02:49,700 a visual scan over that function and look at all the different variables that it references we can then 45 00:02:49,700 --> 00:02:55,880 see like maybe in this case right here that this helper function references a prop called Track I.D.. 46 00:02:56,000 --> 00:03:01,520 So that would be a signal to you and I that we need to add track I.D. to our list of dependencies. 47 00:03:01,640 --> 00:03:07,340 Now again if we defined that helper function outside of use effect there's not any inherent issue it's 48 00:03:07,340 --> 00:03:12,350 just the fact that if we move that thing into use effect it makes it a little bit easier for us to look 49 00:03:12,350 --> 00:03:18,200 at this and say oh I'm inside of use effect and I have a variable that is a reference to a prop that's 50 00:03:18,200 --> 00:03:20,310 all it's just a little helper thing. 51 00:03:20,630 --> 00:03:22,010 And actually that would have helped you and I. 52 00:03:22,010 --> 00:03:27,830 Quite a bit in this particular scenario if we had moved start watching inside of use effect we could 53 00:03:27,830 --> 00:03:31,990 have very easily identified that the callback variable was a reference to a prop. 54 00:03:32,450 --> 00:03:36,960 And so callback should have been added to our dependency list with that in mind. 55 00:03:36,980 --> 00:03:43,130 Let's move our start watching function into use effect then we're going to say OK well we've got a reference 56 00:03:43,130 --> 00:03:44,560 to some prop right here. 57 00:03:44,690 --> 00:03:51,370 We should probably handle that somewhere else so I'm gonna take start watching I'm going to cut it and 58 00:03:51,380 --> 00:03:55,370 pasted at the very top of use effect like so. 59 00:03:55,390 --> 00:04:00,710 So now we would do once again a visual scan of this function we would notice oh we are referencing a 60 00:04:00,710 --> 00:04:03,380 prop right here inside of this helper function. 61 00:04:03,380 --> 00:04:08,300 So we need to add that prop to our dependency list and while in this case we already did. 62 00:04:08,300 --> 00:04:14,730 But like I just said this would have helped us find this issue way sooner inside of our project. 63 00:04:14,750 --> 00:04:18,980 Now one other thing I want to mention very quickly is if you take another look at our U.S. fact function 64 00:04:19,040 --> 00:04:24,040 there actually is another variable inside of here that is a reference to a state variable. 65 00:04:24,110 --> 00:04:29,870 So remember we set up a subscriber as a state variable right here and we've got a reference to it inside 66 00:04:29,870 --> 00:04:30,710 of use effect. 67 00:04:30,710 --> 00:04:34,130 We reference it right here and right here and right here as well. 68 00:04:34,370 --> 00:04:38,960 So technically we should also add subscriber to our dependency list. 69 00:04:38,990 --> 00:04:43,880 However there's a much better way to handle this subscriber variable than what we currently have. 70 00:04:44,120 --> 00:04:48,980 When you think about these subscriber variable there's really no reason to rebrand or our component. 71 00:04:48,980 --> 00:04:52,210 Whenever we get a subscriber back Just think about it. 72 00:04:52,280 --> 00:04:58,220 We only get subscriber once we start watching for a user's location we don't show or consume that subscriber 73 00:04:58,220 --> 00:05:00,800 in any way inside of a component. 74 00:05:00,890 --> 00:05:04,910 And in fact that variable is 100 percent localized to our hook. 75 00:05:04,910 --> 00:05:09,860 So rather than storing our subscriber inside of a piece of state there is actually a much better way 76 00:05:09,860 --> 00:05:11,170 that we could handle this. 77 00:05:11,360 --> 00:05:13,490 It's just a little bit more confusing syntax. 78 00:05:13,550 --> 00:05:19,080 That's the reason why we went with you state to begin with so as an alternative way to handle this I'm 79 00:05:19,090 --> 00:05:25,780 going to delete you state right there and then inside of use effect I'm going to define a variable at 80 00:05:25,780 --> 00:05:27,900 the very top with a let keyword. 81 00:05:27,920 --> 00:05:29,240 I'm going to call it subscriber. 82 00:05:29,290 --> 00:05:35,820 Like so now anytime that we get a subscriber back from watch position async we're going to assign it 83 00:05:35,820 --> 00:05:37,420 to that subscriber variable. 84 00:05:37,530 --> 00:05:45,670 So instead of con sub I'll say simply subscriber and we can then remove set subscriber. 85 00:05:45,890 --> 00:05:48,920 Finally we can clean up one last reference to set subscriber. 86 00:05:48,920 --> 00:05:50,590 Just a little bit down. 87 00:05:50,640 --> 00:05:52,640 So right here we've got a set subscriber. 88 00:05:52,670 --> 00:05:56,550 We'll update that to be just subscriber is no. 89 00:05:56,550 --> 00:05:59,560 Like so there's one other quick thing I want to do here. 90 00:05:59,570 --> 00:06:03,740 You'll notice that we are setting the value of subscriber to null in several locations. 91 00:06:03,740 --> 00:06:08,840 But then in several other locations we assume that subscriber is defined just a code a little bit more 92 00:06:08,840 --> 00:06:09,770 defensively. 93 00:06:09,770 --> 00:06:11,870 I'm going to wrap this subscriber call right there. 94 00:06:11,870 --> 00:06:17,530 The DOT remove with a quick check just to make sure that we have a subscriber and there's not necessarily 95 00:06:17,560 --> 00:06:19,150 a great reason to do this. 96 00:06:19,150 --> 00:06:22,930 In just about every scenario I really expect subscriber to be defined. 97 00:06:22,930 --> 00:06:27,070 It's just because we are eventually going to set it back to normal that I'm just coding defensively 98 00:06:27,070 --> 00:06:32,590 and assuming that I might have some subtle bug inside of here where some subscriber might be null when 99 00:06:32,590 --> 00:06:35,910 I expect it to be an actual subscriber object. 100 00:06:35,940 --> 00:06:36,170 OK. 101 00:06:36,200 --> 00:06:37,570 So now we've got this all put together. 102 00:06:37,600 --> 00:06:44,000 I'm going to save this and we'll do one last quick test so I can go over to track create. 103 00:06:44,250 --> 00:06:50,030 I'm going to start recording I'm going to go to my terminal and verify that I can see some numbers being 104 00:06:50,090 --> 00:06:51,210 printout printed up. 105 00:06:51,350 --> 00:06:55,800 So yeah looks like we're getting our different number of locations finally. 106 00:06:55,810 --> 00:06:56,550 I'll go back over. 107 00:06:56,560 --> 00:06:57,870 I'll hit stop. 108 00:06:57,970 --> 00:07:03,820 I'll try going between different screens and I don't see any bugs or any errors and I've got a very 109 00:07:03,820 --> 00:07:05,510 stable list of locations. 110 00:07:05,710 --> 00:07:08,050 So I think that we're now in a pretty good spot. 111 00:07:08,050 --> 00:07:08,290 All right. 112 00:07:08,290 --> 00:07:11,260 So now we've got our use location put together. 113 00:07:11,260 --> 00:07:14,140 Well let's take a quick pause right here and continue in the next video.