[Web 前端] 我不再使用React.setState的3个原因

copy from : https://blog.csdn.net/smk108/article/details/85237838

从几个月前开始，我在新开发的React组件中不再使用setState。我并没有停止使用局部组件状态，只是不再用React来管理这些state，这是很不错的一个选择。

对于React初学者来说，使用setState是比较棘手的。即使是经验丰富的React开发者，在使用React本身的状态管理机制时，也经常会出现一些比较微妙的bug，例如：

忘记setState是异步的导致的bug：控制台的输出总是落后一项

React文档总结了使用setState时可能会出现的所有问题：

总的来说，使用setState有如下3个问题：

1、setState是异步的

很多开发者刚接触React时并没有注意到setState是异步的，如果你同时修改一些state，然后马上去调用某个state，得到的是之前的值，并不是修改后的。这是使用setState时最棘手的地方。如果在使用setState时没有注意到它是异步的，就会导致一些棘手的bug。

class Select extends React.Component {
  constructor(props, context) {
    super(props, context)
    this.state = {
      selection: props.values[0]
    };
  }
  
  render() {
    return (
      <ul onKeyDown={this.onKeyDown} tabIndex={0}>
        {this.props.values.map(value =>
          <li
            className={value === this.state.selection ? 'selected' : ''}
            key={value}
            onClick={() => this.onSelect(value)}
          >
            {value}
          </li> 
        )}  
      </ul>
    )
  }
  
  onSelect(value) {
    this.setState({
      selection: value
    })
    this.fireOnSelect()
  }
 
  onKeyDown = (e) => {
    const {values} = this.props
    const idx = values.indexOf(this.state.selection)
    if (e.keyCode === 38 && idx > 0) { /* up */
      this.setState({
        selection: values[idx - 1]
      })
    } else if (e.keyCode === 40 && idx < values.length -1) { /* down */
      this.setState({
        selection: values[idx + 1]
      })  
    }
    this.fireOnSelect()
  }
   
  fireOnSelect() {
    if (typeof this.props.onSelect === "function")
      this.props.onSelect(this.state.selection) /* not what you expected..*/
  }
}
 
ReactDOM.render(
  <Select 
    values={["State.", "Should.", "Be.", "Synchronous."]} 
    onSelect={value => console.log(value)}
  />,
  document.getElementById("app")
)

乍一看，上面的代码并没有什么问题。两个事件处理函数（onKeyDown、onSelect）和一个功能函数（fireOnSelect）触发props的onSelect（如果存在）。上面的gif动态图很好的证明了Select组件的bug，当fireOnSelect被调用时，setState的操作并没有完成，因此，props的onSelect调用时传入的参数总是state中selection修改前的值。我认为React可以做的是将方法名重命名为scheduleState（注:我理解的意思是将方法置为调度状态，等setState操作完成后再执行）或者要求回调函数是必须的。

这个问题很容易修复，重点是要意识到这是个问题。

2018年1月25号注：Dan Abramov非常详细地解释了为什么setState被设计成异步的。

2、setState会引起不必要的渲染（render）

setState的第二个问题是它会触发很多不必要的重新渲染。你可以使用React性能工具提供的printWasted方法监控什么时候触发了不必要的重新渲染。粗略地说，认为一次重新渲染是必要的有以下原因：

1）state新设置的值和上一次的值完全一样。这种情况通常可以通过实现shouldComponentUpdate生命周期来解决，或者你已经在使用一些库(pure render)来解决这个问题。

2）有时state的修改与UI显示相关，但也有些例外。比如一些state用于条件可见的UI时。

3）正如Aria Buckles在2015年欧洲React会议上的演讲中提到的，一些实例状态与UI的展示完全不相关！通常一些是与管理事件监听器、计时器ID等相关的内部控制状态。

3、setState不足以管理所有的组件状态

正如上面2的最后一条所说，并不是所有组件状态都应该使用setState存储和更新。很多复杂组件通常需要使用生命周期函数来管理一些内容，例如：计时器、网络请求、事件等。使用setState管理这些复杂组件的状态不仅会触发重新渲染，还会导致一些相关的生命周期函数再次被触发，进而导致一些奇怪的状况。

使用MobX管理局部组件状态

(Surprise, surprise) 在Mendix，我们已经使用Mobx来管理所有的store。之前我们依然使用React的状态管理机制（setState）来管理局部组件状态。最近，我们连局部组件状态也换成了使用Mobx来管理。参考下面的例子：

import {observable} from "mobx"
import {observer} from "mobx-react"
 
@observer class Select extends React.Component {
  @observable selection = null; /* MobX managed instance state */
 
  constructor(props, context) {
    super(props, context)
    this.selection = props.values[0]
  }
  
  render() {
    return (
      <ul onKeyDown={this.onKeyDown} tabIndex={0}>
        {this.props.values.map(value =>
          <li
            className={value === this.selection ? 'selected' : ''}
            key={value}
            onClick={() => this.onSelect(value)}
          >
            {value}
          </li> 
        )}  
      </ul>
    )
  }
  
  onSelect(value) {
    this.selection = value
    this.fireOnSelect()
  }
 
  onKeyDown = (e) => {
    const {values} = this.props
    const idx = values.indexOf(this.selection)
    if (e.keyCode === 38 && idx > 0) { /* up */
      this.selection = values[idx - 1]
    } else if (e.keyCode === 40 && idx < values.length -1) { /* down */
      this.selection = values[idx + 1]
    }
    this.fireOnSelect()
  }
   
  fireOnSelect() {
    if (typeof this.props.onSelect === "function")
      this.props.onSelect(this.selection) /* solved! */
  }
}
 
ReactDOM.render(
  <Select 
    values={["State.", "Should.", "Be.", "Synchronous."]} 
    onSelect={value => console.log(value)}
  />,
  document.getElementById("app")
)

上面例子中的错误不会再出现：

使用同步的状态机制时，不会出现意外的错误

上面的示例代码不仅看起来更简洁，Mobx解决了所有setState相关的问题：

状态的更改会立即反映在局部组件状态中，这是我们的逻辑更简单，代码复用更容易，并且你不需要为状态尚未更新这一事实进行补偿（注：个人理解是需要额外的操作或代价）。

Mobx在运行时确定哪些可观察状态与UI渲染相关，暂时与UI无关的可观察状态不会导致组件的重新渲染，直到这些状态再次与UI相关。因此，将于UI无关的字段标记为@ observable（可观察状态）时，也不会出现上面提到的渲染代价或生命周期问题。

根据上面的解释，可渲染状态和不可渲染状态可以被统一管理。另外，存储在组件内部的状态和存储在store中的状态工作方式相同，可以达到一样的效果。这使得在必要时的组件重构、将组件内状态移动到单独的store或者将状态从store移动到组件内都很简单，在egghead的教程中有演示。

Mobx有效地将组件转换为小型store。

此外，在使用可观察状态时，不会再出现直接给state赋值这样的低级错误。并且，我们不需要在为实现shouldComponentUpdate或PureRenderMixin而担忧，Mobx已经为我们解决了这个问题。最后，你可能会问，如果我想还使用setState并且等setState完成该怎么办，Mobx允许你仍然可以使用compentDidUpdate生命周期。

如何开始使用Mobx？

开始学习使用Mobx也十分简单，你可以学习10分钟介绍或观看上面提到的视频。你可以简单地从你现有的代码中选取一个组件，使用@observer装饰它，并使用@observable引入一些可观察状态，你甚至不需要替换现有的setState调用，因为它们在使用Mobx时依然可以正常工作（虽然几分钟之内你就会感觉setState太繁琐，然后使用Mobx替换它）。如果你不喜欢使用装饰器也不需要担心，Mobx也可以配合es5一起使用。

我已经在使用Mobx管理局部组件状态，不再使用React的setState，现在React是真正的’just the view’。在我的组件中，Mobx已经同时管理局部组件状态和store中的状态，它是简洁、同步、高效、统一的。从经验中，我感觉Mobx比React的setState更容易让React初学者理解。Mobx可以我们保持组件的简洁与简单。

JSBin： 使用setState管理状态

JSBin：使用Mobx管理状态

注：1、本文为翻译Michel Weststrat（@mweststrate）的文章，原文地址：https://blog.cloudboost.io/3-reasons-why-i-stopped-using-react-setstate-ab73fc67a42e

2、在我csdn的Mobx系列中有介绍Mobx的使用。