Documentation for this.state mutation seems contradictory

[mitchabaza]

In the documentation for the component API , it says:

NEVER mutate this.state directly, as calling setState() afterwards may replace the mutation you made. Treat this.state as if it were immutable.

However, the documentation for ES6 Classes says:

The API is similar to React.createClass with the exception of getInitialState. Instead of providing a separate getInitialState method, you [can mutate] this.state in the constructor.

Perhaps it would be possible to make this exception to this.state mutation more clear?

[aweary]

You aren't mutating this.state in the constructor, the API specifically says:

The API is similar to React.createClass with the exception of getInitialState. Instead of providing a separate getInitialState method, you set up your own state property in the constructor.

Setting up state isn't the same as mutating state. With ES6 classes you provide the initial state by creating the state object on the component instance.

constructor(props) {
  super(props)
  // this.state doesn't exist before you define it
  this.state = {}  
}

Even if state did exist before you initialize it in the constructor you're assigning a new value to it, not muting the existing state object, so it would still not be considered a mutation.

[zpao]

We could make this clearer though as there is some divide. @aweary would you want to try adding an additional sentence clarifying why this assignment is required in ES6 classes?

[aweary]

@zpao sure, I'd he happy to.