Hooks FAQ

Hooks are a new addition in React 16.8. They let you use state and other React features without writing a class.

This tutorial answers some of the frequently asked questions about Hooks.

Which versions of React include Hooks?

Starting with 16.8.0, React includes a stable implementation of React Hooks for:

  • React DOM
  • React Native
  • React DOM Server
  • React Test Renderer
  • React Shallow Renderer

Note that to enable Hooks, all React packages need to be 16.8.0 or higher. Hooks won't work if you forget to update, for example, React DOM. React Native 0.59 and above support Hooks.

Do I need to rewrite all my class components?

No. There are no plans to remove classes from React - we all need to keep shipping products and can't afford rewrites. We recommend trying Hooks in new code.

What can I do with Hooks that I couldn't with classes?

Hooks offer a powerful and expressive new way to reuse functionality between components. "Building Your Own Hooks" provides a glimpse of what's possible. This article by a React core team member dives deeper into the new capabilities unlocked by Hooks.

How much of my React knowledge stays relevant?

Hooks are a more direct way to use the React features you already know - such as state, lifecycle, context, and refs. They don't fundamentally change how React works, and your knowledge of components, props, and top-down data flow is just as relevant.

Hooks do have a learning curve of their own. If there's something missing in this documentation, raise an issue and we'll try to help.

Should I use Hooks, classes, or a mix of both?

When you're ready, we'd encourage you to start trying Hooks in new components you write. Make sure everyone on your team is on board with using them and familiar with this documentation. We don't recommend rewriting your existing classes to Hooks unless you planned to rewrite them anyway (e.g. to fix bugs).

You can't use Hooks inside of a class component, but you can definitely mix classes and function components with Hooks in a single tree. Whether a component is a class or a function that uses Hooks is an implementation detail of that component. In the longer term, we expect Hooks to be the primary way people write React components.

Do Hooks cover all use cases for classes?

Our goal is for Hooks to cover all use cases for classes as soon as possible. There are no Hook equivalents to the uncommon getSnapshotBeforeUpdate and componentDidCatch lifecycles yet, but we plan to add them soon.

It is an early time for Hooks, and some third-party libraries might not be compatible with Hooks at the moment.

Do Hooks replace render props and higher-order components?

Often, render props and higher-order components render only a single child. We think Hooks are a simpler way to serve this use case. There is still a place for both patterns (for example, a virtual scroller component might have a renderItem prop, or a visual container component might have its own DOM structure). But in most cases, Hooks will be sufficient and can help reduce nesting in your tree.

What do Hooks mean for popular APIs like Redux connect() and React Router?

You can continue to use the exact same APIs as you always have; they'll continue to work.

React Redux since v7.1.0 supports Hooks API and exposes hooks like useDispatch or useSelector. Libraries like React Router might support hooks in the future.

Do Hooks work with static typing?

Hooks were designed with static typing in mind. Because they're functions, they are easier to type correctly than patterns like higher-order components. The latest Flow and TypeScript React definitions include support for React Hooks.

Importantly, custom Hooks give you the power to constrain React API if you'd like to type them more strictly in some way. React gives you the primitives, but you can combine them in different ways than what we provide out of the box.

How to test components that use Hooks?

From React's point of view, a component using Hooks is just a regular component. If your testing solution doesn't rely on React internals, testing components with Hooks shouldn't be different from how you normally test components.

What exactly do the lint rules enforce?

We provide an ESLint plugin that enforces rules of Hooks to avoid bugs. It assumes that any function starting with "use" and a capital letter right after it is a Hook. We recognize this heuristic isn't perfect and there may be some false positives, but without an ecosystem-wide convention there is just no way to make Hooks work well - and longer names will discourage people from either adopting Hooks or following the convention.

In particular, the rule enforces that:

  • Calls to Hooks are either inside a PascalCase function (assumed to be a component) or another useSomething function (assumed to be a custom Hook).
  • Hooks are called in the same order on every render.

Previous: Hooks API Reference
Next: Testing Recipes