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 出现了。