Using React hooks only for new code ?

React hooks come with React 16.8. This is a huge step forward in reusing logic and improving code readability.

Source

Before anything you should read amazing posts about react hooks. I just want to discuss very specific points here. I’m reusing existing logic :)

Should we rewrite all the thing ?

In fact it would be a bad idea. It is meant to be a “Gradual Adoption Strategy”. On no account should you migrate critical components in your application.

The React team explicitely warned developers about that :

it’s best to practice using Hooks in new and non-critical components first […] At Facebook, we have tens of thousands of components written as classes, and we have absolutely no plans to rewrite them

Forget equivalences

Be careful when migrating.

First, not all use cases are covered yet.

Source

Second, hooks are not strict equivalents for React lifecycle methods. For example useEffect() is not the new componentDidMount. It’s described as a combination of componentDidMount, componentDidUpdate, and componentWillUnmount.

Source

So depending on your case you have to fine tune hooks (e.g with parameters) to get the exact same result as with React lifecycle methods.

The most important thing is that you have to think different. So here, with useEffect() it’s not “when my component is mounted or unmounted” but something more like “after my component is rendered”.

Readability && efficiency

With hooks you will write less code to do the same thing and more.

They are ridiculously easy to setup and the result is cleaner : you can add your own abstraction.

As a result the user interface can be composed with independents blocks that still share common logic without having to be deadly nested.

Just think about it : to get those great benefits, we basically make a function call !

Conlusion

Indeed we use hooks for new codes. They are efficient and clean, some might even say beautiful.

Nevertheless one must be extra cautious when migrating “old” React code with classes. Hooks are not strictly equivalent to lifecycle methods. They go beyond that to add a high level of abstraction.