Recommend using componentWillMount instead of using a constructor

[jonricaurte]

Do you want to request a feature or report a bug?
feature

What is the current behavior?
In the docs it is recommended to use the constructor over componentWillMount.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://jsfiddle.net or similar (template: https://jsfiddle.net/ebsrpraL/).

What is the expected behavior?
Recommend using componentWillMount over a constructor. In ES6 classes React does not have to provide a lifecycle hook before mounting since constructors are already defined, however, constructors are generally confusing considering they have their own ways of defining things in React. Take the following example from the tutorial:

constructor(props) {
  super(props);
  this.state = {
    color: props.initialColor
  };
}

If this were written in componentWillMount, it would look like the following:

componentWillMount() {
  const { initialColor } = this.props;
  this.setState({
    color: initialColor
  });
}

There is no weird having to pass to super(props) which only happens in constructors and nowhere else in React. Also setting state is different only in the constructor and nowhere else in React. Using componentWillMount, you extract props like you normally would in any other method in a React class. Also setting state is exactly the same as every other method in a React class. I feel like having the consistency of componentWillMount is better even though ES6 classes do provide a constructor. componentWillMount also supports server rendering. Are there any benefits performance wise using a constructor over componentWillMount? Thanks!

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
React 16

[jonricaurte]

Another benefit is componentWillMount can also use other methods defined in the class to set state since the way it sets state is the same. In the following example in the docs (https://reactjs.org/docs/state-and-lifecycle.html#adding-lifecycle-methods-to-a-class) you have this code:

https://codepen.io/gaearon/pen/amqdNA?editors=0010

class Clock extends React.Component {
  constructor(props) {
    super(props);
    this.state = {date: new Date()};
  }

  componentDidMount() {
    this.timerID = setInterval(
      () => this.tick(),
      1000
    );
  }

  componentWillUnmount() {
    clearInterval(this.timerID);
  }

  tick() {
    this.setState({
      date: new Date()
    });
  }

  render() {
    return (
      <div>
        <h1>Hello, world!</h1>
        <h2>It is {this.state.date.toLocaleTimeString()}.</h2>
      </div>
    );
  }
}

ReactDOM.render(
  <Clock />,
  document.getElementById('root')
);

This could be rewritten like the following with componentWillMount:

https://codepen.io/anon/pen/gGXbbb?editors=0010

class Clock extends React.Component {
  componentWillMount() {
    this.tick();
  }

  componentDidMount() {
    this.timerID = setInterval(
      () => this.tick(),
      1000
    );
  }

  componentWillUnmount() {
    clearInterval(this.timerID);
  }

  tick() {
    this.setState({
      date: new Date()
    });
  }

  render() {
    return (
      <div>
        <h1>Hello, world!</h1>
        <h2>It is {this.state.date.toLocaleTimeString()}.</h2>
      </div>
    );
  }
}

ReactDOM.render(
  <Clock />,
  document.getElementById('root')
);

I'm just confused as why using a constructor is the suggested way of doing things. It seems like there are no benefits other than to say you can use an ES6 constructor. Thanks.

[fanny]

Maybe this article will help you: https://daveceddia.com/watch-out-for-undefined-state/

[fanny]

and this: https://reactarmory.com/guides/lifecycle-simulators

[prashanthr]

According to the React docs
https://reactjs.org/docs/react-component.html#mounting
the following is the lifecycle of a mount

constructor()
componentWillMount()
render()
componentDidMount()

What you're saying makes total sense and could probably be done this way. However if you have a little bit of asynchronous state handling going on, your render will be called with a state of null as that is how it begins. In which case, it's always safest to use the constructor to define initial state. Of course if you use redux, you can control default behavior using your reducers or default props.

[bvaughn]

The documentation and source code for reactjs.org now lives in a different repository: reactjs/reactjs.org. (For more info on why we made this move, see issue #11075.)

Feel free to open this issue in that repository to continue the conversation. Sorry for the inconvenience.