Now let's take this to the next level and let's say once we have a response, I actually for whatever
reason want to set a timer of 2 seconds and only after these 2 seconds,
I'll print the response. So here I'll have another anonymous function, another callback in there
and in there, I console log posData. I have access to posData
because of that closure thing as you learned, this is a function nested inside of this function,
so this will work fine
but I only do it after 2 seconds, for, as I said, whatever reason.
So now we have basically a callback,
this one here in another callback which in the end is part of another callback,
so of track user handler which also is a callback of the event listener and we can already see that
this gets a bit hard to read over time, the more callbacks you nest, the harder your code can get to read
and maintain
and we'll have a look at this in a second, for now let's just see if it works.
If I save that and I reload and click track me and I click allow, it takes a while to get the position
and then it takes an additional 2 seconds because of the timer and only after this will show this
object.
Now the idea here really just is to show you that you can nest these operations, you can have an async
operation in an async operation but of course this timer is only kicked off once the location is there,
so once this outer callback function executed. It's also important to understand by the way
now that we speak about timers that if you set a timer here, so in track user handler but not inside of
getCurrentPosition but right before outputting this console log, if you execute this function
right away,
so if you set a timer of zero here, you will still see something interesting. If I console log timer
done here,
would you expect that this runs before getting position or thereafter?
Well let's find out, if I reload and click track me,
you see actually getting position ran first and then we saw timer done even though I set a timer
of zero
and the reason for that is related to what I explained a second ago.
We hand something off to the browser, no matter if it's an event listener, the position fetching or this
timer and then for the browser to execute the callback function, it always has to take the route over
the
message queue and the event loop
and therefore this code always executes first, this executes right away after set timeout executes
and even though the timer immediately finishes, this function still only executes after this line is done
and this by the way has one important implication,
this is the minimum time after which the callback function will be executed,
it's not the guaranteed time,
if it were guaranteed, it would need to run immediately. If we had the long running for loop here, then
this timer would only execute once the long running for loop is done which might take three seconds.
So this is not a guaranteed time, no matter if it's zero or 3000 or whatever it is,
it's not guaranteed, it's the minimum
and the same for set interval. It's the minimum where Javascript and the browser try to run this but
they are only able to run this function if the call stack is empty and if something is blocking the call
stack, that will go first.
So here, this line will always run first because this always has to take the route over the message queue
and the event loop.