State Management in React Apps — Part I

If you know how to properly use JSX and how React components communicate with each other you are a true hero. However, you should ask yourself one important question: where to store information that your application cares about?

Let’s talk about application state management in React.

There are a lot of ways to handle application state but first, let’s take a look at the simplest one — components’ state.

React Components’ State

You might have previously seen this.state. A component has its' local state, an object with a purpose to keep information important to the component, like that movie list you were supposed to render. This local state is firstly initialized in the constructor, like this:

constructor() {    super();    this.state = {        itemKey: defaultItemValue,        ...    };}

Keep in mind that you should define a default value for each of the state attributes you will use in the component, even if the initial value is undefined.

What should you store in components’ state? There is a debate on when to use components’ state, and when to move to a bit more advanced approach: many developers in the past were forcing the philosophy that you shouldn’t use this.state at all, but you should keep everything in the globally accessible state (i.e. redux state - which will be mentioned a bit later), even if it's just a simple toggle used for conditional rendering.

However, there is no point in keeping a value in the redux state if it is only used inside this one component; and if the application that is being developed is pretty simple, there’s no need to introduce yet another dependency like a separate library for state management. In the beginning, when learning React, it’s better to stick to using this.state, as it doesn't require diving into yet another library.

React components’ state is asynchronously updated. You will use this.setState function to update your state. However, there is a thing to always keep in mind: you shouldn't use setState two times in a row when one setState depends on the previous one, due to its' asynchronous nature.

// assuming this.state.count === 0this.setState({    count: this.state.count + 1});this.setState({    count: this.state.count + 1});// it doesn't necessarily mean that this.state.count will be 2 now

However, you can use so called functional setState for setting the state dependent on previous state or on some of components’ props:

this.setState((previousState, currentProps) => {    return {        count: previousState.count + 1,    };});

Using functional setState is the best way to use setState.

If you want to change multiple values kept in the state, you don’t need to call setState multiple times:

// "standard" waythis.setState({    item1: value1,    item2: value2,});// "functional" waythis.setState((previousState, currentProps) => {     return {         item1: value1,         item2: value2,     };});

The state shouldn’t be mutated. This applies both to simple components’ state and some bit more advanced ones, like third-party redux state. Components’ state should only be changed by using setState function. While you can just use this.state.disabled = true, it won't trigger rerendering of the component. There is no prevention of mutating items kept in the state, so you have to care about not mutating them yourself.

So far I’ve covered React components’ state and its’ three basic concepts: it’s immutable, asynchronous and local. It is a quick way to handle storing information in simple apps, but also for local variables that should be accessed from multiple places inside a components’ instance, even in really big and complex applications.

However, for more complex applications, for components that are too dependent on each others’ state, and for better handling of the data used by an application, there are third-party libraries like Redux, Flux, CerebralJS and many other, which provide more advanced ways to handle app state. I’ll be sure to write more about them some next time.

Be sure to stay tuned for more React content!

Originally published at kolosek.com on June 4, 2018.