I would pass state as an argument to render. The function should not just conquer the global variable without asking. Otherwise you have no benefit of all this exercise. You are still not in control of the state. When you pass the state to the render function, you would also not need hoisting, which in my opinion makes the code a bit unreadable. I would rename the global setState function to setStateAndRender but the function argument of viz not. That makes the two abstraction levels that you have more clear and visible.
In my opinion this example is not so good. You blindly implement what you know from React without thinking if this is appropriate or not. This structure makes only sense when your event and your effect are far away from each others. You should choose this structure in order to reduce the sphaghetti-ness of the code, which pulls strings criss cross through your project. But in the example you don't have this. You create it. Your first solution even had the opposite of this. It is the principle of locality. You had the definition of the svg and right there you have defined the handler on it and right there you have defined the effect and right there you have the thing the effect is about. That is already perfect. And you also said, in this case it is not bad. But then the example is just bad for what you try to explain. I know, there are other good reasons why your solution is actually better, and I don't question this. But I don't think, persons who watch this video, actually understand them or that they learn the basic idea behind this. You just said at 5:13 "I would like to introduce a pattern here." For the audience it may look very uninspired. You just apply this pattern, because you learnt it from a text book or because this is how React does it. And now you pull it out of the hat and confront the audience with it. But anyway, the vidoe is very good! Thanks a lot!
This is great feedback, thank you so much! You are probably right that I introduce the pattern too early, before the need for it becomes clear. I think I need to follow the teaching principle of "Just in Time not Just In Case", because you're correct that the pattern does not provide any clear benefit with such a small example. Perhaps it's best to wait until the examples get more complex, with more "moving parts" regarding tracking state (such as with multiple linked views), and only then introduce this pattern, so that its benefits are more clear. I really appreciate your feedback here, thank you so much!
