DEV Community

Cover image for Everything you need to know about React Hooks
Carl Vitullo
Carl Vitullo

Posted on • Originally published at Medium

Everything you need to know about React Hooks

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.

Screenshot of Dan Abramov's Q&A transcript. The highlighted section reads,

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.

  • useState
  • useEffect
  • useContext
  • useCallback
  • useMemo
  • React.memo (Not a hook, but new)
  • useReducer
  • useRef
  • useLayoutEffect
  • useImperativeMethods
  • useMutationEffect

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>
  );
};
Enter fullscreen mode Exit fullscreen mode

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 }))
  };
};

Enter fullscreen mode Exit fullscreen mode

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>
  );
};
Enter fullscreen mode Exit fullscreen mode

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>
  );
};
Enter fullscreen mode Exit fullscreen mode

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>;
};
Enter fullscreen mode Exit fullscreen mode

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>;
};
Enter fullscreen mode Exit fullscreen mode

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>;
};
Enter fullscreen mode Exit fullscreen mode

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])}
    />
  );
};
Enter fullscreen mode Exit fullscreen mode

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} />;
};
Enter fullscreen mode Exit fullscreen mode

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);
    };
  });


}
Enter fullscreen mode Exit fullscreen mode

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)

Collapse
 
sergio profile image
deleteme deleteme

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 hook thing. I don't like it.

Collapse
 
vcarl profile image
Carl Vitullo

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.

Collapse
 
szymkab profile image
Szymon Kabelis

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).

Thread Thread
 
vcarl profile image
Carl Vitullo

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.

Collapse
 
aralroca profile image
Aral Roca

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.

Collapse
 
grahamcox82 profile image
Graham Cox

I do agree here for useState. I can see some of the other hooks being very useful though. Especially useEffect and useCallback...

Collapse
 
jacksonelfers profile image
Jackson Elfers

Agreed, I never felt a need for this.

Collapse
 
jaybeekeeper profile image
Jarret Bryan

This is genuinely such a great step for React

Collapse
 
chasm profile image
Charles F. Munat

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?

Collapse
 
vcarl profile image
Carl Vitullo

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-library is 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.

Collapse
 
chasm profile image
Charles F. Munat

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?

Thread Thread
 
vcarl profile image
Carl Vitullo

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.

Thread Thread
 
chasm profile image
Charles F. Munat

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.

Collapse
 
dance2die profile image
Sung M. Kim • Edited

Thank you for the comprehensive coverage in an easily digestible format there, Carl.

I am unable to find useAPI in the Hook API Reference.

Was it discussed only at React Conf?

Collapse
 
vcarl profile image
Carl Vitullo

Oops, corrected!

Collapse
 
antonio_pangall profile image
Antonio Pangallo

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

Collapse
 
avivrosental profile image
Aviv Rosental • Edited

Thanks for the article, very well written!

Just a small note - in the useMemo example, I think you meant to pass transformedData to the Table component and not the original data.

Collapse
 
andy profile image
Andy Zhao (he/him)

Oh, just the article I was looking for. I felt so out of the loop when I opened Twitter today. 🙈