Setting State Using State

We know that setState() is asynchronous…

So: it’s risky to assume previous call has finished when you call it. Also, React will sometimes batch (squash together) calls to setState together into one for performance reasons. If a call to setState() depends on current state, the safest thing is to use the alternate “callback form”.

setState Callback Form

this.setState(callback)

Instead of passing an object, pass it a callback with the current state as a parameter. The callback should return an object representing the new state.

1
this.setState((curState) => ({ count: curState.count + 1 }));

Abstracting State Updates

The fact that you can pass a function to this.setState lends itself nicely to a more advanced pattern called functional setState.

Basically you can describe your state updates abstractly as separate functions. But why would you do this?

1
2
3
4
5
6
// elsewhere in the code
function incrementCounter(prevState) {
  return { count: prevState.count + 1 };
}
// somewhere in the component
this.setState(incrementCounter);

Because testing your state changes is as simple as testing a plain function:

1
expect(incrementCounter({ count: 0 })).toEqual({ count: 1 });

This pattern also comes up all the time in Redux!

Here is a nice opinionated article on the subject of using functional setState

Mutable Data Structures in State

Mutable Data Structures

We know how to set state to primitives: mainly numbers and strings. But component state also commonly includes objects, arrays, and arrays of objects.

1
2
3
4
5
6
7
this.state = {
  // store an array of todo objects
  todos: [
    { task: "do the dishes", done: false, id: 1 },
    { task: "vacuum the floor", done: true, id: 2 },
  ],
};

You have to be extra careful modifying your array of objects!

1
2
3
4
5
6
7
8
completeTodo(id) {
  const theTodo = this.state.todos.find(t => t.id === id);
  theTodo.done = true; // NOOOOO -> WRONG WAY

  this.setState({
    todos: this.state.todos // bad -> VERY BAD WAY TO SET LIKE THIS
  });
}

Why? It’s a long story…

Mutating nested data structures in your state can cause problems w/ React. (A lot of the time it’ll be fine, but that doesn’t matter. Just don’t do it!)

Immutable State Updates

A much better way is to make a new copy of the data structure in question. We can use any pure function to do this…

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
completeTodo(id) {

  // Array.prototype.map returns a new array
  const newTodos = this.state.todos.map(todo => {
    if (todo.id === id) {
      // make a copy of the todo object with done -> true
      return { ...todo, done: true };
    }
    return todo;  // old todos can pass through
  });

  this.setState({
    todos: newTodos // setState to the new array
  });
}

Pure functions such as .map, .filter, and .reduce are your friends. So is the … spread operator.

There is a slight efficiency cost due to the O(N) space/time required to make a copy, but it’s almost always worth it to ensure that your app doesn’t have extremely difficult to detect bugs due to mischevious side effects.

Immutable State Summary

While it sounds like an oxymoron, immutable state just means that there is an old state object and a new state object that are both snapshots in time.
The safest way to update state is to make a copy of it, and then call this.setState with the new copy.
This pattern is a good habit to get into for React apps and required for using Redux.

Designing State

Designing the state of a React application (or any modern web app) is a challenging skill! It takes practice and time! However, there are some easy best-practices that we can talk about in this section to give you a jump-start.

Minimize Your State

In React, you want to try to put as little data in state as possible.

Litmus test

does x change? If not, ~~x should not be part of state~~. It should be a prop.
is x already captured by some other value y in state or props? Derive it from there instead.

Bad Example of State Design

Let’s pretend we’re modelling a Person…

1
2
3
4
5
6
7
this.state = {
  firstName: "Matt",
  lastName: "Lane",
  birthday: "1955-01-08T07:37:59.711Z",
  age: 64,
  mood: "irate",
};

Does Matt’s first name or last name ever change? Not often I hope…
Does Matt’s birthday ever change? How is that even possible!
Matt’s age does change, however if we had this.props.birthday we could easily derive it from that.
Therefore, the only property here that is truly stateful is arguably mood (although Matt might dispute this 😉).

Fixed Example of State Design

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
console.log(this.props);
{
  firstName: 'Matt',
  lastName: 'Lane',
  birthday: '1955-01-08T07:37:59.711Z',
  age: 64
}

console.log(this.state);
{
  mood: 'insane'
}

State Should Live On the Parent

Its better to support “downward data flow” philosophy of React. In general, it makes more sense for a parent component to manage state and have a bunch of “dumb” stateless child display components. This makes debugging easier, because the state is centralized. It’s easier to predict where to find state:

Is the current component stateless? Find out what is rendering it. There’s the state.

Todo Example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
class TodoList extends Component {
  constructor(props) {
    super(props);
    this.state = {
      todos: [
        { task: "do the dishes", done: false, id: 1 },
        { task: "vacuum the floor", done: true, id: 2 },
      ],
    };
  }
  /* ... lots of other methods ... */
  render() {
    return (
      <ul>
        {this.state.todos.map((t) => (
          <Todo {...t} />
        ))}
      </ul>
    );
  }
}

TodoList is a smart parent with lots of methods, while the individual Todo items are just <li> tags with some text and styling.

That’s all for now. Until next time 👋, Happy learning 🎉 💻

If you found this helpful, please give a shoutout to @gsavitha_ and share this article to help others. For more articles like this, subscribe to my Newsletter and get the latest updates straight to your inbox.

React State Patterns