I want to be helpful. Please read the following with that in mind.<p>----<p>I don't want to throw the question of "Does this really need to be a video?", because, well, you seem to have built this idea of "coding shorts" and it wouldn't make much sense to call it that if they weren't videos. I also don't want to challenge the duration because, again, well, they are "shorts". But then again, I'll ask "Is this good/helpful <i>as a short video</i>?". Or if you prefer "Does this use the medium correctly to actually be good/helpful?"<p>And my impression, I'm sad to say, is that the answer is a very clear <i>no</i>.<p>I won't even discuss the fact that this is not a mistake I've seen senior engineers make. <i>You</i> may have. But how often? Anyway... There are some problems with your presentation.<p>The main problem is that you don't <i>explain</i> anything. You don't explain the problem, nor the cause of it, nor the solution.<p>In fact, there's a point, starting at around 0:15, where you remain silent and just move the mouse around, clicking, expecting the viewer to... I don't really know what you expect of them. I mean, if the viewer is supposed to be familiar with that sort of code, you don't need that <i>at all</i>. You would just say "...increases the counter every time the button is clicked" and simply continue. If you don't expect them to be familiar with that, then they will gain nothing from moving the mouse around silently clicking here and there.<p>Then you demo the thing a bit. "If I change this to <i>two</i>, the counter increases by <i>two</i>". And, suddenly, again without any explanation at all, you duplicate the setCounter line. <i>Why would you do that?</i> We don't know. You just do. And so, when the problem you wanted to show appears, we don't know why it would appear in real life. I mean, why would someone duplicate that line to increase by four instead of just doing the exact thing you did a couple of seconds ago and change the 2 to a 4?<p>And then you even claim "it still increases by two and not by four <i>as you'd expect</i>". But why would the viewer expect that at all? In fact, I'd argue most people -or at least a large percentage- would see the duplicated call and just think "duh, why <i>setCounter</i> to the same value again?". So, again, you are assuming some expectation from the viewer without explaining in any way why would they expect that.<p>Ah! "The reason for this...", now we're getting some explanation. "...is the way that React works." Oh... "React bundles rendering state together; each setCounter does not correlate to a DOM update". Well, but that doesn't seem to be the problem <i>at all</i>. The problem is <i>not</i> that the UI is updated out of sync or something like that. If the problem was about the value and the DOM being out of sync, then at some point the updated value would be reflected somehow. So the explanation leaves the viewer with a confused impression. It is also given offhandedly as if of course they were supposed to know that, which kind of makes the video pointless.<p>The actual problem is that the value is being updated twice, but with the same value both times. That when you call setCounter, counter itself does not get immediately/reactively/magically updated, and so if counter is, say, 8, you're calling setCounter(8+2) and again setCounter(8+2) a second time.<p>Finally, you offer a solution: "do something like this". Again, no explanation. Not only no explanation of what -well, you just write the code, so let's assume the viewer clearly sees what the change it- but more importantly no explanation at all of why. No explanation of why using a function changes things, of why it now works.<p>All in all, I'm sorry to say this but it feels like the poster image for the video -you know, the one with the bad code on the left and good code on the right- gives just as much information -or as little, really- as the whole video itself.<p>----<p>So, again, trying to be constructive...<p>I'd say you need to improve a number of things.<p>First of all, start by defining your intended audience, what they should already know and what not.<p>Second, don't just <i>make up</i> a problem, present and explain an existing one. That means that you don't just duplicate that line with no explanation, instead you do the complete opposite: you explain why and how someone would be walking into the problem.<p>Then once you've shown the problem, first give an accurate explanation of why the problem occurs. Here the key is the first point, knowing your audience. If someone were to walk into such a problem, they <i>won't know that obvious reason</i>, they won't know what you mean by "it's just because it works this way; state rendering is bundled, obviously".<p>And finally, once you've explained the problem and go onto giving a solution, again, explain that solution, what it changes and why the change is actually significant in the context of the problem.