Asynchronous tasks inside React.useEffect can create Stale Closure BUGS! 

It's in the queue!

Thanks 🤗

Glad it helped! There's a couple of gotchas with useEffect, but once you know, they're not too bad!

The copy is a good way of thinking about it, so if that value in the closure is updated, it is updated only inside that closure. It's similar to passing a value to a function. function abc(x) { x = 123 }. In this example x (the copy) inside of the function is changed, but outside the function, nothing has been changed. The ref is able to change because it's an object. Also similar to a function. function abc(x) { x.current = 123 }. In this example, x is mutated and so the value outside the function is also modified.

It's less than ideal and there may be better solutions. The ref contains the real value but updates won't trigger a rerender. Updating the state will trigger a rerender, but may contain stale values. ¯\_(ツ)_/¯

In other situations, this would be fine. But for this specific case, the code is using a timer (setInterval). When cancelling / re-initializing the timer on each state change, the timer could count too quickly or too slowly. In other words, the interval could tick off beat. The useInterval from that article is a better approach and basically the next step from this video (for setInterval), which is to extract the `setInterval` code into it's own hook. I didn't demo a solution like the `useInterval` because the problem I was demonstrating isn't limited to `useInterval`. It's a problem with all asychronous code inside of `useEffect`. For example, if there was a `fetch` request, or another Promise or a callback, the same stale state problems would exist. `setInterval` was just a quick way of adding async code for a demo. Cheers 🍻

@@JoelCodes I see why you're worried about it ticking too fast or too slow. You don't want to go super in-depth like useInterval but you're also worried about very granular things like interval ticking "off-beat". I think the interval would be very very close - as close as it could be. It will never be exactly 1s, as you would have to take into account of React's rendering and reconciliation (which takes cycle, more if render is batched), and browsers' own event loop. So accounting just for React's update life-cycle, and setting a new timer each second, while it feels icky, shouldnt be something we'd worry about in the average use-case, esp in tutorials. Just my 2c though!

For this example this would be a good solution, control the updating from within the setCount! But this solution won't work if your condition needed to reference values from other states.

Oh hey thanks! I really appreciate that! The theme is called moonlight and the font is FiraCode. It's one of my favorite setups! Hope to see you around. Cheers! 🍻

Ya I get that. I definitely understand. The tooling is improving. Which I guess means you aren't the only one who feels that way.