Top 4 Traps in React State Management

Note: I will stick to the class notation and not use the more modern functional component notation using hooks, as this is what we see currently in repos having issues with state. It seems the legacy code base is quite substantial.

In a single-page application, the state management need to cater for several aspects:

React provides props and state. The major difference is that props is used to communicate from the component higher in the hierarchy to sub-components. It communicates data points as well as callback functions. Components need to treat props strictly read-only and should behave like pure functions to them.

A pure function has two properties:
(1) The same return value given the same arguments
(2) No side effects by changing the state

So, no local state, changing external state or inputs from streams.

OK, obviously, in real life we need to interact with the environment somewhere. So the golden rule is to try to keep your state as high in the hierarchy as possible . The functional sub-components get their data via props and use callback functions to communicate the need for change of state to the higher-level component. This guarantees to keep one truth and make sure all components display consistent data.

So far so easy… in theory. In practice, physics comes into play. To optimize performance, React applies some tricks. For example, changes to props and state are collected and executed in one batch. But this means a component cannot always rely on the props and state to reflect the latest. This is the source of a tricky class of bugs that are really nasty. Nasty because you might see performance issues in some circumstances (aka redraws) or depending on the load, you will see your app behaving strangely. Hard to reproduce bugs for sure.

In JavaScript, objects or arrays (aka compound values) are managed by keeping references. For example, this code will not copy the object or array but rather copy the reference.

So, when this component changes elements within the compound value in its state, it actually changes the original object, aka violating the rule to never change your props.

I guess by now you see where the problem is but we found this type of code literally in tens of thousands of repos. So, how to do it better?

We used a different version of the setState() function by providing a function. This function gets two parameters (I showed both of them for reference) which are safe state and props to use. Using the spread operators ... we generated a new instance with a copy of the initial array.

The spread operators ... on arrays (or any iterable) expands the array into zero or more individual elements.

Since the elements are treated individually, it results in a new array.

Warning: This goes only one level deep!

I kept close to the original code. You can remove some of the syntactical overloads and get a very slick one-liner:

As mentioned above: Simply do not change props. The mechanism is meant to communicate from higher up the hierarchy to sub-components. It is not meant to store state or communicate back. Still, we find this to be done quite commonly in our training set.

Not always is it as obvious as here. As mentioned above, using a shallow copy could result in changing props data. DeepCode's engine is capable of following references and identify props data even when handed over to functions or stored somewhere.

How to prevent this issue? Well, simply treat props data as absolutely immutable.

In general, expect the state to reflect what is currently rendered and use setState() as shown above when you need state or props to calculate the new state. Simply, stick to the best practices on state and setState(). Again, DeepCode is here to help. We added suggestions that will point out possible issues on using setState().

A very common mistake is to copy props values into the state object in the constructor. Two things need to be considered: First, it is simply not necessary. Take the value from the props when you need it. Second, the constructor is called once in the lifetime of a component. During an update of the component with changed props, the state copy might be outdated.

Related posts:

We collected 28 of the best free online 3 player games. These games include browser games for both your computer and mobile devices, as well as apps for your Android and iOS phones and tablets. They…

I acknowledge that following is annoying to deal with and quite frankly boring as all hell. But if one, only one poor soul, comes across this poison, then at least I may die with a clear conscious to…

Writing has never been my passion, it didn’t fascinate me and I never thought of writing on any platform. But at some point in life, I came to realize that I did not have words to describe my…