Skip to content

Latest commit

 

History

History
77 lines (63 loc) · 1.77 KB

no-did-update-set-state.md

File metadata and controls

77 lines (63 loc) · 1.77 KB

Prevent usage of setState in componentDidUpdate (no-did-update-set-state)

Updating the state after a component update will trigger a second render() call and can lead to property/layout thrashing.

Rule Details

The following patterns are considered warnings:

var Hello = React.createClass({
  componentDidUpdate: function() {
     this.setState({
        name: this.props.name.toUpperCase()
      });
    },
  render: function() {
    return <div>Hello {this.state.name}</div>;
  }
});

The following patterns are not considered warnings:

var Hello = React.createClass({
  componentDidUpdate: function() {
    this.props.onUpdate();
  },
  render: function() {
    return <div>Hello {this.props.name}</div>;
  }
});

Rule Options

...
"no-did-update-set-state": [<enabled>, <mode>]
...

allow-in-func mode

By default this rule forbids any call to this.setState in componentDidUpdate. But in certain cases you may need to perform asynchronous calls in componentDidUpdate that may end up with calls to this.setState. The allow-in-func mode allows you to use this.setState in componentDidUpdate as long as they are called within a function.

The following patterns are considered warnings:

var Hello = React.createClass({
  componentDidUpdate: function() {
     this.setState({
        name: this.props.name.toUpperCase()
      });
    },
  render: function() {
    return <div>Hello {this.state.name}</div>;
  }
});

The following patterns are not considered warnings:

var Hello = React.createClass({
  componentDidUpdate: function() {
    this.onUpdate(function callback(newName) {
      this.setState({
        name: newName
      });
    });
  },
  render: function() {
    return <div>Hello {this.state.name}</div>;
  }
});