- 函数式、不可变、模块化： 经典实现： Redux
- 响应式、依赖追踪， 典型实现： Mobx
- 响应式，区别以流的形式实现，典型实现： Rxjs、xstream
数据流通用准则：副作用隔离，全局与局部状态的合理划分
-
前后端未分离时代，前端数据流、设计模式等布道力度小
-
设备性能提高，需求复杂度提升，组织代码需求日益渐增
-
angular 出现，mvvm 思想打开视野，数据驱动思想深得人心
-
react 兴起，进入 react+mobx 时代，avalon 时代，状态驱动，单向数据流等
-
react 内置的分形数据流管理体系，强调 view 层，对数据层增强的框架不断出现，从 flux，reflux 到 redux，react 真正推动了数据流管理的独立，让人们重新认识到数据流管理的重要性
-
redux 一步到位强制把副作用隔离掉了， 但是没有深入解决带来代码冗余的问题，一部分人转向 mobx， 响应式数据流框架没有强调分离的副作用
-
rxjs 与 mobx 共用一个 observable 名词，偏门数据管理领域正在萌芽
-
vue 接着火起来，慢慢五花八门的现象开始传染（笑）
- 以时间顺序解读三个框架(redux -> mobx -> rxjs)
- 强制使用全局 store 框架， 虽然很多人在尝试局部化
- 定位明确： 清晰，可回溯
- 从分离副作用下手，副作用阻碍代码清晰，action + reducer 的概念出现， 解决副作用问题，参考 koa 中间件的设计思路，redux 中间件将 action 对接到 reducer 的黑盒权限暴露给开发者
- 从 redux 中间件源码引发的函数式热，拉近了开发者对 rxjs 的好感，高阶函数概念字啊中间件源码中体现，为 react hoc 做铺垫
- 社区为 redux 的异步做支持，redux-thunk 到 redux-saga， redux 的异步隔离思想深入人心，基于此封装的高阶框架出现，如 dva
- 第二解决阻碍回溯的对象引用机制，将 immutable 不可变数据流思想搬到前端，所有状态不可被修改，基于此的 redux-dev-tools“时光机”功能使人印象深刻
- 当然像事件机制 dispatch 导致 redux 对 ts 支持比较繁琐， 所以对 redux 的项目，维护需要频繁使用全文搜索，至少两个文件间来回跳跃十分麻烦
TFRP 框架是 FRP 的一个分支，将 FRP 做到了透明化，也可以说是自动化
- mobx 的 observable 可以理解为信号源，信号变化时，函数流会自动执行，并输出，对于前端而言就是将视图刷新，也就是数据驱动视图，变量发生变化之后会自动触发 dispatch，各视图也是自动订阅各数据流，称为依赖追踪或者自动依赖绑定
- TFRP 是最高效的开发方式，自动订阅 + 自动发布 （笔者观点）
- 隐患： 引发副作用对纯函数的污染，对 props 的直接修改会导致 react 对 props 的不可变定义冲突
rxjs 是 FRP 的另一个分支，基于 Event Stream 的，对于 view 的辅助作用来说，相比 mobx 显得不太智能，但是对于数据源的定义，与 TFRP 有着本质的区别，类似 rxjs 的框架可以将任意事件转化为数据源
- 前端一切转换为数据源后，剩下的都可以使用 rxjs 做数据转换， 副作用在数据源这一层完全隔离，直接为纯函数然后输出到 dom driver 渲染，加上 vdom 的处理，为前端数据流管理方案带来全新方案
- redux 和 rxjs 完全隔离副作用，原因是对前端副作用的抽象，redux 通过 action 做副作用，将副作用隔离在 reducer 之外， 使得 reducer 成为纯函数，rxjs 将副作用先转化为数据源，将副作用隔离在管道流处理之外，mobx 缺少副作用抽象这一层，代码书写方式比前两者好，但是副作用和纯函数混杂，与函数式无缘
- 业务场景决定，业务场景组件适合绑定全局数据流，业务无关的通用组件不适合绑定全局数据流，对于复杂的通用组件，为了更好的内部通信，可以绑定支持分形的数据流。
- 副作用封装成事件或者 promise
- 前端开发过程： 副作用隔离 -> 数据流驱动 -> 视图渲染
- 无论 jsx,template 都是可以互相转化的，对于副作用隔离，视图层框架并不关心，需要通过数据管理方式来解决
- react+redux 更像 vue+redux，对于视图渲染和副作用隔离，因素上不受任何组合影响
- 通用 jsx 转换通用 DSL 时，使用通用方式描述结构和方法，转化为对应视图层框架代码时，会转化为对应内置数据流方案的实现。
- 内置数据流的风格在上层抽象之后是可以忽略的，对于 proxy 元编程的方式，将 mutable 的代码转化到 react 时，编程 immutable 模式，转到 vue 时保持 mutable
对框架封装的抽象度越高，框架之间的差异性就越小，框架名的讨论中会渐渐释放，演变成框架 + 数据流哪种组合更加适合思考
-
插件拓展功能是抽象下的对框架语言的功能拓展，其并不关系框架的具体实现形式，对于纯插件机制，数据流定义了数据处理方式，副作用隔离，同时依赖注入也在数据流功能列表之中，前端数据流对于概念是十分宽泛并且提供了很多功能。
-
未来可能会有一种完全无数据管理能力的框架，只做 view 层，内核原生对接 redux 等工具，对于 react 无状态组件(状态不可控的形式)这种纯 view 层组件配合数据流的形式还比较小众
-
更多思考： web components 甚至 HTML components 这种规范配合浏览器实现大量原生组件后，DSL 也就不需要了，HTML 本身就是一套通用的 DSL，框架更不需要，完全浏览器内置
-
未来潜力可能是强大纯函数数据流处理能力的 rxjs
-
纵观前端历史，数据流框架从无到有，但在未来极有可能从有变到无，前端数据流框架消失了，但前端数据流思想永远保留了下来，变得无处不在。