DEV Community

Discussion on: How not to update states in React!!

Collapse
lukeshiru profile image
LUKESHIRU

The first one is fine for the vast majority of scenarios, and you should use it, so that title "How not to update states in React" is wrong. A more fitting title would be "How to update states in React with async operations" or something like that.

The second example is only useful if you need to know the previous value of the state, instead of the current, which generally is if you're updating the state asynchronously or from some scheduler like setInterval, setTimeout or requestAnimationFrame.

As you mentioned, the state updates are scheduled, not ran in place, so the value of the state will not be changed until next render. One pretty common mistake folks do is they want to update the same state several times in the same render, so they might do something like this:

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

// In some callback:
setCount(count + 1);
setCount(count + 1);
setCount(count + 1);
Enter fullscreen mode Exit fullscreen mode

And then they realize that instead of having 3, they just have 1 ... so they might fall into the mistake of using the callback to "resolve" the issue:

setCount(prevCount => prevCount + 1);
setCount(prevCount => prevCount + 1);
setCount(prevCount => prevCount + 1);
Enter fullscreen mode Exit fullscreen mode

Yey! They got 3.... but the actual correct approach for scenarios like this, is to set the value once you actually are sure of it, instead of scheduling 3 state changes:

let totalCount = count;
totalCount += 1;
totalCount += 1;
totalCount += 1;
setCount(totalCount);
Enter fullscreen mode Exit fullscreen mode

Obviously this example is ridiculous, but is only to illustrate that if you need to do several changes in the same state, you should do them before you set the state, in a temporary variable if necessary.

Cheers!

Collapse
nehal_mahida profile image
Nehal Mahida Author

Thanks, man, You put great points 🙏🏻

Trust me it adds value to my post.

Regarding the title, Yes the first approach works most of the time.
But don't you think if programmers follow the second approach from starting itself, they don't need to worry about state updates ( asynchronous or synchronous) at the end?

As the world moves towards pair or group programming it is a good habit to make a RIGHT approach a default one. 🤗

Happy Coding!!

Collapse
lukeshiru profile image
LUKESHIRU

As I mentioned in my initial comment, the problem with the second approach is that you're scheduling more state changes (so you're making React do more work than what it should). The idea with having the value and the callback options is that you should use the one that does the job correctly, not use "always the same". The rule is simple: Do you need the current state? Use the value approach. Do you need the past state or are you running outside React's scheduler? Use the callback.

I would even dare to say that usually the callback approach is a "code smell", because we actually need to use it in extremely particular scenarios.

Thread Thread
nehal_mahida profile image
Nehal Mahida Author

You are right. My article is all about when you need the previous value of the state then and then you need to use the callback function in setState otherwise it's fine.