If I want to update the location hash manually - that is, I want my application to manipulate the location hash - I'll usually do something like this:
- Turn OFF location hash monitoring.
- Set internal hash.
- Set location hash.
- Turn ON location hash monitoring.
I turn off the location hash monitoring while updating the internal hash because I am worried that my monitoring interval will catch me in between steps 2 and 3: where I have updated the internal hash, but have not yet updated the location hash. I am worried that this will inaccurately detect a change in the location hash.
This fear is irrational.
This scenario does not exist.
I know this rationally; but, as I just said, the fear is irrational. To try and cure myself of the fear, I put together a quick demo that tries to put my fear to the test. In the following code, we're going to monitor the location hash. And, we're going to update the internal hash and the location has without pausing the monitor. And, we're going to try to waste a lot of time in between those two steps.
NOTE: You can see this in the video.
Hopefully this exploration will be enough immersion therapy to put my event loop anxiety to rest.
That was a short, but highly informative video. In fact, I've often steered clear of setInterval and setTimeout for just this reason. So if I can extend the argument logically, does this mean that setInterval waits for its bound function to be the only function on the call stack before executing the next iteration?
great post, this should help those of us who suffer irrational eventusansaphobia (fear of the event loop). personally, just knowing that the complete execution of the handler takes precedence over the clock puts my mind almost 100% at ease. almost.
I can't say that I know how things get chosen to run; but, what I can say is that when the callback in setTimeout() / setInterval() is running, you can be *sure* that it's not conflicting with code outside of the callback.
Thanks! Hoping to put all of our minds at ease :D