To Hook or Not to Hook?
By: Bianca Czaderna
Tags: React Hook, React, Hooks, Redux

PROS:

The React team tells us in the docs that, “Hooks solve a wide variety of seemingly unconnected problems in React that we’ve encountered over five years of writing and maintaining tens of thousands of components.”

A Way to Recycle Stateful Logic

The first of these problems is that it has proven difficult to recycle stateful logic between components. React on its own isn’t able to do it. Developers have had to incorporate things like Redux (a library which holds state in a central “store” that any component can have access to), render props (a props whose value is a function), and higher-order components (functions that take a component and return a new component). These abstractions are okay workarounds, but many developers complain that Redux is difficult to learn, requires a lot of tedious boilerplate code, and often results in “nesting hell”, as actions often have to be passed through multiple components just to get to where they’re actually used. Render props can also result in crazy nesting. Higher-order components are perhaps the best alternative, but they still often result on “wrapper hell”, and and require you to restructure your code before using them, which can more readily result in a “false hierarchy”, and in errors which can make code harder to follow.

Hooks do what these abstractions do, but without these nasty side-effects, and with arguably less labor and headache. Instead of introducing more layers into your code, they make something like a flat list of “memory cells” attached to a component. They allow you to reuse stateful logic without changing your component hierarchy. Further, the ability to pass data between hooks make them a great fit for expressing animations, data subscriptions, form management, and other stateful abstractions.

Organization Based on Functionality

Another problem, proponents of hooks say, is that it’s weird and unnatural to organize logic by lifecycle methods, as each lifecycle method often contains a mix of unrelated logic. Meanwhile, logically-related code — code that is trying to do a particular thing, achieve a particular functionality— often gets split apart into different methods. This is confusing and can easily introduce bugs and inconsistencies. What ends up happening is that there’s stateful logic peppered all over the place. That makes the component hard to test, and the code hard to understand. Many developers use Redux to help with this, but as I’ve stated above, Redux comes with its own host of issues.

Hooks solve this by allowing you to organize your code based on functionality, rather than on where in the lifecycle the action happens.

Here is a visual for how hooks divide your code up differently (and slim it down):

Easier than Classes

There is also the argument that classes are a barrier for people who want to learn React. The creators of React hooks say that “People can understand props, state, and top-down data flow perfectly well but still struggle with classes.” With classes you need to understand how the enigmatic “this” works in Javascript, you have to bind event handlers, and you have to plod through long, often confusing chunks of code.

React hooks would render these “confusing” classes essentially useless.

Optimization’s the Thing

Finally, the proponents say that hooks will help keep React relevant and optimized. They want to incorporate things like ahead-of-time compilation and component-folding, and classes can slow these down. Classes can also slow down other tools, like hot reloading.

Finally, if you’re worried about implementation size, the hooks support increases React only by ~1.5kB (min+gzip). This really isn’t much. It’s also likely that adopting hooks could reduce your bundle size because code using hooks tends to minify better than equivalent code using classes.