Why Do We Use this.setState()?

During my React assessment I was asked the question why we should use this.setState() and not just this.state.KEY = VALUE. This question stumped me. In my mind I thought that we were supposed to use this.setState() because it actually updates the state, meanwhile this.state.KEY = VALUE doesn’t. That just isn’t the case.

I was also thinking that we should never try to update the state by utilizing this.state.KEY = VALUE because we should consider this.state immutable. I had read that somewhere, but I never even bothered to look deeper into it, to find out why we should consider it to be immutable. I couldn’t explain my ‘why’ to the instructor because I didn’t even know.

So, here I am writing a blog post about it so that hopefully this can help myself, as well as someone else, gain a better understanding of the topic! Here we go!

According to the official React.js documentation, “Treat this.state as if it were immutable.” See, I knew I had seen it somewhere. So, let’s dive deeper into why this is the case.

The most important ‘why’ that I could find on this topic, at least in my opinion, is that when we use this.state.KEY = VALUE, while it may update the state, it does not re-render the component. Here is an example:

Let’s say you wanted to add a button to a site and every time it was clicked you wanted the counter that is displayed to increase.

Every time this button is clicked, the state will increase every time, the only problem is, the user wouldn’t see it. They would think that the button is broken because what is displayed will remain 0. This is because the component isn’t re-rendering every time the button is clicked.

Now, if we were to write our code using this.setState(), the counter displayed on the page will actually change every time it is clicked.

Why is this, you may ask? It’s because this.setState() synchronously updates this.state and re-renders the component. This means that setState triggers a change in the components state. It then tells React that the component and its children all need to be re-rendered with the newly updated state.

Another great thing to keep in mind in regards to this topic is that if you utilize the this.state.KEY = VALUE and then use setState() afterwards, it could replace the mutation you have made. This would mean you lost what you were trying to store into state and that isn’t something any of us wants to happen to our code!

I don’t know about you, but I now feel like I have a much better understanding of why we should be using setState() and not this.state.KEY = VALUE. There are other reasons as to why this is the case, but I’ll leave that up to you to explore!

Note: This blogs cover image comes from the beautiful Sierra Nevadas this past weekend when they got a light dusting of snow!

Resources

React.Component
State and Lifecycle

Second Note: This article was originally published on my Flatiron blog which was deployed using my GitHub Pages. This blog no longer exists, so I wanted share this helpful article. I made a few small edits to fit my style now.

Comments

[Joel Ruiz]

Also setState under the covers uses Object.assign which let's you use partial objects like {a:10} while this.state has {b:20}. this.state would end up with {a:10, b:20}.

[Oinak]

Hello!, Great article, thanks for sharing

I am also investigating these matters nowadays and recently discovered that if you have

class Foo extend Component {
  constructor(props){
    super(props)
    this.state = { foo: 1 }
  }
//...

And you are:

• using modern js or babel
• not doing extra stuff on the constructor

then, you can do:

class Foo extend Component {
  state = { foo: 1 }
//...

and it works the same.

I hope it helps.

[ducksauce88]

Great article! I'm currently looking for a job and while I know how to use what I know, sometimes I am not able to explain why. Thanks!!

[MartinJ]

That's a really helpful post. You have a great writing talent. Keep it up - I think that writing clear English is actually much more challenging than writing smart code!