React 学习及使用心得----1

1. React更新状态（state）的顺序与 setState的调用顺序是一致的，不管是在同一个组件（见代码段1）还是在不同的组件中（见代码段2），所以在代码段1和代码段2中不会出现 {a: false, b: true} 这种情况。也不论是否 setState 是否处于批处理（batch）中。

// 代码段1
class Container extends React.Component {
  constructor(props) {
    super(props);
    this.state = { a: false, b: false };
  }
  render() {
    return 
  }
  handleClick = () => {
    this.setState({ a: true });
    this.setState({ b: true });
  }
}

//代码段2
class SuperContainer extends React.Component {
  constructor(props) {
    super(props);
    this.state = { a: false };
  }

  render() {
    return 
  }
}

class Container extends React.Component {
  constructor(props) {
    super(props);
    this.state = { b: false };
  }

  render() {
    return 
  }

  handleClick = () => {
    this.props.setParentState({ a: true });
    this.setState({ b: true });
  }
}

2. 状态（state）更新的中间状态是否可见取决于 setState 是否处于批处理中。
   React 16 及更早版本中, 只有 React 事件处理器（event handler）中的更新默认是批处理的。其他更新可通过React 目前提供的 ReactDOM.unstable_batchedUpdates API 来手动设置批处理。
   因此如果 setState 在事件处理器之外，例如在 AJAX 请求的回调中，每个 setState 都会立即被处理（即 按照该 setState 指定内容去更新状态，然后立即进行重新渲染 re-render，而不再是批处理中将几个 setState 合并后只进行一次重新渲染）。
   具体参考如下代码段，据 Dan Abramov 老哥说，React 在未来的 17 版本将会统一将 setState 默认批处理，无论其是否在事件处理器中，这样对多数应用情况而言更方便。（未来版本可能不再提供 unstable_batchedUpdates，其命名前缀也反映了这一点）。

promise.then(() => {
  // 不在事件处理器中，因此重渲染独立进行
  this.setState({a: true}); // Re-renders with {a: true, b: false }
  this.setState({b: true}); // Re-renders with {a: true, b: true }
  this.props.setParentState(); // Re-renders the parent
});

promise.then(() => {
  // 强制批处理
  ReactDOM.unstable_batchedUpdates(() => {
    this.setState({a: true}); // Doesn't re-render yet
    this.setState({b: true}); // Doesn't re-render yet
    this.props.setParentState(); // Doesn't re-render yet
  });
  // 当退出 unstable_batchedUpdates 的时候，只进行一次 re-renders 
});

3. 猴子都知道 setState 是异步的，至少在效果上是这样，究其原因，look here
   )