React just announced a new feature: Hooks. It's a brand new set of APIs that enables powerful new ways to share stateful logic between components, optimize performance without significant rewrites, get some of the benefits of Redux-style separation of concerns, and more. They also deliver on a promise that the React team made years ago—stateful function components. Using state from function components came up as a possibility in Dan Abramov's Q&A on Reactiflux all the way back in April 2016.
It's been a long time coming, but they're here! More than just state, though, there are 11 new functions in all that should enable the full range of functionality that we use classes and the lifecycle for today.
useStateuseEffectuseContextuseCallbackuseMemo-
React.memo(Not a hook, but new) useReduceruseRefuseLayoutEffectuseImperativeMethodsuseMutationEffect
Let's take a look at what each of them is for.
useState
Stateful function components are enabled with the new function useState.
import { useState } from "react";
const SomeComponent = props => {
const [state, setState] = useState(initialState);
return (
<div>
{state}
<input onChange={e => setState(e.target.value)} />
</div>
);
};
If you ever used the library recompose, this API may look familiar. useState takes an initial state as an argument, and returns the current state and an updater function. The setState it returns is almost the same used by class components—it can accept a callback that gets the current state as an argument, but it doesn't automatically merge top-level object keys.
Each call to useState is paired with a component, with its state persisting across renders. This means that you can call useState multiple times within a single function component to get multiple independent state values. Because the setState returned isn't scoped to a single component, we can define stateful behaviors independent of the component. This enables powerful new ways to abstract stateful logic.
Let's look at an example that I've run into on several projects: managing sort state in several components. I find the APIs that table components expose to be inflexible, so I tend to write tables of data as one-offs. My current project has some code for managing what key to sort against, and in which direction, copy-pasted into several different components. With useState, we gain the ability to define it as a separate module.
const useSort = (someArray, initialSortKey) => {
const [state, setState] = useState({
isAscending: false,
sortKey: initialSortKey
});
// Let's pretend `makeSortComparator` exists for simplicity
const comparator = makeSortComparator(state);
const sortedData = someArray.slice().sort(comparator);
return {
...state,
sortedData,
toggleAscending: () =>
setState(state => ({
...state,
isAscending: !state.isAscending
})),
setSortKey: sortKey =>
setState(state => ({ ...state, sortKey }))
};
};
Now we have a reusable method to use in our data table components. We have a simple API we can use across our many different tables, with each component working off its own separate state.
const SomeTable = ({ data }) => {
const { sortedData, ...sortControls } = useSort(
data,
"id"
);
return (
<table>
<TableHeading {...sortControls} />
<tbody>
{sortedData.map(datum => <TableRow {...datum} />)}
</tbody>
</table>
);
};
Please note: the React team strongly recommends prefixing the names of these types of modules with use so there's a strong signal of what kind of behavior it provides. See the full docs for more about writing your own hooks.
I am super excited about this new way to share functionality. It's much more lightweight than a HOC in all ways; less code to write, fewer components to mount, and fewer caveats. Check out the API documentation for all the details.
useEffect
A lot of components have to kick off different types of effects as part of mounting or re-rendering. Fetching data, subscribing to events, and imperatively interacting with another part of the page are all common examples of this. But the code for handling these types of effects ended up scattered across componentDidMount, componentDidUpdate, and componentWillUnmount.
If you wanted to run the same effect when a prop changed, you either had to add a mess of comparisons in componentDidUpdate or set a key on the component. Using a key simplifies your code, but it scatters control of effects into another file—completely outside the component's control!
useEffect simplifies all these cases. Imperative interactions are simple functions run after each render.
const PageTemplate = ({ title, children }) => {
useEffect(() => {
document.title = title;
});
return (
<div>
<h1>{title}</h1>
{children}
</div>
);
};
For data fetching and other interactions you don't want to happen unnecessarily, you can pass an array of values. The effect is only run when one of these changes.
const ThingWithExternalData = ({ id, sort }) => {
const [state, setState] = useState({});
useEffect(() => {
axios
.get(`/our/api/${id}?sortBy=${sort}`)
.then(({ data }) => setState(data));
}, [id, sort]);
return <pre>{JSON.stringify(state, null, 2)}</pre>;
};
Subscriptions and other effects that require some kind of cleanup when the components unmount can return a function to run.
const ThingWithASubscription = () => {
const [state, setState] = useState({});
useEffect(() => {
someEventSource.subscribe(data => setState(data));
return () => {
someEventSource.unsubscribe();
};
});
return <pre>{JSON.stringify(state, null, 2)}</pre>;
};
This is so powerful. Just like with useState, they can be defined as separate modules—not only does this put all the code required for these complex effects in a single location, they can be shared across multiple components. Combined with useState, this is an elegant way to generalize logic like loading states or subscriptions across components.
useContext
The context API is great and was a significant improvement in usability compared to what existed before. It advanced context from a "you probably shouldn't use this" warning in the docs to an accepted part of the API. However, context can be cumbersome to use. It has to be used as a render prop, which is a pattern that doesn't compose gracefully. If you need values out of multiple different render props, you quickly end up indented to the extreme.
useContext is a substantial step forward. It accepts the value created by the existing React.createContext function (the same one you would pull .Consumer off to use as a render prop) and returns the current value from that context provider. The component will rerender whenever the context value change, just like it would for state or props.
// An exported instance of `React.createContext()`
import SomeContext from "./SomeContext";
const ThingWithContext = () => {
const ourData = useContext(SomeContext);
return <pre>{JSON.stringify(ourData, null, 2)}</pre>;
};
This gets rid of my final complaint with context. This API is simple and intuitive to the extreme and will be a powerful way to pipe state around an application.
More advanced hooks
The 3 hooks mentioned above are considered to be the basic hooks. It's possible to write entire applications using only useState, useEffect, and useContext--really, you could get away with just the first two. The hooks that follow offer optimizations and increasingly niche utility that you may never encounter in your applications.
useCallback
React has a number of optimizations that rely on props remaining the same across renders. One of the simplest ways to break this is by defining callback functions inline. That's not to say that defining functions inline will cause performance problems--in many cases, it has no impact. However, as you begin to optimize and identify what's causing frequent re-renders, you may find inline function definitions to be the cause of many of your unnecessary prop change.
In the current API, changing an inline function to something that won't change across renders can be a significant change. For function components, it means rewriting to a class (with all the changes that entails) and defining the function as a class method. useCallback provides a simple way to optimize these functions with minimal impact on your code by memoizing a function provided to it. Just like useEffect, we can tell it what values it depends on so that it doesn't change unnecessarily.
import doSomething from "./doSomething";
const FrequentlyRerenders = ({ id }) => {
return (
<ExpensiveComponent
onEvent={useCallback(() => doSomething(id), [id])}
/>
);
};
This is another exciting improvement in usability. What used to mean a significant rewrite of a component can now be accomplished in-place with a function directly from React.
useMemo
On the subject of optimizations, there's another hook that has me excited. Many times, I need to calculate derived data from the props I provide a component. It may be mapping an array of objects to a slightly different form, combining an array of data to a single value, or sorting or filtering. Often render is the logical place for this processing to happen, but then it will be run unnecessarily whenever other props or state change.
Enter useMemo. It's closely related to useCallback, but for optimizing data processing. It has the same API for defining what values it depends on as useEffect and useCallback.
const ExpensiveComputation = ({
data,
sortComparator,
filterPredicate
}) => {
const transformedData = useMemo(
() => {
return data
.filter(filterPredicate)
.sort(sortComparator);
},
[data, sortComparator, filterPredicate]
);
return <Table data={data} />;
};
I'm excited about this for many of the same reasons as useCallback. Previously, optimizing this type of processing typically meant extracting the logic to a separate function and memoizing that. Because it's common practices for memoization tools to rely on a functions arguments for invalidating memoization, that meant creating a pure function. This refactoring can end up being too substantial, so only the most extreme performance problems end up being addressed. This hook should help avoid the "death by a thousand cuts" type of performance problems.
React.memo
This isn't a hook, but it's a new API and an important optimization. Memoizing calculations and ensuring props don't change unnecessarily are good for performance, but both are more effective when combined with the shouldComponentUpdate or PureComponent features—neither of which is available for function components.
React.memo is a new function that enables behavior similar to PureComponent for functions. It compares prop values and only re-renders when they change. It doesn't compare state or context, just like PureComponent. It can accept a second argument so you can do custom comparisons against props, but there's an important difference from shouldComponentUpdate: it only receives props. Because useState doesn't provide a single state object, it can't be made available for this comparison.
useReducer
This hook has interesting implications for the ecosystem. The reducer/action pattern is one of the most powerful benefits of Redux. It encourages modeling UI as a state machine, with clearly defined states and transitions. One of the challenges to using Redux, however, is gluing it all together. Action creators, which components to connect(), mapStateToProps, using selectors, coordinating asynchronous behavior... There's a whole menagerie of associated code and libraries on top of Redux that can overwhelm.
useReducer, combined with the usability improvements to context, new techniques for memoizing calculations, and the hooks for running effects, allow for many of the same benefits as Redux with less conceptual overhead. I personally have never been bothered by the supposed boilerplate problem that Redux has, but considering how these hooks will combine has me excited for how features could be defined and scoped within an application.
useRef
Sometimes when writing components, we end up with information that we need to keep track of but don't want to re-render when it changes. The most common example of this is references to the DOM nodes we've created, for instance, an input node that we need to track the cursor position for or imperatively focus. With class components we would track assign them directly to properties on this, but function components don't have a context we can reference that way.
useRef provides a mechanism for these cases. It creates an object that exists for as long as the component is mounted, exposing the value assigned as a .current property.
Directly from the docs (and the FAQ:
// DOM node ref example
function TextInputWithFocusButton() {
const inputEl = useRef(null);
const onButtonClick = () => {
// `current` points to the mounted text input element
inputEl.current.focus();
};
return (
<>
<input ref={inputEl} type="text" />
<button onClick={onButtonClick}>Focus the input</button>
</>
);
}
// An arbitrary instance property
function Timer() {
const intervalRef = useRef();
useEffect(() => {
const id = setInterval(() => {
// ...
});
intervalRef.current = id;
return () => {
clearInterval(intervalRef.current);
};
});
}
This code is more verbose than using instance properties is in class components, but it should be relatively infrequent that you need to store values in this way.
Rarely used hooks
The hooks mentioned above have covered all the use cases that I've encountered when writing applications. Reading through the docs of the remaining hooks, I understand why they exist and I'm sure that I'm using libraries that will implement them, but I don't anticipate using them myself in application code.
useLayoutEffect
If I use any of these 3, I anticipate it will be useLayoutEffect. This is the hook recommended when you need to read computed styles after the DOM has been mutated, but before the browser has painted the new layout.
Crucially, this gives you an opportunity to apply animations with the least chance of visual artifacts or browser rendering performance problems. This is the method currently used by react-flip-move, an amazing transition library when items change position, but there might be situations where I need to use this myself.
useImperativeMethods
To the best of my knowledge, this hook is a counterpart to forwardRef, a mechanism for libraries to pass through the ref property that would otherwise be swallowed. This is a problem for component libraries like Material UI, React Bootstrap, or CSS-in-JS tools like styled-components, but I haven't run into a case where I needed to solve this problem myself.
useMutationEffect
This is the hook I'm having the hardest time wrapping my head around. It's run immediately before React mutates the DOM with the results from render, but useLayoutEffect is the better choice when you have to read computed styles. The docs specify that it runs before sibling components are updated and that it should be used to perform custom DOM mutations. This is the only hook that I can't picture a use case for, but it might be useful for cases like when you want a different tool (like D3, or perhaps a canvas or WebGL renderer) to take over the actual rendering of output. Don't hold me to that though.
In conclusion
Hooks have me excited about the future of React all over again. I've been using this tool since 2014, and it has continually introduced new changes that convince me that it's the future of web development. These hooks are no different, and yet again substantially raise the bar for developer experience, enabling me to write durable code, and improve my productivity by extracting reused functionality.
I thought Suspense was the only upcoming feature that I'd be excited for in 2018, but I'm happy to be proven wrong! Combined, I expect that React applications will set a new bar for end-user experience and code stability.
Thanks for reading! I'm on Twitter as @cvitullo (but most other places I'm vcarl). I moderate Reactiflux, a chatroom for React developers and Nodeiflux, a chatroom for Node.JS developers. If you have any questions or suggestions, reach out! Cover image is from rawpixel on Unsplash
Top comments (18)
So adding class lifecycle events to functional components? Why not just use a class?
The beauty of the functional components is that immediately you know there's ZERO state in here. It's just rendering markup based on input.
Now there's more to look out for given this
hookthing. I don't like it.Immediate explorations I've seen have dramatically cut the number of lines for implementation. One example I saw cut 130 lines down to 15. These APIs also enable new behaviors not achievable with classes (extracting reusable stateful logic), as well as letting you consolidate related logic so it's not all intermingled with unrelated functionality.
To be honest you can extract reusable state logic by using abstract classes for example but rather for some small logic and I wouldn't go too far with that because it can quickly end up with ugly non-readable composition.
Also, I hate classes because you can quickly end up with a mess (lots of unrelated things in componentDidMount, componentWillUnmount, having the same state in multiple classes etc). Hooks are a really great improvement (for readability and composition).
Inheriting from a custom class is considered an antipattern in React, so while it works on a technical level I wouldn't say it's a viable option. All the downsides of mixins without any benefits over other ways of composing functionality.
Hooks are a beauty alternative to renderprops or hoc. Reusing logic without JSX in the middle. Of course they don't reinvent another lifecycle and they reuse the existent one.
Components are now more atomic, with a separation of concerns.
At the beginning I didn't like so much until I realized that is possible to generate a custom hooks. IMO here is where is all the power.
I do agree here for
useState. I can see some of the other hooks being very useful though. EspeciallyuseEffectanduseCallback...Agreed, I never felt a need for this.
This is genuinely such a great step for React
How can everyone write about hooks without a word about testing them? Not just this author -- even the Facebook documentation says nothing about testing them.
Shouldn't every code example START with a test before a line of application code is even written? If tests are an afterthought or left out completely in the tutorials, how do you think the average developer will treat them? Maybe as an afterthought or left out completely?
Maybe you could take the lead on this?
Hooks are an implementation detail, if used within a component. I specifically try to write UI tests that manipulate the DOM and verify that callbacks were called correctly (what I view as the inputs and outputs of a UI--
react-testing-libraryis excellent for this), so whether I use hooks or something else the tests would be the same. Indeed, I'd consider it a faulty test if I had to dramatically change my strategy by adding hooks.As for writing tests for custom hooks, that is definitely new and valuable, but seems beyond the scope of an API overview. If you'd like to try it out and write up your experience with it, I'm sure it would be valuable.
So would you disagree with this example:
medium.com/@MimiLiou77/testing-rea...
(Only one I've found.)
There is actually very little on best practices unless one goes off and takes something like the frontend masters courses. Personally, I think tests should always be discussed, even if to say what you've said above.
So you don't use mocks to mock out the implementation?
Mocking modules makes tests more fragile, I try to mock as little as is feasible when testing. Ideally I'd only use mocks for functions that I pass in, and I'd use those more as "spies" to make sure they're called correctly.
That seems like a solid testing example of a custom hook, as a unit test.
I'm only mocking my own functions. I never mock libraries. I figure they should work fine.
I will give this some thought. Thanks for the responses.
Thank you for the comprehensive coverage in an easily digestible format there, Carl.
I am unable to find
useAPIin the Hook API Reference.Was it discussed only at React Conf?
Oops, corrected!
Hi Carl, good article. I have been using react hooks to build a predictable state container which reimplements redux's api and concepts. I am trying to get feedbacks on it. would you take a look at github.com/iusehooks/redhooks ? Thanks
Thanks for the article, very well written!
Just a small note - in the
useMemoexample, I think you meant to passtransformedDatato theTablecomponent and not the originaldata.Oh, just the article I was looking for. I felt so out of the loop when I opened Twitter today. 🙈