[bilalq]

> I also see sooo many issues when reviewing code like leaked event listeners, unstable props causing re-renders, etc. And these issues show up from teammates who otherwise write impeccable and trustworthy PRs in other regards.

I think this is true. However, I don't think I saw less bugs with `component(Did|Will)(Mount|Update|ReceiveProps)`. Lifecycle events are intrinsically about state management, and that has always been the root cause of many bugs. This isn't a React specific problem either. Back in AngularJS 1.2.x days, the $scope and digest cycle was the source of many bugs. In Backbone, people's two-way binding between views and models were the source of many bugs.

Are React hooks complex? Yes. I don't think they're worse than what existed before though.

[totaldex]

I don't entirely agree - the old React way was verbose and explicit about when events are executed. This allowed developers to more concretely reason about logical workflows in applications.

With hooks, we traded verbosity for a single interface that does it all (assuming you know how to hook up your dependencies correctly, or compose helper hooks to manage state comparisons). Hooks allow you to do mostly anything lifecycle methods did, but they're a lot trickier to reason with, review, and develop.

This all goes away if all your developers are functional maestros - in practice, it's lead to buggier code across our various frontends.

[bilalq]

My experience has been pretty different. With lifecycle methods, you had the implementation details of a single concern split across the constructor, multiple lifecycle handlers, and sometimes even the render function when refs were involved. Hooks can express full concerns in a reusable way. This is a valuable abstraction that previously required complex higher order components to do.

People would also constantly get tripped up over `this.props` and `this.state` when it came to computed state values. Now a simple `useMemo` simplifies and expresses that intent way better than setting something conditionally in the constructor and doing a bunch of conditional checks on componentWillUpdate before calling this.setState again.

Edit:

Oh, and the improvements with Redux are life-changing. The `useTypedSelector` UX is so much better than writing a mapDispatchToProps, mapStateToProps, and then having a bunch of merging ceremony there.

[totaldex]

I'd chalk it up to a difference of opinion then - I like simplicity, but I'd take verbose clarity over it any day. Having to explain to newer engineers the nuances of hooks (and the permutations required to wrangle them in) is harder for me than saying "this exact lifecycle method is what you're looking for, take a look at its documentation".

[spoils19]

Chalk it up, then. I've never had a problem explaining the nuances of hooks, and there isn't actually that many permutations needed to wrangle them in indeed - but our engineers are usually quite quick to pick these things up and understand the interface without having to worry about the implementation anyway.

[thawaya3113]

It is a challenge for many developers. It’s taking developers I work with between 2-5 months to really grok it.

So if you’re working on multiple tiny changing projects, or with contractors who are only gonna be around for 6-12 months, it’s possibly not worth it.

But if you’re working on a project that needs to stick around, and the people you’re working with are colleagues who will remain in the company even if not on the same project, the training is totally worth it, IMO.

[acemarke]

Thank you, glad to hear that our React-Redux hooks are useful!

And yes, the fact that the hooks work so much better with TS than `connect` was one of the major reasons why we now recommend the hooks API as the default.