状态机可概括为4个要素,即现态、条件、动做、次态。这样的概括,主要是出于对状态机的内在因果关系的考虑。“现态”和“条件”是因,“动做”和“次态”是果。详解以下: html
当类对象的某个状态发生变化时,系统将会经过某种途径调用类中的有关处理这个事件的方法或者触发控件事件的对象就会调用该控件全部已注册的事件处理程序等。 react
状态机 |
事件 |
状态机仅仅是状态迁移,并不关注状态变化后你们干什么。perfect,分离了关注点,全部组件能够选择本身想关注的“状态”来自适应变化。 |
关注事件和结果 |
谁都能获得状态 |
|
广播状态,主动选择适应。基本能够不用事件监听机制了。 | 注册-监听,全局监听管理。及耗浏览器性能 |
只管生无论养,若是土壤好,环境好,长的天然好 若是没有强硬的编码规范约束,确定是一锅粥 |
管生管养,成本高,效率低 |
状态控制UI,致使UI的重用率高,界面和数据完整分开 | 一般的js框架界面模板多数用完即销毁,反复服务器存取 |
handleAdd: function() { ........ this.setState({items: oldItems}); ......... this.setState({items: oldItems}); }
1)若是使用react你的第一原则就是使用状态机去解决一切,别用flux这些插件。 jquery
非官方的react-router,react-motion,他们都是使用非状态机的方式来作的,更应该避而远之。 浏览器
2)让状态进入系统设计,变为系统开发过程全程可控的。 服务器
3)UI被状态全程控制。状态不能滥用,只能用于UI控制 react-router
4)状态双向绑定:系统设计严格区分层级,控制状态传递在父子之间,祖辈之间禁止传递状态。react原则上状态是能够任意传递的。 框架
5)不要使用框架。react本身自己都还在反复完善阶段。你用框架是给本身挖坑。原生的和使用jquery这类框架也没什么区别 dom
若有三层:A->B->C->D,AB之间能够互通,BC,CD均可以,可是AC,AD这类跨层次须要严格禁止。 性能
6)react原则上不建议在原生html的dom中写数据的,以下面一种方式是不建议使用,二是建议包装下div,做为重复可用组件: this
<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"));注意:区分状数据双向绑定。官方是严格要求数据是单向传递的,我的也赞同