[emerongi]

Hooks are a bit of a double-edged sword in my opinion.

On the one hand, they are nicely composable. You can make one hook call depend on another and you can easily build a lot of cool functionality thanks to this. On the other hand, you are no longer able to directly follow the flow of the code. Making a change to a series of hook calls can sometimes be scary to me as it can be hard to fully understand the cause-and-effect of that change.

On the one hand, you can hide a lot of complexity behind a simple `useSomething()` call, on the other hand the code inside `useSomething()` can be absolute horror, because all the stateful logic is handled through hooks. Any non-obvious use-case ends up being a mess of hook calls. If you only write the code once and never need to touch it again, `useSomething()` can be an amazing hook though. There are some hooks that I have written that I hope I (or anyone else) don't ever have to touch. I might just be a bad programmer though, or missing some obvious patterns.

TLDR: hooks work well, but they have downsides in terms of maintenance burden

[ssijak]

On the other end you can compose class components which have lifecycle methods which you need to jump through up and down the code to figure out the full behavior. Which to me is much more unreadable than hooks and effects. Not to mention that lifecycle methods have their own gotchas.

[madeofpalk]

> On the other hand, you are no longer able to directly follow the flow of the code.

Hooks are, at least as they're presented on the surface level, exceptionally functional, so shouldnt it be easier to directly follow the code? Just follow the function calls?

[sydd]

> There are some hooks that I have written that I hope I (or anyone else) don't ever have to touch.

If you need to make such statements something is very wrong. Either your code or with the design patterns you're forced into by your framework/library