All right we've got our code working but clearly this is a real nasty bug to find and fix.
So in this video I want to give you a couple of tips on how we could have avoided getting in this scenario
in the very first place.
Now just so you know the tips that I'm going to share with you are coming from the REACT team themselves
like the actual react developers if you open up the react documentation.
They've actually got a section on hooks where they kind of go over this problem of dependencies changing
and not really noticing it inside of helper functions we're inside of using fact functions as well.
So let me show you some diagrams to essentially summarize the tips that they give.
All right.
So here's tip number one.
Anytime that we have a use effect function that references a piece of states props or a context value
we need to end them add them to our dependency list.
So in this diagram let's imagine that we've got some prop called like track I.D. a piece of state called
value or a piece of context called recording if we reference any of those inside of our U.S. fact function
we should add them to our dependency array.
So in other words this would be kind of ideal right here if we are referencing those values.
Let's just make sure that we add them to the dependency right.
So if they ever change we're going to get access to those latest values inside of our use effect function
as a quick side note if we're making use of state.
Remember when we initialize a state value we get both a value and a setter as well.
So a setter like say set value these functions.
These setter functions we do not have to add to that dependency list because the setter is actually
a consistent function in memory unlike this value.
Right here the setter is a very consistent function.
We're not actually recreating that variable again and again and again.
So this is a very easy way to avoid getting into the scenario we're just in if we ever reference proper
context or state.
Just make sure to add them to the dependency list.
Tip number two.
And this one's a little bit more applicable to us any time that we've got a helper function being defined
inside of our component.
Well we can very easily have that helper function reference say a prop or a piece of state or a piece
of context.
We do not want to generally add in functions like this outside of a use effect statement because it
ends up with us having a very similar scenario where the helper function might be referencing some prop
that's going to change over time.
Now this just to be clear is kind of bad.
Let me show you the solution to this and you're going to see why this is not necessarily something that
we don't want to do is just something that is very easy to have us eventually introduce a bug into our
code.
So rather than defining a helper function inside of our component body we should instead define helper
functions that get called from use effect inside of use effect.
If we define these functions inside of use effect then that makes it really easy for you and I to do
a visual scan over that function and look at all the different variables that it references we can then
see like maybe in this case right here that this helper function references a prop called Track I.D..
So that would be a signal to you and I that we need to add track I.D. to our list of dependencies.
Now again if we defined that helper function outside of use effect there's not any inherent issue it's
just the fact that if we move that thing into use effect it makes it a little bit easier for us to look
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
all it's just a little helper thing.
And actually that would have helped you and I.
Quite a bit in this particular scenario if we had moved start watching inside of use effect we could
have very easily identified that the callback variable was a reference to a prop.
And so callback should have been added to our dependency list with that in mind.
Let's move our start watching function into use effect then we're going to say OK well we've got a reference
to some prop right here.
We should probably handle that somewhere else so I'm gonna take start watching I'm going to cut it and
pasted at the very top of use effect like so.
So now we would do once again a visual scan of this function we would notice oh we are referencing a
prop right here inside of this helper function.
So we need to add that prop to our dependency list and while in this case we already did.
But like I just said this would have helped us find this issue way sooner inside of our project.
Now one other thing I want to mention very quickly is if you take another look at our U.S. fact function
there actually is another variable inside of here that is a reference to a state variable.
So remember we set up a subscriber as a state variable right here and we've got a reference to it inside
of use effect.
We reference it right here and right here and right here as well.
So technically we should also add subscriber to our dependency list.
However there's a much better way to handle this subscriber variable than what we currently have.
When you think about these subscriber variable there's really no reason to rebrand or our component.
Whenever we get a subscriber back Just think about it.
We only get subscriber once we start watching for a user's location we don't show or consume that subscriber
in any way inside of a component.
And in fact that variable is 100 percent localized to our hook.
So rather than storing our subscriber inside of a piece of state there is actually a much better way
that we could handle this.
It's just a little bit more confusing syntax.
That's the reason why we went with you state to begin with so as an alternative way to handle this I'm
going to delete you state right there and then inside of use effect I'm going to define a variable at
the very top with a let keyword.
I'm going to call it subscriber.
Like so now anytime that we get a subscriber back from watch position async we're going to assign it
to that subscriber variable.
So instead of con sub I'll say simply subscriber and we can then remove set subscriber.
Finally we can clean up one last reference to set subscriber.
Just a little bit down.
So right here we've got a set subscriber.
We'll update that to be just subscriber is no.
Like so there's one other quick thing I want to do here.
You'll notice that we are setting the value of subscriber to null in several locations.
But then in several other locations we assume that subscriber is defined just a code a little bit more
defensively.
I'm going to wrap this subscriber call right there.
The DOT remove with a quick check just to make sure that we have a subscriber and there's not necessarily
a great reason to do this.
In just about every scenario I really expect subscriber to be defined.
It's just because we are eventually going to set it back to normal that I'm just coding defensively
and assuming that I might have some subtle bug inside of here where some subscriber might be null when
I expect it to be an actual subscriber object.
OK.
So now we've got this all put together.
I'm going to save this and we'll do one last quick test so I can go over to track create.
I'm going to start recording I'm going to go to my terminal and verify that I can see some numbers being
printout printed up.
So yeah looks like we're getting our different number of locations finally.
I'll go back over.
I'll hit stop.
I'll try going between different screens and I don't see any bugs or any errors and I've got a very
stable list of locations.
So I think that we're now in a pretty good spot.
All right.
So now we've got our use location put together.
Well let's take a quick pause right here and continue in the next video.