New rule: react-set-state-with-function

[adidahiya]

Enforce usage of the callback form of this.setState

// bad
this.setState({ ... });
// good
this.setState((prevState, props) => ...);

[karfau]

From reading these docs the first approach it fine, as long as there are no occurences of this.state or this.props inside of it, right?
Would you still enforce the second approach to make sure code is more consistent, even though it is more typing all the time?

[vhfmag]

I don't know much about tslint and tsutils API, so that may be not feasible, but I think the ideal would be that the rule allows objects if props and state aren't used and enforce callback usage otherwise. Does that sound feasible?

[benbankes]

It seems like disallowing this.setState({...}); might be a little too restrictive. It seems like a better approach might be #172

[karfau]

From what I understand, the rule suggested in #172 is more flexible and covers more cases then this one. They have some overlap though and I can imagine a team deciding for this rule that might be simpler to implement and thus be more performent. So not sure if those two are duplicates or not.
Maybe the behavior suggested here could be provided by an option in the other rule to stop ading overlapping rules that might be confusing to choose from and configure.

[adidahiya]

closing in favor of #172