Well we can show a little circle to indicate where our user is which is definitely fantastic.
However there's still a little deficiency inside of our application.
I'm going to open up my location context file.
Here it is right here inside of ADD location.
I'm going to add a quick console log and just have it say something like Hi there or then save this.
Refresh my application go back to track create and then go check out those console logs at my terminal.
So inside my terminal I see.
Hi there start to appear.
OK.
Makes sense every time we get a location update.
We get a single console log.
But here's where something not so great starts to come into play.
I can go backward my application and navigate over two track list screen.
So on trackless screen now that we're here and we are not purposefully like recording a new track for
a user.
Ideally we would disable all of our location tracking stuff because right now it's just eating up battery
power even though we're not showing a map or the user's location or anything like that.
However if I go back over to my terminal I'm still getting a ton of different console logs so hi there.
Hi there.
And so on.
So at present even though we navigated away from that track create screen we're still maintaining a
lookup on the user's location.
Again not ideal because we don't want to burn excess battery power if we are not purposely creating
a new track very closely related to this idea of kind of toggling whether or not we're tracking a user's
location.
Remember we had also very briefly discussed the idea of extracting some of the location logic from chat
create screen into a reusable hook that we could call it use location so at this point I think it would
be a really good idea to start extracting all that location logic into a reusable hook and then we can
start to figure out how to disable the location tracking whenever a user navigates from chat create
screen as well.
So long story short let's start working on use location.
All right.
To get started.
I'm gonna go back over my code editor and remove that console log I put in there really quickly then
inside my SRT directory I'll make a new folder called hooks inside of hooks I'll make a new file called
use location dot J.S. so inside of here we're going to write out some amount of logic that's going to
start up the process of requesting permission to track users location do the error handling and then
start watching for a users change in location so inside of here I'm gonna do an import at the very top
for you state and use effect from react and then we're also going to get from the location library accuracy
request permissions async and watch position async
from Expo location then we can create an export our hook alright so remember this is a custom hook that
we're putting together we've seen one example already of how we extract logic into a separate hook file
or a separate hook helper function.
So we're going to do the same thing this time.
The general idea behind these reusable hooks is that we're going to go to some component like track
create screen and we're going to take a look at all the different variables we define inside of here
that we want to somehow make reusable where all the different logic that we want to make reusable.
So in our case we want to extract everything from this component track rate screen that has something
to do with handling location.
So at present we're going to go through this thing line by line.
I would say that this error piece of state right here is definitely tied to location because it's tied
to tracking whether or not there is an air during requesting permissions.
So I'm going to cut that line and put it put it into use location.
Next up the entire start watching function.
Yeah.
Without a doubt.
Hundred percent related to location.
So going to take the entire start watching function.
Cut it and put it into use location then use effect right here.
Yeah.
Hundred percent related to location so I can extract that.
I'm going to cut it and put it at the bottom of use location as well.
And now finally we're only left with some stuff that is not quite related to well tracking a user's
location.
You'll see right here we've got ADD location.
Yeah that's definitely related to tracking the user's location.
However that's a very specific use case of maintaining a user's location and it's not really related
to some reusable logic that we might want to use in the future.
Remember anytime we create a reusable hook like this we only want to put stuff inside there that we
expect to reuse possibly at some point.
Having a reference directly to add location and our location context not necessarily reusable because
we might work on another project where there is no location context where we might try to use this use
location hook on another screen where we don't care about the location context at all as well.
So now that we've got use location put together we need to start to think about what arguments it's
going to take in what is going to return in order to decide what it's going to return.
Remember we can go back to our track create screen and we can look up all the different variables inside
of our JSA X block that come from that hook.
The only thing inside of here that comes from that hook is the air value right there.
So inside of use location at the very bottom I can make sure that I return an array with air inside
of it recall that the only reason that we return in array right here is that we might want to eventually
return multiple different values.
There's nothing special about returning an array.
That's just the convention of hooks.
We could just as easily easily only return the air or we could return the air inside of an object like
so.
But in this case we're gonna follow convention and return it inside of an array
secondly what arguments does use location really require.
Well I think that at present the only thing that we really want to pass in here that we need to customize
and really make this thing reusable is the callback function right here.
The second argument to watch position async because whenever we make use of this hook will we probably
want to customize what happens whenever we get a new location.
So I'm going to assume that we are going to be able to pass in a callback to this hook and that we will
run that callback function rather than trying to call ad location right there.
Now anytime we get a position update we're gonna call callback okay.
That's pretty much our reusable use location hook.
So we now have a input of the callback function to run any time that we get an update and then we have
a return value from the hook of an error if one occurs during the permissions process.
Now we can save our hook.
Go back over to track create screen we can update some of the import statements inside of here and really
condense this thing down so we no longer need anything from Expo location.
We no longer need you state or use effect I will import the hook I just created.
So I will import used location from hooks use location and then right after we call our context right
here and get a reference to add location we can receive that ear value and call use location like so
and we'll make sure that we pass in a callback function to be ran anytime we get a new location.
So we want to take the location that we receive as the update from Expo location and just pass it directly
to add location.
Now we're once again in a scenario where we don't really have to make this extra helper function here
we could just pass in a reference directly to add location like so and that's pretty much it.
So I think you'll agree with me the logic is inside of track rate screen is now significantly less complex
than it was before.
Really easy to understand what's going on.
It's now any time that we have some project where we need to get access to a user's location and see
how it changes over time we could just import use location call it pass in some callback and then receive
some error if anything goes wrong when we tried to ask for permission.
So it looks pretty good not going to save it and just make sure that everything still works as expected
and yep looks like it sure does.
Okay.
So this is definitely a good extraction but we're still in our original scenario where we are not really
turning off our location tracking whenever we go to a different screen.
So let's try to figure out how to handle that in the next video.