Hacker News Reader

Comment by ng12 | Hacker News Reader

For me the problem hook solves is the heartache pain I feel when I have to convert a SFC to a React.Component. Adding useState and useEffect feels much more natural. I don't think it's any more or less bug-prone than React.Component, especially because you have to be careful about making sure componentDidMount() and componentDidUpdate() are in sync.

View on HN

but you introduce the danger of relying on an api that determines your state based on the order of function calls. if you accidentally take an api that pretends to work based on call site and use it in a loop or callback everything falls apart.

Only the order of the hook function calls is tracked. The "danger" of 3rd party APIs is a theoretical one, as in most cases you would not put hook function anywhere else except the first level inside the functional component - not into callbacks or whatnot of 3rd party libraries.

It only relies on that order between renders. It’s really a non issue.

I just spend the last month building a new chunk of our app in hooks to try them out, and it’s really nice to be able to wrap up shared stateful logic without HoCs.

A bunch of the HoCs in this app take a “propKey” param, because the HoCs are all stacked on top of each other, and prop collisions happened frequently.

Also, it’s a gigantic pain to use TypeScript and “compose”.

it’s really nice to be able to wrap up shared stateful logic without HoCs

agreed. I loved HOCs for the composibility, abused them and very rarely encountered prop collision, but TS (or Flow) made them a massive pain

IIRC this is easily preventable using the ESLint rule.

Reply on news.ycombinator.com