[TameAntelope]

> Most of those issues never manifest to the end-user, but incorrect code that is not a bug today will, eventually.

No... what? Could not disagree more with this sentiment; this is the "for the love of the game" kind of stuff that completely loses focus on why we write code in the first place; to make money. Very, very few people have the resources to care about this level of problem, and far more often people who don't have the resources end up spending them on useless "improvements" like what's discussed in the article, rather than building things that users can use (or that make it easier to build things users can use).

Hooks are surely flawed, in the same sense that literally everything in software is flawed. The point is not to select a way of writing code that doesn't have flaws; the point is to select a way of writing code that has flaws you can live with.

Hooks have flaws, but hooks also have benefits that make writing software meaningfully easier. Losing sight of that is a great way to write an article that complains about problems that never impact the user's experience.

It's just such a big red flag when someone talks about "incorrect code" that doesn't impact the user in any way. Huge, gigantic waving red flag.

[masylum]

Maybe I expressed it incorrectly. When the code is incorrect, it fails in the future. So the user will notice it. This happens when your code relies on some context to work (for instance, if it relies on how the data structure was allocated somewhere up the component hierarchy). When the context changes, then that piece of code starts failing, therefore impacting users.

[TameAntelope]

But now it just sounds like you're saying, "When the code changes, the code changes." which feels obvious?

Of course when you change some of the code without changing other parts that rely on the original code, it will break. I'm not sure why that's unique to hooks.