Flux
概览
一种使用单向数据流的形式来组合 React 组件的应用架构
用途
Facebook用其取代MVC，组织代码，安排内部逻辑
核心原理
Flux 包含了 4 个部分，分别是 Dispatcher、 Store、View、Action
Store 存储了视图层所有的数据，当 Store 变化后会引起 View 层的更新
如果在视图层触发一个 Action，就会使当前的页面数据值发生变化
Action 会被 Dispatcher 进行统一的收发处理，传递给 Store 层，Store 层已经注册过相关 Action 的处理逻辑，处理对应的内部状态变化后，触发 View 层更新
优缺点
Flux 的优点是单向数据流，解决了 MVC 中数据流向不清的问题，使开发者可以快速了解应用行为。
从项目结构上简化了视图层设计，明确了分工，数据与业务逻辑也统一存放管理，使在大型架构的项目中更容易管理、维护代码。
Redux
概览
Redux 本身是一个 JavaScript 状态容器，提供可预测化状态的管理
社区通常认为 Redux 是 Flux 的一个简化设计版本，但它吸收了 Elm 的架构思想，更像一个混合产物。
Redux 中整个数据流的方案与 Flux 大同小异
用途
它提供的状态管理，简化了一些高级特性的实现成本，比如撤销、重做、实时编辑、时间旅行、服务端同构等。
核心原理
三大原则
单一数据源
纯函数 Reducer
State 是只读的
副作用
什么是副作用
对主调用函数产生附加影响
AJAX 请求等异步工作，Dom操作，或不是纯函数产生的第三方的交互都被认为是 “副作用”
处理副作用变成了一件至关重要的事情
middleware
第一类是在 Dispatch 的时候会有一个 middleware 中间件层，拦截分发的 Action 并添加额外的复杂行为，还可以添加副作用
社区方案
Redux-thunk
Redux-Promise
Redux-Observable
Redux-Saga
Reducer
允许 Reducer 层中直接处理副作用
社区方案
React Loop
采用了 Elm 中分形的思想
工程化方案
rematch
dva
提供了更详细的模块架构能力，提供了拓展插件以支持更多功能
优缺点
结果可预测；代码结构严格易维护；
模块分离清晰且小函数结构容易编写单元测试
Action 触发的方式，可以在调试器中使用时间回溯，定位问题更简单快捷
单一数据源使服务端同构变得更为容易
社区方案多，生态也更为繁荣
Mobx
概览
Mobx 通过监听数据的属性变化，可以直接在数据上更改触发UI 的渲染
用途
在使用上更接近 Vue，比起 Flux 与 Redux 的手动挡的体验，响应式，省时省力
核心原理
响应式
Mobx 5 为分界点，5 以前采用 Object.defineProperty 的方案
5 及以后使用 Proxy 的方案
优缺点
样板代码少
简单粗暴、用户学习快
响应式自动更新数据让开发者的心智负担更低
个人观点
Flux 的设计更偏向 Facebook 内部的应用场景，Facebook 的方案略显臃肿，拓展能力欠佳，所以在社区中热度不够
Redux 因为纯函数的原因，碰上了社区热点，简洁不简单的 API 设计使社区疯狂贡献发展，短短数年方案层出不穷
但从工程角度而言，不是每一个项目都适用单一数据源。因为很多项目的数据是按页面级别切分的，页面之间相对隔绝，并不需要共享数据源，是否需要 Redux 应该视具体情况而定
Mobx 在开发项目时简单快速，但应用 Mobx 的场景 ，其实完全可以用 Vue 取代。如果纯用 Vue，体积还会更小巧
