I want to be helpful. Please read the following with that in mind.
----
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 as a short video?". Or if you prefer "Does this use the medium correctly to actually be good/helpful?"
And my impression, I'm sad to say, is that the answer is a very clear no.
I won't even discuss the fact that this is not a mistake I've seen senior engineers make. You may have. But how often? Anyway... There are some problems with your presentation.
The main problem is that you don't explain anything. You don't explain the problem, nor the cause of it, nor the solution.
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 at all. 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.
Then you demo the thing a bit. "If I change this to two, the counter increases by two". And, suddenly, again without any explanation at all, you duplicate the setCounter line. Why would you do that? 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?
And then you even claim "it still increases by two and not by four as you'd expect". 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 setCounter 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.
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 at all. The problem is not 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.
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.
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.
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.
----
So, again, trying to be constructive...
I'd say you need to improve a number of things.
First of all, start by defining your intended audience, what they should already know and what not.
Second, don't just make up 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.
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 won't know that obvious reason, they won't know what you mean by "it's just because it works this way; state rendering is bundled, obviously".
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.
Pretty cool that you took your time out to write some very useful tips so thanks a lot. It is my first video so definitely a very rogue in that aspect haha.
I’ll take it on board for the next video! Thanks
Annoying React useState mistake I've seen senior engineers make · HackerTrans
----
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 as a short video?". Or if you prefer "Does this use the medium correctly to actually be good/helpful?"
And my impression, I'm sad to say, is that the answer is a very clear no.
I won't even discuss the fact that this is not a mistake I've seen senior engineers make. You may have. But how often? Anyway... There are some problems with your presentation.
The main problem is that you don't explain anything. You don't explain the problem, nor the cause of it, nor the solution.
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 at all. 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.
Then you demo the thing a bit. "If I change this to two, the counter increases by two". And, suddenly, again without any explanation at all, you duplicate the setCounter line. Why would you do that? 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?
And then you even claim "it still increases by two and not by four as you'd expect". 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 setCounter 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.
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 at all. The problem is not 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.
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.
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.
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.
----
So, again, trying to be constructive...
I'd say you need to improve a number of things.
First of all, start by defining your intended audience, what they should already know and what not.
Second, don't just make up 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.
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 won't know that obvious reason, they won't know what you mean by "it's just because it works this way; state rendering is bundled, obviously".
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.