React Hooks — Best practices & a shift in mindset

Bryan Manuele (Fermi Dirak)
3 min readMar 22, 2019

--

React hooks landed a little over a month ago at the time of me writing this article. From my one month of experience in using and writing hooks, I’ve found hooks to be a very powerful abstraction — possibly a little too powerful. As the saying goes, with great power comes great responsibility; and this article intends go over how to effectively start thinking in hooks and covers battle-tested best practices cumulated over the course of the entirety of their existence on writing your own React components with hooks.

Note: This article assumes knowledge of hooks and how to use them. Check out the docs if you’re in need of a refresher (https://reactjs.org/docs/hooks-intro.html)

⚓ Thinking in Hooks ⚓

One of the things that I love about classical components is the idea of encapsulation. Everything relevant to the classical component will live within the curly braces that follow the class keyword. Life-cycle hooks: constructor, componentDidMount, render, etc., give components a predictable structure, which makes code organization braindead and, well, predictable. (rule of least power at play)

With hooks, the composition of a component fundamentally changes from being a conglomerate of life-cycle hooks, to being a down-the-barrel registering / acknowledging of plug-n-play functionalities with some render at the end.

The classical vs functional model of a component. The classical model is more predictable, while the hooks model is more composable.

Looking at the hooks example above you may be wondering to yourself, “What does useHook do?” The answer: well, anything.

useHook could be subscribing the component to various side-effects, instantiating state variables, consuming contexts, or all the above if you’re using a custom hook! This leads to best practice no. 1…

1. Keep your hooks simple

If you can avoid writing custom hooks — it’s in your code maintainer’s best interest that you do so. Mixins were considered harmful in no small part due to them enabling obfuscated and often heavy handed abstractions to often trivial functionalities. If you can inline a useState or useEffect instead of creating and using your own hook, then keep it simple and do that. Don’t be that developer that takes DRY to the extreme. Prefer to keep your hooks simple.

premature optimization / abstraction is more relevant than ever in this compositional paradigm

2. Keep your hooks organized

Follow the classical component’s lifecycle ordering — do your computations first, instantiate your state, subscribe to your side-effects, set up your event handlers, and finally render, in that order.

https://github.com/airbnb/javascript/tree/master/react#ordering

Keeping your functional component organized in the same way one would organize a classical component helps with readability and keeps the flow of your components consistent and predictable.

3.2 ES6 default values > defaultProps (especially for Typescript and Flow users)

When using a type-checker, one of my pet peeves is that a “required” prop isn’t necessarily a required prop since it may have a defaultProp value associated with it.

This type checking pet-peeve is due to the nature of defaultProp. Since defaultProp is evaluated at run-time, it cannot be accounted for in static type-checking.

Using ES6 default values remedies this issue since default values are statically defined. With ES6 default values, your prop-types will correctly reflect what is optional and what is required.

4. Lastly, take adoption easy 🏄🌊

Hooks are still a relatively new technology and the ecosystem and community are not fully there yet — outside of this article best practices have not entirely been settled yet, and so adoption should be taken with the precaution one would take in adopting any early technology. With that wisdom in mind, hooks are the way of the future for React, and I hope this article serves you well in your hook fueled code adventures!

--

--

Bryan Manuele (Fermi Dirak)

I'm a Full Stack Engineer at Flexport. I sometimes writes about things that I'm sometimes interested in :)