A Critique of React Hooks

I am disappointed with the React team’s decision to push functional components and hooks as the standard way of working with React. Not sure if the reason is to make React more approachable to newcomers or not, but in my experience leveraging the power of the component lifecycle through class components and decorators is the most fool-proof way to build and maintain large applications. Particularly leveraging shouldCompomentUpdate for performance and componentDidMount/componentsWillUnmount for registering and disposing of component dependencies is very easy to reason about and scale.

Hooks weren't invented because of 'this' complexity though, but rather as a better way to handle reuseable code (somewhat) akin to mixins.

From what I've learned using them, hooks are a tool like anything else—pushing one method as "the" way means that you make a lot of poor engineering decisions.

Hooks are like a screwdriver; great for simple stuff when you want to reduce code overhead.

Sometimes you need a power drill, though, and classes and the old-school lifecycle functions are wonderful for that.

I don't think this is a great critique, simply because the pain I've encountered using them isn't mentioned here. The incompatibility with class components is what it is, they're different programming paradigms that you have to choose between. If your library leaned heavily into HOCs, that was an unfortunate choice and I'd recommend making a new library because HOCs were always unwieldy and had problems with composition. Nothing to do with functional components or hooks really, just a very heavy pattern that can typically be done better with another approach like render props.

I guess I see a lot of this as evolutionary. It's unfortunate that there has been so much change, and the timing might not be great for some projects, but I would not prefer a world where I was still writing and using HOCs and class components.

In my day job I work on a pretty old (in React years) project, and we haven't had trouble writing new code in a functional + hooks style. Still plenty of class components abound.

The reaction to react hooks has been (as far as I've seen) a little too positive, so I was looking forward to read a genuine critique.

However, I'm disappointed.

In reverse order:

> 5. They Complicate Control Flow

A set of contrived examples, within which the only genuinely confusing part is not related to React at all. It's Javascript's object non-equality ({ multiplier: 5 } !== { multiplier: 5 })

> 4. The Rules of Hooks Limit Your Design

This is an interesting section but seems to point to a pattern that would lead to serious issues given any library/paradigm. It's criticising the Rules for their inflexibility, but in this instance they're helping you by pointing out the pitfalls of your approach, and encouraging you to rethink it.

An alternative way of looking at it is that it's again (like in 5) bemoaning Javascript's object inequality which is prevening the memoization here.

The other 3 bullets are pretty silly "boo new things" issues that are common to migration to any new API.