Redux和Reflux研究

写在前面

在开始全新的React项目前，先好好研究一下React两个典型的“轮子”，Reflux和Redux。两者没有明确的优劣之分，只是对初学者来说Reflux容易理解，而Redux的单一state在项目开发中非常好用，所以你可能发现Github上Redux的星星比Reflux略多些吧。但是见智者见智，两者其实都是社区同仁智慧的结晶。

Redux

先谈谈对Redux的理解。

独特性

第一
一个数据层的framework，类似于Baobab。比其好的一点，引入middleware体系，有几个现成的插件redux-thunk, redux-promise，不用但心异步请求的事。虽然说灵活、独立很重要，但全局设计也是 让人放心去用，而不用担心功能缺失和其它风险。

第二
应用了FP中数据不可变性（immutable），这让追踪数据改变过程有很大提升。也就是其宣扬的时间旅行。这对复杂问题定位是有好处的。

第三
树形化数据存储，reducer的返回即是其新建，更新、删除过程，树形结构不需要预先定义。同时，reducer也是纯函数，与reactor的render是纯函数呼应。

第四
强约束（约定），增加了内聚合性。Flux中的action, dispatcher, store比较散，在分层架构是需要的，但内聚性不佳，出现java的仪式感。而Redux是数据层很清晰，一个store，更新则dispatch到action，前半段自己想怎么搞就怎么搞(middleware），后半段reducer。reducer约束是不要改oldState，返回newStatew，做到immutable。

第五
不一样的action：Redux中的action会切得很细，一个传统的Action被切成了三个Action：Loading, GetSuccess, GetError。所以，从这个方面来看Action服务于UI，而非业务逻辑单元。

第六
Redux大量应用FP，经常遇到FP中的curry, trund, promise这些概念，学习成本较高。在middleware层实现，对没有FP经验的人讲不友好。

置Redux于上下文中

Redux是一个比较薄的数据层。同时，把View同步刷新也做了（redux-react）。

在传统MVC中，还是有一个controller来做业务逻辑。但Redux硬生生的把一个controller切成二部分:action, reducer。

理论上，Redux还可以把React组件中的state的存储也拿过来，比如用户搜索的名称。这样，就可以把过滤算法放到selector中去。但这样好处并不是很大。

对比其他方案

与Baobab对比，两者都是数据管理框架，Baobab提供cursor来方便你对很深层的数据结构进行update。而Redux是通过selector函数来做，这种方法会比较晦涩。但比Baobab好的地方，做数据fetch可以通过Redux的middleware来完成。

与Rails的controller, ActionRecord相比，Redux更多是一种约定，不提供路由级的controller，不提供数据访问cursor。

Redux接口不超过10个，代码也非常少，但是与之前的MVC框架完全不同。可能最大的问题是没有和react-route打通，在工程化时让人迷茫。

挑战

Redux应用最大的挑战更多来自设计层面，如何设计action，设计state树形结构。我们只能通过非常少的线索（FP架构思想）去做，这对没有FP经验的团队是一个大挑战。

通过selector函数从stat树里取数据比较晦涩，并且这个selector里的代码认为是业务逻辑，单独放在selector，业务上不内聚。

middleware层设计：action是一个意图(intent），发送给middleware，让其来实现此意图。但这样做，action比有两义性，一会儿是对象，一会儿是函数。同时FP编程侵入性太大。

没有与Route结合起来设计，让人很不放心，也不知道如何在不同路由下来做数据与组件的connect。

OO与FP编程范式对决

react + redux是一种典型的FP编程范式实现，而其它框架大多是OO范式。是否选用react+redux开发，需要看是否对FP有掌握或者有一定的架构能力。但单独用react则没有这种要求，当个view来用。

FP优缺点

FP的好处是没有OO的复杂仪式感，是沿着数据结构+算法的思路进行抽象和结构化。如果顶层设计做好，代码复用度极高，代码量少。比如要生成一颗树我用迭归算法直接生成，而OO的人往往会用一个Composite模式去定义一个晦涩的类接口。

FP的缺点也是也是面向过程编程的缺点，算法与数据全局化、并且互相耦合，这往往会导致一个强耦合的系统。如果没有做好顶层设计，是难以演进的。

通过约定和全局的理解，可以减少FP的一些缺点。“约定大于配置”也是框架的主要发展方向。

OO优缺点

OO的好处是分而治之，增量演进。同时有自闭性，语义比较清晰。

缺点是在表达一些算法时，反而是很困难的。如command模式实现历史回滚就挺麻烦。也这是四人帮的设计模式大多比较难以理解的原因。另外，OO一直有一个对算法复用的问题，ruby语言解决比较好，用mixin很自然。而像C++就用多继承和泛型，个人感觉并不是最好的。

建议

有FP经验的或者架构能力比较强，团队人员比较少、能力强，较强适合用react+redux。不然用react+angluar, 或直接用vue。而且过度的OO，搞太多java仪式感确实没有必要。通过架构设计，FP在生产力有着一定的优势。同时对付复杂系统，能更好调测、定位问题。在新时代下，值得尝试。

Reflux 和 Redux

已经认识了Redux，而相比较Redux而言，Reflux没有reducer的概念，取而代之，和action做基友的是store。Reflux的功能流程如下：

组件就是用户界面，actions就是组件的动作，store用于执行actions的命令，并返回一个state对象给组件。组件通过state来更新界面。

而Redux的流程如下：

state就是数据，组件就是数据的呈现形式，action是动作，action是通过reducer来更新state的。

Reflux没有把状态的一部分值绑定在组件的props上，而是将状态绑定在组件的state上，请看 react dev tool的截图:

Reflux可以直接调用action的方法，而Redux必须将方法绑定在组件的props上，或者使用props的dispatch方法来执行actions的方法。

---

@参考 百草赵斌 《深入理解React、Redux》
@参考 天可 《react＋relux入门教程》