一、什么是状态机
状态机可归纳为4个要素，即现态、条件、动作、次态。这样的归纳，主要是出于对状态机的内在因果关系的考虑。“现态”和“条件”是因，“动作”和“次态”是果。详解如下：
①现态：是指当前所处的状态。
②条件：当一个条件被满足，将会触发一次状态的迁移。
③动作：条件满足后执行的动作。动作执行完毕后，可以迁移到新的状态，也可以仍旧保持原状态。动作不是必需的，当条件满足后，也可以不执行任何动作，直接迁移到新状态。
④次态：条件满足后要迁往的新状态。“次态”是相对于“现态”而言的，“次态”一旦被激活，就转变成新的“现态”了
二、什么是事件
当类对象的某个状态发生变化时，系统将会通过某种途径调用类中的有关处理这个事件的方法或者触发控件事件的对象就会调用该控件所有已注册的事件处理程序等。
三、比较状态机和事件的区别
| 状态机 |
事件 |
| 状态机仅仅是状态迁移，并不关注状态变化后大家干什么。perfect，分离了关注点，所有组件可以选择自己想关注的“状态”来自适应变化。 |
关注事件和结果 |
| 谁都能得到状态 |
|
| 广播状态，主动选择适应。基本可以不用事件监听机制了。 | 注册-监听，全局监听管理。及耗浏览器性能 |
| 只管生不管养，如果土壤好，环境好，长的自然好 如果没有强硬的编码规范约束，肯定是一锅粥 |
管生管养，成本高，效率低 |
| 状态控制UI，导致UI的重用率高，界面和数据完整分开 | 通常的js框架界面模板多数用完即销毁，反复服务器存取 |
handleAdd: function() {
........
this.setState({items: oldItems});
.........
this.setState({items: oldItems});
}
五、原则
1）如果使用react你的第一原则就是使用状态机去解决一切，别用flux这些插件。
非官方的react-router,react-motion，他们都是使用非状态机的方式来做的，更应该避而远之。
2）让状态进入系统设计，变为系统开发过程全程可控的。
3）UI被状态全程控制。状态不能滥用，只能用于UI控制
4）状态双向绑定：系统设计严格区分层级，控制状态传递在父子之间，祖辈之间禁止传递状态。react原则上状态是可以任意传递的。
5）不要使用框架。react自己本身都还在反复完善阶段。你用框架是给自己挖坑。原生的和使用jquery这类框架也没什么区别
如有三层:A->B->C->D，AB之间可以互通,BC，CD都可以，但是AC,AD这类跨层次需要严格禁止。
6）react原则上不建议在原生html的dom中写数据的，如下面一种方式是不建议使用，二是建议包装下div,作为重复可用组件:
<div key="123"
viewState="1234"
viewdState={StateCode.MainBoxItem}
data-view-state={StateCode.MainBoxItem}
onClick={this.handleItemShow}
>
1\main page.click me
</div> 经编译后在谷歌浏览器看到的结果：
<div data-view-state="MainBoxItem" data-reactid=".0.0.0.0.2.$123">1\main page.click me</div>
说明了只有前缀为"data-"的属性才会最终被渲染到真实dom，另外我们怎么获取到这个data-view-state的属性值呢？在handleItemShow方法中使用
console.log(event.nativeEvent.target.getAttribute("data-view-state"));注意：区分状数据双向绑定。官方是严格要求数据是单向传递的，个人也赞同
