目录

• 参考文档
• 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。

---