React hooks guidelines
Before react 16.8, it was already possible to reuse some stateful logic across your app with higher-order components and render props but Custom Hooks let you do it without adding more components to your tree.
Hooks are a way to reuse stateful logic, not state itself. In fact, each call to a Hook has a completely isolated state — so you can even use the same custom Hook twice in one component.
Custom Hooks are more of a convention than a feature. If a function’s name starts with ”use
” and it calls other Hooks, we say it is a custom Hook. The useSomething
naming convention is how the linter plugin is able to find bugs in the code using Hooks.
You can write custom Hooks that cover a wide range of use cases like form handling, animation, declarative subscriptions, timers, and probably many more we haven’t considered.
When should I create a new custom hook?
When we want to share logic between two JavaScript functions, we extract it to a third function. Both components and Hooks are functions, so this works for them too!
Hooks core motivations :
It’s hard to reuse stateful logic between components
Complex components become hard to understand
Classes confuse both people and machines
With this in mind, you can create new custom hooks when :
There is similar stateful logic across components
You want to write specific stateful logic without rendering anything.
You want to extract logic from your component body to make it easier to read/understand/maintain, or you want to separate render and logic concerns.
Hooks can be shared easily between pages, components, and hooks! So, when creating a new custom hook, consider whether there is any shareable logic that can be isolated in the hooks/
folder.
Otherwise, you have the choice between letting your custom hook's code in the same file as your page or creating a new file aside your component's file.
Please remember that every file need to be tested.
You can found some example on
Document your custom hooks!
As with most things in a large organization, the more custom hooks your team creates, the easier it is to lose track of them.
It's a good idea to keep track of every hook you make. If not for the sake of your team, then for the sake of yourself in the future. Make sure people are aware of your hook's existence, what it does, and what your intentions were, whether it's a README in each hook's folder or a doc in a wiki.
A note like "This was a massive hack where we only covered case X due to this buggy API we use" is far more valuable than nothing.
Adding JSDOC comments above your hooks is also useful
Don't make the mistake of assuming that your code is self-documenting or simple to understand. Because it's still fresh in your mind, you're probably thinking your code is simple.
Testing custom hooks
Thanks to React Testing Library's react-hooks-testing-library, it's never been easier to test hooks in isolation.
Here's an example from their docs. Given a hook extracted as useCounter
:
Your tests would look like this:
References and articles :
Last updated