Well we've got a 50 percent solution to our problem.
So in this video I want to explain what the remaining problem is like the remaining 50 percent and then
describe how to fix it.
So as usual a quick diagram.
So here's what's now going inside of use location.
The very first time we call it are using fact took its ran inside there we call start watching and of
course inside of start watching at some point time we call watch position async right here.
So that essentially sets up some listener in our application something and says Hey Expo tell me whenever
are users location changes we can then imagine that at some point time use location gets called a second
time maybe this time there's no change in the callback because maybe it was not the recording piece
of state that changed.
So maybe use effect won't be called that particular time maybe then it gets re rendered or called a
third time and maybe during this time the callback function does change.
So use effectively then run a second time and inside there of course we will call start watching.
Now here's the issue we have now called start watching twice.
And between those two calls to it we have invoked watch position async twice.
So I don't necessarily know what Expo location does behind the scenes but without a doubt we have essentially
told it that we want to watch for changes in the user's location two separate times.
So does that mean that we're going to essentially get two separate updates.
I don't know but it could possibly mean that's the case it might mean that every single time that we
call watch position async we're always going to say give me another listener.
Another listener another listener.
And if we end up Collin's function like ten times we might eventually get like 10 different callbacks
registered in everyone those 10 might be invoked every single time a user's location gets updated.
Now again that might not be the case with Expo location but essentially with any other library that
would definitely be a risk maybe this function doesn't have that kind of vulnerability or I should say
vulnerability but that issue but it might be that we have some other very similar function that we're
making use of that has some similar problem.
So regardless of how watch position async actually works behind the scenes we should definitely make
sure that when we do a follow up call we somehow stop the previous time we were watching for changes
to the user's location change.
So how are we going to do that.
Well here's the idea the very first time that we call use location we are of course running use effect
whenever we call a U.S. fact and we pass in a function our inner functionally passing has the option
to return something called a clean up function.
This is a function that is meant to solve the exact scenario we are in.
Essentially if we have a use effect took as we do right here that starts up a listener or starts watching
something or starts some process then we can return a function from use effect that we can use to stop
that watching automatically series what goes on behind the scenes.
The very first time we call a location we'll call these effect.
We start watching then we're going to return a cleanup function inside that cleanup function we're going
to put in some amount of code to stop listening to the user's location.
We can then imagine that use location gets called a second time maybe there's no change to a callback
so use effect does not get called and then the third time where we do call use effect when we call use
effect it's going to automatically see that the last time we ran this use affect function like way back
over here.
It's going to see that we returned a cleanup function from the first time.
So before doing anything inside of our use affect function it's going to first call the cleanup function
that we returned from the very first call back over here so we can use that as our opportunity to do
a little bit of cleanup and make sure that we stop listening for changes to the user's location before
we start listening a second time.
So this essentially gives us the ability to easily clean up after ourselves and it's perfectly suited
for what we're trying to do Gates.
Let's make a little change.
We're going to return a cleanup function from our use effect function.
We're going to make sure that inside that cleanup function we stop listening to the user's location
before we start to listen to it.
Once again all right.
So inside of use location I'm going to add in a return statement and return a function like so.
So inside of here we're going to do some amount of cleanup.
For us our cleanup is going to be to call subscriber dot remove.
Remember that stops us ladies listening to updates from the user's location.
So inside of here we're going to first check to make sure that we have a subscriber and then we'll do
a subscriber dot remove like so.
Now the reason that we're checking to make sure that we have a subscriber.
Remember when we first initialize that piece of state we started off with the default value of null.
So there might be some kind of crazy scenario where we do not actually start listening to users location
and then actually run that function right there.
And that's actually very much possible if we ever call use location with a should track default value
of false.
That means we're going to fall into this case right here and we're essentially not going to have any
subscriber around.
So we might have a subscriber value of null in which case we would not want to call remove okay.
Let's try saving this I'll go to track rate again start recording.
Go to my terminal and once again just verify that I'm not like completely spanning this thing with updates.
And once again I should be able to tap on stop and see a very consistent number of locations have now
been recorded.
So this is definitely a good improvement.
We are now cleaning up after ourselves and making sure that we're not just constantly calling start
watching start watching start watching again and again and again.
All right.
So at this point we've got some code that definitely works but there's one last little thing inside
of your maybe one or two things.
I want to make sure it's really clear how we can kind of fix this issue and not run into it in the future.
And I also want to touch on the topic of the fact that we've got this subscriber piece of state inside
of here.
Maybe there would be a better way to handle it subscriber than storing it inside of a piece of state.
So let's take a quick pause and wrap up on use location in the next video.