A Critique of React Hooks

I was skeptical towards hooks when it was first introduced. I was hesitant to use it. Then, I used it for a few components in my projects. I realized how much simpler my code looked, and migrated completely to hooks. No regrets.

The reason they introduced hooks was exactly that component lifecycle and decorators/higher order components were found not to scale well in larger codebases (as experienced by the people using React at Facebook).

The useEffect pretty much provides a direct replacement for componentDidMount/componentWillUnmount.

I'm still on the fence, but so far it seems to me that using hooks makes my intent clearer than using the various lifecycle methods.

All of this reads akin to someone criticizing an apple for not being an orange. Every point is an intentional design decision. Learning new things is necessary, leaving class syntax behind was a choice, and imposing limits on (controlling) application design is the point of libraries.

The team is pushing a functional declarative pipe method of building UI applications where things are built using a straight-line series of composed functional transformations. Personally, I think supporting this method with the hooks model of handling side effects is an improvement over everything else that exists in "roll your own" UI library land. I find these style libraries more enjoyable to build with, more expressive, and better suited to building things where you need finer grain control than template style libraries like Vue, which provide a stronger degree of predictability and ease of immediate use.

That's the thing -- it's a balance. Hooks add a nicely considered and balanced degree of order to the otherwise intentionally uncontrolled-so-you-can-do-the-controlling programming model of React. React identifies as the advanced lego set with the smaller more numerous blocks that you can build the cooler stuff with, and as such will always have a certain threshold of complexity.

Agree, "More Stuff to Learn" isn't really a critique of hooks, it's a critique of learning.

I have some similar gripes. I find Hooks to save a bit of coding overall. I've found my functional components to be about 10-20% smaller than my class components. I'm not 100% convinced it's really worth it, though.

With class components, my state/props are clearly defined within the constructor and/or PropTypes. This makes it easy to understand the overall architecture of a component. Functional components with Hooks don't have the same sort of structure and can be difficult to understand at a glance.

One of my gripes with Hooks is that listening for async state updates requires more code/complexity than w/classes. In a traditional class component, you can add a second, optional argument as a callback which is called when the state has updated:

  setState({ myState: 'newValue' }, () => { this.doSomething(); });

With Hooks, that doesn't apply. The useState "set" function doesn't have a similar argument.

  setMyState('newState');

Instead, you need to use 'useEffect' with an optional argument:

  useEffect(() => { doSomething(); }, [myState]);

This leads to potentially having many "useEffects" scattered throughout the component.

That said, this is just my experience with Hooks after a few months of working with them. It's entirely possible that I just haven't had enough experience with them yet.