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 co...
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.
2 comments
[ 3.0 ms ] story [ 18.3 ms ] thread----
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 co...
I’ll take it on board for the next video! Thanks