A journey through the implementation of the useState hook

When the React team released hooks last year, my first thoughts were, "what new piece of wizardry is this which has been unleashed upon us?!". Your initial impressions may have been less dramatic but I am sure you shared my sentiments. Digging into the implementation of new framework features is one of my favoured methods of understanding them better, so in this post I will attempt to walk you through part of the workflow that is triggered when the 

 hook is used. Unlike other articles which teach you 

 your own version, I am more concerned with the code behind the hook, so to speak.

One way I like to break down features is by focusing on their underlying data structures. Components, hooks, context...all these are React features but when you peel back the layers, what are they really? I find this approach immensely useful because it helps me not to be fixated on framework specific concepts but on the tool used to build the framework - JavaScript.

The first thing we will do is create a very simple example application (they work best for this kind of deep dive):

const ComponentWithHook = () => {
  const [count, setCount] = React.useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>Count: {count}</button>
  )
}

ReactDOM.render(
  <ComponentWithHook />,
  document.getElementById("root")
);

Our app renders a button which displays a counter and increases it by one it whenever it is clicked. It consists of a solitary function component. Hooks were created to encapsulate side effects and stateful behaviour in such components. If we look at this code through our data structure lens, we can see that:

Before we go into what happens next, let us remind ourselves of some of the behaviour we expect to see based on how hooks work:

All code taken from React's source is from version 16.12.0

 when the app loads. It has one property called 

 as its initial value, and is allocated hook functions corresponding to React's mount or update phase. This allocation happens in the 

{
  if (nextCurrentHook !== null) {
    ReactCurrentDispatcher$1.current = HooksDispatcherOnUpdateInDEV;
  } else if (hookTypesDev !== null) {
    // This dispatcher handles an edge case where a component is updating,
    // but no stateful hooks have been used.
    // We want to match the production code behavior (which will use HooksDispatcherOnMount),
    // but with the extra DEV validation to ensure hooks ordering hasn't changed.
    // This dispatcher does that.
    ReactCurrentDispatcher$1.current = HooksDispatcherOnMountWithHookTypesInDEV;
  } else {
    ReactCurrentDispatcher$1.current = HooksDispatcherOnMountInDEV;
  }
}

var children = Component(props, refOrContext);

In the source, there are comments above this code which explain that if the following check 

 is true, this indicates to React that it is in the mount phase. 

You might be interested to know that the only difference between the dev and production versions of the 

 objects is that the dev hooks contain sanity checks such as ensuring that the second argument for hooks like 

 At the beginning of our app's lifecycle, our dispatcher object is 

Each time a hook is called, our dispatcher is resolved by 

 function which checks that we are not trying to call a hook outside of a function component. 

 itself actually calls a function called 

 returns an object which starts off with 

 as the value for all its properties but ends up like this at the end of the function:

{
  memoizedState: 0, // our initial state
  baseState: 0, // our initial state
  queue: {
    last: null,
    dispatch: dispatchAction.bind(null, currentlyRenderingFiber$1, queue),
    lastRenderedReducer: basicStateReducer(state, action),
    lastRenderedState: 0, // our initial state
  },
  baseUpdate: null,
  next: null,
}

 maps to our state initialisation expression 

const [count, setCount] = React.useState(0)

With regards to the hooks part of React's initialisation, this is where our interest ends. At the beginning of this article we said we would be looking at things from a data structure perspective. React exposes hooks to us as functions but under the hood, they are modelled as objects. Why this is the case will become apparent in the next section.

What happens when we click the button and update our counter? From what we know so far, we should expect the answer to that question to also include answers to these sub-questions:

The answer to question two is comes from the declaration of 

 provides the answer to question three. I have written about React's new fiber implementation 

 but essentially, a fiber is an object that is mutable, holds component state and represents the DOM. React creates a tree of these objects and that is how it models the entire DOM. Every component has a corresponding fiber object. You can actually view the fiber node associated with any HTML element by grabbing a reference to the DOM element and then looking for a property that begins with 

 and its value is the hook object created during 

's execution. That object has a property called 

{
  memoizedState: 0, // the setCount hook
  baseState: 0,
  queue: { /* ... */},
  baseUpdate: null,
  next: { // the setBool hook
    memoizedState: false, 
    baseState: false,
    queue: { /* ... */},
    baseUpdate: null,
    next: { // the useEffect hook
      memoizedState: {
        tag: 192,
        create: () => {},
        destory: undefined,
        deps: [0, false],
        next: { /* ... */}
      }, 
      baseState: null,
      queue: null,
      baseUpdate: null,
      next: { // the useRef hook
        memoizedState: { 
          current: undefined
        }, 
        baseState: null,
        queue: null,
        baseUpdate: null,
      }
    }
  }
}


Hooks are stored according to their calling order in a linked list on the 

 of using hooks is they should not be used in loops, conditions or nested functions. For example, the docs provide the following code to illustrate what could go wrong:

When React first initialises the app, the fiber node for this component has a property called 

["useState", "useEffect", "useState", "useEffect"]

 function runs and compares the currently executing hook and its expected index in the array. In the example above, it finds 

 and throws an error. But what if you tried tricking React by writing this:

function Form() {
  // 1. Use the name state variable
  const [name, setName] = useState('Mary');

  // 2. Use the middle name state variable
  if (name !== '') {
   const [middleName, setmiddleName] = useState('Nyasha');
  }

  // 3. Use the surname state variable
  const [surname, setSurname] = useState('Poppins');

  // ...
}

 to the linked list implementation. When the error occurs, React is expecting to be working on 

. However, in the example above, it encounters the 

 property pointing to the hook object for 

Moving on to our first question (which state field on the hook object gets updated?), we can answer it by looking at the hook object we get once the component has been updated and re-rendered:

{
  memoizedState: 1, // our new state
  baseState: 1, // our new state
  queue: {
    last: {
      expirationTime: 1073741823,
      suspenseConfig: null,
      action: 1,
      eagerReducer: basicStateReducer(state, action),
      eagerState: 1, // our new state
      next: { /* ... */},
      priority: 98
    },
    dispatch: dispatchAction.bind(null, currentlyRenderingFiber$1, queue),
    lastRenderedReducer: basicStateReducer(state, action),
    lastRenderedState: 1, // our new state
  },
  baseUpdate: {
    expirationTime: 1073741823,
    suspenseConfig: null,
    action: 1,
    eagerReducer: basicStateReducer(state, action),
    eagerState: 1, // our new state
    next: { /* ... */},
    priority: 98
  },
  next: null,
}

A lot has changed. The most significant being 

 contains the most recent action that changed 

. If you were to increment the counter again and pause at the 

function basicStateReducer(state, action) {
  return typeof action === 'function' ? action(state) : action;
}

Because it accepts a function which will take the current state as its first argument, we could re-write our 

<button onClick={() => setCount(count => count + 1)}>Count: {count}</button>

Some developers advocate giving a function to useState's update function if your state update depends on your previous state. Another thing to note is that if the newly computed state is the same as the current state, React bails out without scheduling a re-render.

I came across many references to reducers whilst looking at 

 and this is because the function which actually does the state update is called 

. It is also used to perform updates by the 

 is computed, it means React has not yet entered the render phase. When it eventually does so, it realises that the new state has already been "eagerly computed", so it is applied to the 

We began this article by asking what happens when we introduce the 

 hook to a codebase. It involves the creation of a shared object and a linked list. This post is by no means an exhaustive or complete explanation of 

 but I hope it has provided some interesting insight into React's internals. As I mentioned at the outset, focusing on the data structures behind library and framework features can yield some interesting learnings. From a developer's point of view, hooks are functions which encapsulate stateful code and side effects but internally, React is working on a linked list. I have found this approach not only educational but empowering because it reminds me that despite the complexity of the tools we use, they are built using some of the JavaScript language features you and I use daily.

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

A journey through the implementation of the useState hook

Tags

Responses (2)

Masterclasses

Tutorials

Fullstack React with TypeScript