[q7xvh97o2pDhNrh]

The entire hooks "thing" felt like a case of the library authors being too clever.

Having components with lifecycle methods called at known times by the framework is a perfectly straightforward mental model. It's worked just fine since the beginning of time. iOS still uses it.

I remember investing hours (and days and weeks) migrating old code to the "new way" or trying to get some simple thing "working with hooks." Other than being able to share in the authors' feeling of smugness over the unnecessarily-convoluted mental model when we finally got it all working, I genuinely can't recall any value we got out of the whole investment.

[flashback2199]

I agree. Hooks felt to me like an attempt to go all-in on functional programming when components are perhaps easier for many people to think about as classes due to the unavoidable need to have state in the component. It seemed like an attempt at purism that, instead of making things simpler, made them, at least cognitively, a bit more complicated due to the irreducible complexity of state.

[bilalq]

My experience has been the opposite. With hooks, it's now possible to decompose a concern and modularize it in full. Having logic for dealing with a concern spread over willMount/didMount/shouldUpdate/willUnmount was a total mess. It's bad enough with one concern, but if a component has 3 or 4 concerns that span across the lifecycle, it quickly became unwieldy. And for all the complains about people using `useEffect` wrong, I saw just as many people using setState calls in lifecycle methods and crazy things happening in mapStateToProps of class components.

In the end, hooks have greatly simplified things for me.

[dboreham]

It turns out much of s/w development is a cult (many cults) with no basis for their teachings.

[Izkata]

> Having components with lifecycle methods called at known times by the framework is a perfectly straightforward mental model. It's worked just fine since the beginning of time. iOS still uses it.

Android, too.