The React useState hook is the most commonly used hook. In this article, we will delve into the useState hook in detail and explore how it can be used to manage state in React.

Anatomy of useState

Let’s break down its components and functionality:

const [state, setState] = useState(initialState);

useState is a hook function that accepts one argument, which represents the initial state of the component. This argument can be either a value or a function.
state refers to the current value of the state. It can hold various data types, such as numbers, strings, objects, and arrays.
setState represents the setter function responsible for updating the state value. Invoking setState triggers a re-render of the component, ensuring that the updated state is reflected.

By utilising array destructing, useState returns an array containing the current state value and the corresponding setter function.

So when you console log below:

console.log(useState(2));

you will get this:

The first value is the current value and the second value is the setter function. So by destructing the array, we can get the current state and setter function from [state, setState].

When you call the setState function, React schedules a re-render of the component, updating the state with the new value you provide.

It’s important to note that directly mutating the current state value is discouraged.

// ❌ we will never do this...
count = count + 1

React relies on the setter function to determine when a re-render is necessary and tracks the correct state values. Therefore, it’s best to use the setter function to update the state value, as demonstrated below:

setCount(count + 1)

Code example

And here is the CodeSandbox.

Let’s break down this instance where we utilise the useState hook for creating a state variable, named count. This variable is initialised with a value of zero.

The next part of the code in the button incorporates the setCount function – a setter function provided by the useState hook. We’re using this function to manipulate the value of the count variable. Every time a user clicks on either the “Increment” or “Decrement” button, setCount will update the count value accordingly, increasing or decreasing it by one.

Lastly, we present the existing value of count on the screen.

Updating state triggering re-rendering

Whenever we modify the state using the setter function provided by React’s useState hook, it triggers a re-rendering of the associated component. This mechanism allows the component to display the updated state value.

For example, let’s take a look at the onClick function from the button.

Upon clicking any of these buttons, the setCount setter function is invoked to update the count value. Following this state update, React re-renders the Counter component and reflects the new count value.

If you’re keen to explore in more depth how React’s re-rendering works, you might find this article interesting.

Pass initial value via prop

In React, we have the option to assign an initial state value through a prop passed to the component. Here is how it’s done:

export default function Counter({ initCount }) {
  const [count, setCount] = useState(initCount);
  
  ...
}

With this setup, the component is rendered with the initial value specified by the prop.

We can provide a default value to prevent possible errors, as shown below:

export default function Counter({ initCount = 0 }) {
  const [count, setCount] = useState(initCount);
  
  ...
}

Furthermore, TypeScript can be utilised to establish a type guard for added safety and predictability in your code:

interface Props {
  initCount: number;
}

export default function Counter({ initCount = 0 }: Props) {
  const [count, setCount] = useState(initCount);
  
  ...
}

For the above example, neglecting to supply the initCount prop from the parent component will result in a type error, as illustrated in the following image:

Passing a function as the initial value

You can indeed pass a function as an initial value to React’s useState hook. This approach is particularly beneficial when the initial state value requires computation based on other values, or when you need to establish the initial value lazily.

Below is an example of utilizing a function to set the initial value with the useState hook:

In this example, the function is employed to calculate the initial value for the count state variable, taking into account the initialCount prop. When the component is initially mounted, the function supplied to useState gets executed to determine the starting value for count. Subsequent state updates won’t invoke this function again.

For example, from the parent component, we are sending 2 as a value of initCount.

and on the initial mount, the initial count value will show as 4.

We can also establish the lazy initialization by passing a function as an initial value. Let’s delve into the concept of lazy initialization.

Lazily initial value

The technique of passing a function as the initial value to useState can also be harnessed when you need to compute the initial state value lazily.

In React, the useState hook is invoked during every render, but the initial value you provide to useState is only used on the first render. On subsequent renders, the useState hook uses the current state value.

As we saw above from “Pass initial value via prop” section, if we provide a constant value as the initial state to useState, that value will not be “re-computed” on every render. The constant value is simply the initial value used for the state on the first render. On subsequent renders, React uses the current state value (whether it has changed or not).

However, if we provide a function call as the initial state (like slowComputedFunction()), that function will be invoked on every render unless you wrap it in a function. Let’s see an example:

In this instance, the data state is initialised by calling slowComputedFunction. However, given that useState is invoked with every render, the slowComputedFunction function call will also be invoked with each render, even if the state remains unchanged.

If slowComputedFunction is a costly operation or if the data seldom changes, this approach can lead to inefficiencies. A better alternative would be to compute the initial state value lazily by passing a function reference as the initial value to useState. In this case, the function gets called only once during the state’s initial setup.

From the React Hook Flow Diagram shown below, we can observe that lazy initialisers are executed solely during the initial render, specifically at the “Mount” stage, and are not triggered again during the update or unmount lifecycle stages.

So React employs a unique rule to compare the initial value with the preceding state value. When the initial value is a function, React understands that it needs to call this function to obtain the actual initial value.

Following the initial render, React will no longer call this function for the initial value, as it has already been computed and stored in the state. Instead, it will use the value preserved in the state and compare it with the new value each time you invoke the setState function.

Let’s look at a revised version of the code that lazily computes the initial data value:

By lazily computing the initial state value, we can enhance the performance of our component and sidestep redundant computations.

useState hook cannot be called conditionally

In React, consistency is key when it comes to calling hooks. Hooks need to be called in the exact same order during every render. If a hook is called conditionally, it might not be invoked on every render, leading to potential confusion regarding the order of hooks.

Let’s examine a code snippet to illustrate this:

if (isActive) {
  const [count, setCount] = useState(0);
}

Here, useState is called conditionally, depending on the value of the isActive prop. This can be problematic since useState must always be invoked in the identical order with every render. If isActive varies between renders, React might end up executing useState in an inconsistent order, resulting in unpredictable behaviour.

How can we prevent this issue? The answer lies in always calling hooks at the top level of our component, without making them conditional. If part of our component needs to be rendered conditionally, we can accomplish this without affecting the hook call. Here’s a proper way to structure the code:

const [count, setCount] = useState(0);

if (isActive) {
  setCount(1);
}

By adhering to this structure, we maintain the consistency of hook calls, and thereby ensure the predictable operation of our React components. It’s a simple adjustment, but one that carries significant implications for the stability and maintainability of our code.

Calling setter function multiple times

Have you ever wondered what happens when you call a setter function multiple times in React? Let’s dive into an example to explore this behaviour.

Consider the following code snippet:

What do you think will happen here?

Or how about this:

You might think that both instances will increase the count by 6. But the reality is different: the first one will increment it by 3, and the second one will increment it by 1. Surprised? Let’s understand why.

When you call setCount multiple times like this, React will batch the updates and perform the update only once. Moreover, JavaScript creates a closure around the count variable, and the new value of count will be based on the previous value. So when we look at the second example, we’re essentially doing:

Here, the final value of count will be incremented by the last call, setCount(0 + 1).

Now let’s optimise the second example (though the first one works the same):

In this optimised example, we’re using the function form of setCount. We’re passing it a function that takes the previous state as an argument and returns the new state based on that previous state.

These function calls will be executed in the order they were called. Each function we’re passing in will take the previous value as its argument. Unlike our earlier example where the count variable was not updated in time, these functions will receive all the previous values before them, incrementing the total by 6.

In conclusion, by calling setCount three times with this approach, React will update the count value by 6. Understanding how this works can be vital in writing more predictable and efficient React code and it quite often appears in technical interviews.

Working with Objects

Managing multiple states

In React, it’s common to encounter scenarios where we need to manage multiple states within a single component.

Let’s explore an example of adding another feature to the Counter component, where we introduce a button to show or hide the counter title.

To achieve this, we can employ multiple instances of the useState hook. Let’s take a look at the updated code:

In this example, we’ve added a new state, showCountTitle, which determines the visibility of the counter title. By toggling the button, we can toggle the display of the title. Managing multiple states using separate instances of useState is a perfectly valid approach.

Alternatively, if the states are closely related to each other, we can consolidate them into a single object. Here’s an example of using an object to manage both states related to the count:

In this approach, we use the countAction object to manage both the count and showCountTitle states. It is important to note that we need to spread the existing countAction object and then modifying the desired property to update the states accordingly.

When deciding between these approaches, it often comes down to personal preference. Personally, I find it clearer to use separate instances of useState when dealing with multiple states, as it allows for a more straightforward management of individual state variables. However, consolidating related states into a single object can be advantageous in certain scenarios where it provides better organisation and cohesion.

Updating and removing objects

In the above section, we explored how an object was used to hold the state value, and we briefly touched on updating values within the object. In React, when we work with objects for maintaining the state, we must handle updates and removals with care. Let’s explore this in detail.

Keep in mind that when you provide a value to the useState setter function, this value will entirely replace the existing state.

For example, if we choose to update only the count value:

const [countAction, setCountAction] = useState({
  count: 0,
  showCountTitle: true
});

...

// button - onClick
setCountAction({count: countAction.count + 1 });

// Output: {count: 1}
console.log(countAction);

Notice something wrong? When updating count, we accidentally removed the showCountTitle from the state object.

Let’s see another way it can go wrong:

const [countAction, setCountAction] = useState({
  count: 0,
  showCountTitle: true
});

setCountAction(countAction.count = countAction.count + 1); // ❌

// Output: 1
console.log(countAction);

Here, we tried to directly update the count value in the object, but this causes the entire object to be replaced with a single number. This leads to an error in subsequent operations as the count property is no longer accessible.

Another thing to remember is that useState will not trigger the component to re-render unless you set the value to a completely new value. Simply changing the values inside the object isn’t working properly.

So, how do we properly update a value within an object without losing the other properties?

We must merge the new value with the existing state object. This can be done by using JavaScript’s spread operator to spread all of the existing key/value pairs onto a new object. Then, we pass that new object to the setter function.

Here’s the corrected code:

const [countAction, setCountAction] = useState({
  count: 0,
  showCountTitle: true
});

...

// button - onClick
setCountAction({...countAction, count: countAction.count + 1 });

// Output: {count: 1, showCountTitle: true}
console.log(countAction);

By using this approach, we maintain the integrity of our state object, allowing us to successfully update individual properties without affecting others.

State depending on the previous state and get the updated state value

If we need to update a state based on the previous state, you might face some challenges going with an object.

In the earlier example, we used the spread operator to get the updated values in an object. We can also get the previous state and spread it.

Consider the following code:

const [countAction, setCountAction] = useState({
  count: 0,
  showCountTitle: true
});

...

// Updating object with current state
setCountAction({...countAction, count: countAction.count + 1 });

// Depending on the previous state
setCountAction((prev) => ({...prev, count: prev.count + 1 })

These two setCountAction setter functions give the same result. So what distinguishes them?

As we learned earlier from the section, “Calling setter function multiple times”, if we update the state based on the previous state, simply spreading the current state value won’t work.

Here’s an example to illustrate this point:

Clicking the button will output:

countAction {count: 0, showCountTitle: true}
Rendering {count: 1, showCountTitle: true}

Notice that the countAction log didn’t update the count value? It’s because useState is asynchronous and it doesn’t change the state immediately. Therefore the console log right after the setter function might not have the latest state value yet.

To make sure we get the updated value, we can access the previous state value within the setter function. Here’s an updated version:

This will give the output which shows the count value for countAction in onClick got updated.

countAction {count: 1, showCountTitle: true}
Rendering {count: 1, showCountTitle: true}

And we can further simplify the setter function:

Understanding these two approaches is essential for effectively managing asynchronous state changes and ensuring robust and reliable state management with objects.

Working with deeply nested objects

In our previous examples, we saw the application of the spread operator, …, within objects. It’s essential to understand that the … spread syntax operates on a “shallow” basis, meaning it only copies elements one level deep.

Here we have updated the state by adding countDetails.

const [countAction, setCountAction] = useState({
  count: 0,
  showCountTitle: true,
  countDetails: {
    title: 'Number count',
    author: 'Ryan Yu'
  }
});

If we wish to update the author within countDetails, the following approach won’t work:

The reason it fails is that it’s attempting to mutate the state, but in React, state is treated as immutable. Therefore, to update the author, we need to spread twice.

Now it gets trickier if the object is deeply nested.

For the deeply nested objects, one option is to flatten the object, but this would alter the state’s structure. If you wish to preserve the structure while updating a nested state value, Immer is a handy library to use. Below is a code example employing Immer.

// install immer
// https://github.com/immerjs/use-immer
yarn add immer use-immer

We’ve examined how to manage interconnected state with an object. Another way to handle various states is by using useReducer. I plan to write an article about this soon, so stay tuned!

Working with Arrays

We can manage arrays using useState too. Given the depth of this topic, I’ll address it in an upcoming blog post, where we’ll explore the proper techniques for handling arrays with useState. Keep an eye out for it!

Lifting state up

In React, “lifting state up” is a common pattern where shared state is moved to the closest parent component in the component tree. This state is then passed down to child components through props. This way, one component can manage the state, and the same state can be accessed across other child components.

Here’s an easy way to understand how it works:

The Problem

In our code example, there is a Counter component that includes the count value and a setCount setter function. If we add another Counter component in its parent App component, each Counter will manage its state separately.

But what if you want multiple Counter components to share the same count value?

The Solution

The good practice here is to “lift” the state up to the parent App component. This way, each Counter component will share the same count value.

Here’s the intended design:

And here is the updated code.

The Code

We start by lifting up the state to the App component and send the count value through the count prop to the Counter components.

To update the count, we use the setter function in the parent component, where the state lives, and send this setter function through the prop. The child components can then invoke this function.

When considering whether to lift up the state, ask yourself:

Do any other components, including parent or sibling components, need to know the change of the state value?

If the answer is yes, it’s better to lift the state up, allowing easy sharing with other components. If not, you can keep the state in the local component itself.

Managing shared state can be done in other ways too, such as using the Context API. Stay tuned for a future article where we will delve into this topic in detail!

Derived state

Derived state in React refers to a regular JavaScript variable that is computed based on existing state or props. This concept can help us make our components more efficient by avoiding unnecessary re-renders. Let’s break down this concept with an example.

Imagine we have another section in the counter app that displays the number of characters of the title. When the focus gets out of the title element, the character count should also update.

You might be tempted to add another state to track the character count of the title, updating it whenever the title changes:

While this works, calling setCountTitleChar triggers an extra re-rendering of the component, which isn’t ideal.

Since we are already storing the countTitle.length value, we can derive it and store it in a variable, without needing additional state management:

With this approach, even though countTitleChar isn’t managed as a state, it’s computed from countTitle every time the countTitle value is updated which causes the re-execution of the component and ensures the correct value is rendered without unnecessary re-rendering.

Derived state can be a powerful tool in optimising the React components. By understanding how to compute variables directly from existing state or props, we can eliminate extra re-renders and make our components more efficient.

Infinite re-rendering caused by state updates

If you’ve ever faced an issue where your browser gets frozen due to infinite re-rendering in your React application, you know how troubling it can be. In this section, we’ll look at a common scenario that causes this and how to fix it using React’s useEffect hook.

A Troubling Scenario

Imagine you want to fetch some data from the server and display it. You may try something like this:

Warning: Running the below code will cause an infinite loop of re-rendering, freezing your browser. If this happens, you’ll need to forcibly close the browser tab. In Chrome, go to Windows > Task Manager, find your application, and end the process. For Firefox users, click the menu button > More tools > Task Manager.

// Counter.tsx
...

const [posts, setPosts] = useState([]);

console.log("rendering");

const fetchPosts = async () => {
  const response = await fetch("https://jsonplaceholder.typicode.com/posts");
  const posts = await response.json();

  setPosts(posts);
};

fetchPosts();

...

Why Does This Happen?

Upon running the code, you’ll notice the word render gets logged infinitely. This is because each time fetchPosts() runs, it sets a new posts array in memory, even if the data is the same. Since React treats these arrays as different, it triggers re-rendering, calling fetchPosts() again and creating an infinite loop.

To illustrate this point further, consider this JavaScript example:

if ([1,2,3] === [1,2,3]) { 
  console.log('same')
} else {
  console.log('different')
}

This code will log different, because even though the two arrays look the same, they are different in memory.

The Solution: Using `useEffect`

You can break this infinite loop by utilising the useEffect hook to handle side effects like fetching data:

// Counter.tsx
...

const [posts, setPosts] = useState([]);

console.log("rendering");

useEffect(() => {
  const fetchPosts = async () => {
    const response = await fetch(
      "https://jsonplaceholder.typicode.com/posts"
    );
    const posts = await response.json();
    setPosts(posts);
  };
  
  fetchPosts();
}, []);

fetchPosts();

...

By wrapping the fetchPosts function inside useEffect, and providing an empty dependency array, we ensure that the fetching happens only once when the component mounts, thus avoiding the infinite loop.

Infinite re-rendering can be a confusing issue, but understanding how React treats arrays and objects in memory can help you recognize and fix the problem. By using the useEffect hook properly, you can manage side effects and prevent infinite loops. Stay tuned for an upcoming deep-dive article on useEffect where we’ll explore this topic in greater detail!

Using React DevTools to Inspect states

React DevTools is a powerful tool that enables you to inspect React components within your browser. It provides a detailed view of the state, props, hooks, and more, offering invaluable insights into your application. Here’s how you can use React DevTools to examine your React states.

First, you’ll need to install React DevTools as an extension in your browser. Once installed, you will notice two new extensions in your toolbar, labeled “Components” and “Profiler.”

Clicking on the “Components” extension opens the Inspector, where you can view and explore your React components.

Select the component you want to inspect, and you’ll see details like props, hooks (including state and effects), and more.

To view the specific names of the state, there’s a “magic button” you can click to parse the hook names. This will reveal the exact names used in your code.

I hope this article on useState in React was clear and helpful. If you have more questions or just want to chat, find me on LinkedIn. I’m always happy to talk about React!