> It's about "when this function executes, what data does it see, and did any of those values get changed out from under it in a way that could potentially break the logic"?
You're just describing the semantics of functions versus classes, and the consideration has existed long before hooks came around for exactly the reasons you describe. This discussion has also existed long before JavaScript, React, or hooks existed obviously. It's secondary to the discussion because function components have existed for a long time.
None of what you're saying changes the fact that replacing classes and lifecycles with hooks was done despite the fact that 99.9% of the API users would never care about the performance implications of classes, while that is precisely why the React team made the change. JavaScript is plenty composable with classes and without nested useEffect calls, which is one of the most absurd foot gun APIs that I have seen released in my entire career.
I'm legitimately curious. Can you point to a single actual source to cite "the React team made the change to hooks because of JS engine performance"? (and when you say "performance", you _are_ talking about literal instruction execution time / JIT behavior / etc, that sort of thing?)
I'm pretty deeply tied into the React ecosystem, and I honestly can't remember _ever_ seeing that mentioned as a justification.
If you can link me a reference with them saying that, I'd both be interested in reading it, but honestly surprised to see that stated at all.
You're just describing the semantics of functions versus classes, and the consideration has existed long before hooks came around for exactly the reasons you describe. This discussion has also existed long before JavaScript, React, or hooks existed obviously. It's secondary to the discussion because function components have existed for a long time.
None of what you're saying changes the fact that replacing classes and lifecycles with hooks was done despite the fact that 99.9% of the API users would never care about the performance implications of classes, while that is precisely why the React team made the change. JavaScript is plenty composable with classes and without nested useEffect calls, which is one of the most absurd foot gun APIs that I have seen released in my entire career.