The best way of thinking about hooks I've seen is they're an attempt to describe all possible states of the component at once, right in the render function. In

The best way of thinking about hooks I've seen is they're an attempt to describe all possible states of the component at once, right in the render function. Instead of tracing through various imperative lifecycle handlers to see how side effects are handled, you have them all in one place. It's kind of a declarative(ish) approach to side effect management. I personally like hooks and think they achieve this goal pretty well. The API is good, the abstraction maps over decently once you've grokked it (though this is honestly non trivial), and they end up simplifying 80%+ of common usecases. But... I think it comes with a huge caveat. To consume, hooks are much quicker, easier, cleaner, etc. To write, I'd say less so. The problem is that in order to write and debug custom hooks, you have to deeply understand both the underlying component lifecycle model and the mapping onto the hooks API. This naturally makes creating, modifying and debugging hooks that bit harder than working directly with lifecycle methods in the class model, where there's one layer less of abstraction to deal with.