目录
- 参考文档
- what is iflux ?
- react.js + immutable.js
- React的界面刷新
- Immutable的特点
- flux简介
- iflux特性及demo
参考文档
本人纯前端小白，学习两周基本知识后遇到了一个全新的框架----iflux，写此博客整理和记录学习内容。先将参考文档列出来，方便大（自）家（己）的翻阅。
- iflux 官方介绍
- React 简单介绍 --- React 入门实例教程 --- React：组件的生命周期
- Immutable 详解
- Flux 架构入门教程
- 《ECMAScript 6 入门》(选)
- React Router 使用教程 (选)
what is iflux ?
什么是iflux呢？其实我也不知道，项目上要用而已（逃~~~）。首先，我们先看iflux在npm上的 官方文档 。
what is iflux ?
iflux = immutable.js + react.js
这个式子不懂没关系。继续往下翻文档，找到了这么一句话：
xxxxxxxx
xxxxxxxx
于是，顺其自然的写了iflux去更好的粘合React和immutable。
看到这里，思路就很清晰了：想学iflux，得先去学React和immutable。
react.js + immutable.js
-
React主要原理
React 是一个用于构建用户界面的 js 库，最大的特点就是使用virtual DOM来对页面进行描述。第一次看代码时找了很久都没找到HTML文件在哪，请教后才发现所有的标签都在React组件的render方法中。当React组件的参数（props）和状态（state）发生改变时，就会触发其生命周期，render方法中的虚拟DOM就会对界面进行刷新。页面刷新的效率非常高。
总体流程就是这样了。组件化也是React的特征之一，render方法是React组件的重要生命周期。当用户对界面进行操作时，只要修改props和state属性的值，就能快速的对用户操作进行反馈。但是，React毕竟只是管理界面的工具，对props和state的数据不能进行充分的管理，这时就要用到专门处理数据的Immutable。
-
Immutable的特点
Immutable的出现，解决了JS中的一个痛点：JS中的对象是引用赋值，新的对象简单的引用了原始对象，两个对象指向同一个地址，共享一个内存空间。这样就会使得原始对象中的数据变得不可靠。
程序猿们为了解决这个问题发明了“浅拷贝”与“深拷贝”，其实就是把原对象的数据拷贝一份放在新的对象中。这样做显得很笨重，而且浪费内存空间。
immutable给出的解决方法就是对原数据对象新建一个代理对象。当数据发生变动时，新生成变动数据的备份，与其他不变的数据一起返回给新的变量。虽然两者共享了数据，但是变量是指向两个不同的地址的。这样就能既完成值传递，又能节省内存了。
当然immutable也有其他的优点，但其处理数据对象的高效完美的与React的参数数据契合，使用immutable来管理React的状态(state)就变得理所当然了。
flux简介
介绍完React和Immutable，界面和数据都能进行处理了，那我们完全可以将所有的数据都作为React组件的state属性，当任意数据发生改变即状态(state)发生改变，就立即会刷新界面。flux便是在此设想上进行了完善形成的。
Flux将一个应用分成四个部分：
- View： 视图层
- Action（动作）：视图层发出的消息（比如mouseClick）
- Dispatcher（派发器）：用来接收Actions、执行回调函数
- Store（数据层）：用来存放应用的状态，一旦发生变动，就提醒Views要更新页面
图为flux的运转流程，在我们设想的基础上，完成了数据的"单向流动"，数据变得可控是flux的优点之一。Flux 架构入门教程中介绍了Action和Dispatcher，完全可以跳过不看，我看了也只得出一个结论：太繁杂了！这就给flux提供了改良的空间，也是iflux出现的重要原因。
iflux简介
此时我们再打开 iflux 官方介绍 看一看iflux的流程图。
+-----------------------+
| WebApi |
+-----------------------+
|
\|/
+-----------------------+
| Store（immutable） |<-----+
+-----------------------+ |
| //es5 style |
| StoreMixin | msg(EventEmitter)
\|/ |
+------------------------+ |
| React App |-----|
+------------------------+
| <Layout> |
| <SearchForm/> |
| <Toolbar/> |
| <DataGrid/> |
| </Layout> |
+------------------------+
iflux针对flux的Action和Dispatcher的分层，提出了一个解决方案：一个应用只有一个Store，单根数据源。这样就完全不需要Action和Dispatcher了，使得框架更加的扁平化。文档中作者的思路说的很清楚。
整体思路：
- React只承担view应该承担的事情（1. 资料呈现 2. 用户交互） 不处理任何的业务逻辑，就是根据数据去渲染dom即可，这样view可以做的很轻。
- 应用的全部数据沉淀在一个Store中，当全部数据在顶层时，很多事情都变得简单，因为获取数据变得十分廉价。无论是校验和对数据的转换控制都变得非常简单。
- React只是取数据渲染，其他的比如状态的变化全部通过事件pubsub通知appstore去更新数据。如果状态不会影响其他组件的级联变化可以放在组件内部消化掉。
- 所有的ajax封装在webapi模块中，全部promise化。回调回来通过cursor更新store, cursor更新store， store通知React去rerender。
- 区分View component 和 pure component。
