Cover image by John Wright, on Flickr.
Some time ago React got a new major feature called hooks. They are a way to add state to component functions. Things that required lifecycle methods and in turn, component classes now can be achieved with a component function that calls hook functions.
This fact on its own is already a huge boon. We write our first UI draft with component functions and then don't have to restructure anything, drop in our hooks, and be done with it.
It also eliminates deep component trees. Things that had to be done with higher-order components and render props, which were design patterns constructed with component classes and their lifecycle methods. Auth, UI state, services, internationalization, etc. everything was a component nested in a component.
Hooks add another dimension for nesting. This new dimension allows decoupling the nesting of the visible UI components from the nesting of the invisible behavior of our applications.
But I think these points aren't the main selling point of hooks.
What makes them powerful is that they offer a different way to think about the component lifecycle.
Before hooks, we would think in terms of lifecycle events.
Do I need my component to do something when its rendered for the first time? Let's put the code in componentDidMount!
Will the component be removed? Put it into componentWillUnmount!
For updates? Put it in componentWillUpdate or componentWillReceiveProps or getDerivedStatesFromProps... or ... well now it gets a bit complicated...
Hooks remove this problem once and for all.
With hooks, the focus is moved from the different lifecycle events we want to hook into to the actual state we want to observe.
We create the state we need to observe with useState and use it with useEffect to trigger code when it changes.
The only things we care for are the state changes and if our component gets removed from the DOM.
When we used lifecycle methods, it wasn't enough to know what we want to observe, we also needed to know where at the lifecycle it could occur. This extra step could lead to UI bugs.
For example, React would re-use a component that was already rendered, change the props and componentDidMount wouldn't be called again. The useEffect hook would recognize the changed props and rerun its code.
This sounds like a pretty dull change in thinking about component behavior, but I think it's a brilliant one that eases the creation of component-based UIs tremendously.
Top comments (5)
Nice post! I have found that hooks are so much better for reading comprehension as well. Instead of having to read each lifecycle function of a class component and figuring out what happens in each function and mentally connecting the dots, the code of a function component with hooks is so much easier to comprehend, as the state and effects of the component are defined declaratively, rather than imperatively.
Thank you!
Yes, the actual need to look into every lifecycle method after you wrote all of them is the other side of that problem.
I like hooks, they feel more natural to me.
when I was trying to make a react library and I got to know you can not have more than one copy of React in the same app with hooks. (There were all kinds of workaround for it, but the easier thing was to just code in Class API)
I also read they have some performance implications, don't know if they solved them. But yes, component classes are sometimes the better way, depending on what you want to do :)
Yes, it's super cool. I am using since 3 months and loving it. Initially it may confuse, as we need to unlearn the class life cycle metal model.