Redux 学习总结（一）

       通常来说，在系列的第一篇里总是要洋洋洒洒的写一堆废话，其实很多都是自我陶醉了。我是个俗人，自然不能免俗。不想看废话的直接看下一章吧。

       其实flux我很早就知道（也就是2015年7，8月左右），当时刚好技术经理强烈推荐我们用 react 来实施一个新项目，再加上身边同事的怂恿，我们就义无反顾的转投 react 了。其实我们当时有比较丰富的 angular 1.2 经验，如果直接用 angular 做，可能效率会更高些。

       真正开始做之前，肯定是需要先做做练习的，当时主要是看官方文档和demo，以及阮老师的博文，文笔很舒服。当时也有翻译的react中文文档，但是版本比较滞后，所以直接就看英文了。做了几个demo之后，感觉是：这东西真特么难用。 lib 和 angular 差不多大，但是就提供个像模板的功能，没有 angular 的双向数据绑定，也没有各种方便的工具，比如 promise， http 。真的就是主页上宣称的：

JUST THE UI

好吧，你真是诚实。

但是没办法啊，项目要用啊，硬着头皮学呗。为了解决数据的问题，开始看 flux。本以为它是一个 data bind 的好办法，后来发现，这完全是另一种思想。flux 提倡的是数据的单向流动。如下图所示。

ps: 来自flux官网

而 angular 是视图和数据直接绑定，操作任何一方，另一方也会联动。做过jquery的人就知道这有多方便了--从此摆脱各种 selector 啊。所以直观上感觉，flux 绕了很多。

再看下面这个图：

ps: 来自flux官网

页面上用户修改了表单，必须通过dispatcher更新store，然后监测store的view得到更新。这个模型也不复杂，但是涵盖了最常见的应用场景：处理用户输入。传统的思想并没有对输入的存储做什么定义和规范，即使是 angular也没有（虽然你可以使用service存储），完全属于爱怎么存怎么存。也没有对数据的推送来源做限定，有的来自后端，有的来自用户。而flux做了。所有view的数据必须来自 store， 而对store 的更新只能由dispatcher发起。这形成了比较简单的数据通路，而且，它是单向的。

单向的有什么好处吗？好处就是，场景简单了，需要思考的问题也就变得纯粹了。如果有下面这个案例：

写一篇日记后，日记列表更新（添加日记），很简单。如果是以前的做法，无非是添加一个日记到日记列表，完事。如果页面上有其他的视图也需要更新（比如显示日记数目的UI），那就也去更新这个视图依赖的数据。这是angular的做法，如果是jquery，还得去获取dom，再更新dom。

自己画的图，略简陋。

如果是 flux的做法呢？

第一步： 建立日记列表对应的store，action，dispatcher。所以和store相关的view都建立好联系。

第二步： 添加日记后，通过dispatcher更新日记的store。

结束。

这两步完全是分离的，更新store的时候，完全不用考虑其他的视图。其他视图也完全不关心谁更新了store。如果有更多的view想要展示日记相关的东西，只需要去订阅store的更新就好了。

 

认识到这一点之后，我对react有信心了。一般来说，敢于颠覆传统思维的，要么是标新立异，要么就会引发技术革命。

后来的发展也证实了flux不是凡品，一些其他的框架也逐渐向flux靠拢，这包括 vuejs，还有涅槃重生的 angular 2。

再到后来，redux 出现了。