根据 React 的设计，所有的 DOM 变动，都先在虚拟 DOM 上发生，然后再将实际发生变动的部分，反映在真实 DOM上，这种算法叫做 DOM diff
这些生命周期在深入项目开发阶段是非常重要的。而要完全理解更新阶段的组件生命周期是一个需要经验和知识积累的过程，你需要对 Virtual-DOM 策略有比较深入理解才能完全掌握，但这超出了本书的目的。本书的目的是为了让大家快速掌握 React.js 核心的概念，快速上手项目进行实战。所以对于组件更新阶段的组件生命周期，我们简单提及并且提供一些资料给大家。
但这里建议大家可以先简单了解 React.js 组件是有更新阶段的，并且有这么几个更新阶段的生命周期即可。然后在深入项目实战的时候逐渐地掌握理解他们，现在并不需要对他们放过多的精力。
让我们来看看每一条，找出哪一个是 state。每个数据只要考虑三个问题：
它是通过 props 从父级传来的吗？如果是，他可能不是 state。
它随着时间推移不变吗？如果是，它可能不是 state。
你能够根据组件中任何其他的 state 或 props 把它计算出来吗？如果是，它不是 state。
原产品列表被作为 props 传入，所以它不是 state。搜索文本和复选框似乎是 state，因为它们随时间改变并且不能由其他任何值计算出来。最后，产品的筛选列表不是 state，因为它可以通过将原始产品列表与搜索文本和复选框的值组合计算出来。
最后，我们的 state 有：
用户输入的搜索文本
复选框的值
值得注意的是， setState 是一个异步方法，一个生命周期内所有的 setState 方法会合并操
作。关于 setState 的实现原理，请参见 3.4 节。
有了这个特性，让 React 变得充满了想象力。我们完全可以只用 React 来完成对行为的控制、
数据的更新和界面的渲染。然而，随着内容的深入，我们并不推荐开发者滥用 state，过多的内部
状态会让数据流混乱，程序变得难以维护。
如果我们在 componentWillMount 中执行 setState 方法，会发生什么呢？组件会更新 state，
但组件只渲染一次。因此，这是无意义的执行，初始化时的 state 都可以放在 this.state
如果我们在 componentDidMount 中执行 setState 方法，又会发生什么呢？组件当然会再次更
新，不过在初始化过程就渲染了两次组件，这并不是一件好事。但实际情况是，有一些场景不得
不需要 setState，比如计算组件的位置或宽高时，就不得不让组件先渲染，更新必要的信息后，
再次渲染。
对你应用的每一个 state：
- 确定每一个需要这个 state 来渲染的组件。
- 找到一个公共所有者组件(一个在层级上高于所有其他需要这个 state 的组件的组件)
- 这个公共所有者组件或另一个层级更高的组件应该拥有这个 state。
- 如果你没有找到可以拥有这个 state 的组件，创建一个仅用来保存状态的组件并把它加入比这个公共所有者组件层级更高的地方。