这篇文章我觉得是最重要关于Redux的运转模式的思考文章.我在Redux这里已经花了太多的功夫.每每遇到有网友在编写React/React-Native的app的时候,遇到Redux的这个问题总是想要跳过去，我总要写一些反驳的话,因为我已经认识到了Redux对于React或者基于状态的编程方法的重要性.请相信我,你看到的那一句话：“你不知道该不该用Redux的时候,你就不要用Redux”。我没看到原文,但是我看到了另外一句话:"如果你对数据流程不清楚,你就不知道自己在做什么"。 我估计这个话的翻译很很成问题，结果作为很多React学习者自我安慰的一个圣旨了. 想想看,你对Redux的工作方法都没有掌握,你怎么知道Redux是好还是还是坏,你怎么来使用Redux。所以这句话是一个伪命题. React-Redux基本已经成为了React程序的官方标配了,重要性不容置疑,看在github几千星星的成绩上你也要学习啊!当你基本理解了Redux的工作原理以后,当你对redux佩服的五体投地的时候,你再做决定不迟.
Redux的原理总结为一句话就是：改变了原有组件自己管理状态的方法.这个话你现在不理解也可以,等你理解了Redux的时候,你自然会有这个念头.
记住一点：程序编制就是要解决数据流问题
看看生活中的数据流问题
好了,我们再讲正题之前,先讲两个你熟悉的例子来辅助理解.
奥林匹克公园的疯狂人流中的数据流
今天是到北京的第二个周末,慕名前往奥林匹克森林公园去跑步.
等到了森林公园以后,我惊呆了,作为一个自认为是资深跑友的人,都被场面惊呆了.人山人海,锣鼓喧天,入口处有好几十个队伍在准备进行比赛.这么多队伍,加起来有几千人,那么打眼一看人很多，很复杂.这一点其实就和我们的app编程中逻辑，流程复杂以后一样,如果不从每个小处去思考流程,很可能就不知道整体是怎么正常运转的,每个细节各自处理好了,就体现出整体的运转正常.
那么我们现在从奥体的巨大人流中聚焦到小的流程中来看看小流程是怎么运转的。简单就是看看每个小组都做了哪些跑步工作
中移动研究院的队伍.
显然是已经过了为钱发愁的阶段，所以成员的状态都好,着装整齐, 具体的流程就是: 绕南园,北园两个来回,20公里的距离,也不需要打卡,也没有人监督.中石油北京直属机关.
不亏是老牌国企,500强企业,领导挺着大肚子,绕道走了1.5公里，做做样子就行了,其他的员工就哭了,每跑2km还要跳绳100下,在接着跑步。中航工业公司
每个人拄着双拐,疾步飞走.
4 . 弱视群体
眼睛视力不好的,有志愿者和视障者绑在一起, 双双飞奔,有疾走的
- 野路子的,像我一样的一个人,全身关注,埋着头,思考着到底怎么说服其他人用Redux. 不是超过一个大长腿的妹子,还要偷偷瞄上几眼.
哈哈,几千人一起在森林公园跑步,看起来杂乱无章,其实落实到细节的地方,都是属于整体中的一个组成部分,每一部分都有自己完成工作的不同的地方,每个组成部分之间是不会相互干扰的.
在森林公园中似乎有一个单一的部分,但是其实里面有许多独立的容器来各自组织自己的工作,独立容器的工作汇聚在一起就完成了整个工作.
马路上的数据流
车水马龙,人潮涌动. 但是其实各自在做自己的事,各自都有自己做事的方法,和判断标准.机动车,非机动车,人流各自按照自己的规则运行以后才体现出整个交通的正常工作.
好了看来这似乎是一个解决复杂问题的好办法,就是把大的结构拆解成各自独立的部分，让他们自己来决定自己的行为方式.
用马路做例子,如果机动车按照行人的规则和逻辑来办事就会出现很大的问题.所以机动车和行人不要相互干涉,要用栏杆和道沿隔开来.
回到Redux
Redux的思想其实和上面的跑步这个过程,马路上的过程其实是完全一样, 组件要根据自己的逻辑流程来和其他的组件隔离起来. 这里头其实用了container这个方法, 来隔离独立的逻辑处理过程.
根据上面生活中的例子,遇到复杂的问题,不要从整体考虑,从独立的逻辑上考虑,把复杂过程分解为相互独立的处理部分,各自行使自己的功能.
在app中.例如登录和注册操作其实是没有任何关系, 注册过程把表单数据做验证以后存入数据库
登录过程中用户输入数据,期待通过数据库的验证.
这两者都和数据库有关,但是其实一个是写操作,一个是读操作,两者的逻辑是不同的.
在设计中就要考虑到尽管可能app中有很多的逻辑，但是其实有很多的逻辑是非常独立的部分,所以我们考虑可以每个独立的逻辑独立处理.
在Redux中,container组件负责 把独立的逻辑包装起来和其他的逻辑隔绝开. 每个独立的逻辑会返回 state树的一个节点,combineReducer函数. 每个逻辑负责自己的处理,然后由combinRedcer合成一个大的应用. 每个小部分的返回对象正常了,app的工作就正常了.
隔离在container里的组件和其他组价之间是不会有交流逻辑的,因为在每个container里的组件代表的是独有的逻辑, 这些组件之间相互操作,难免就不在一个频道上,需要一个中间人来协调之间的工作. 这有一个中间人存在,就不会出现版本的冲突问题了.
至于有网友说,redux里面分了那么多的文件件,看不下去。 这其实是组件化的问题,分了那么多的文件件其实就是为了你编程的简单化,容易排错,高手把这些东西写到一起一点问题都没有,但是会增加新手的学习负担. 集成度高可配置性和可维护性就大大降低了.
比如说 同样是照亮的, 手电的集成度很高,很小巧, 屋子里的电灯集成度很低,分了开关,灯头，电路等.但是在可配置性上电灯的配置性就高了很多, 手电的可配置性很低,维护性上,电灯的维护性很高,很容易发现问题,
文件夹的多寡其实只是形式而已,正真要解决的还是一个数据流的流动问题.
怎么处理复杂的数据流，这是Redux中的重点,React引入Redux以后数据流的控制权就交到了Redux中了, 组件要提交数据,要考虑怎么操作Redux中数据源(state)的问题,组件要请求数据要考虑怎么从Redux中来获取了.
记住Redux中数据源只有一个,所有与数据有关的操作最终要看到Redux 中 state的变化. 安装了redux-logger以后,这个中间件会使用Store.getState()方法获取每一步交互操作的state的变化情况.
Redux的学习过程一路走来,坎坷无比，最终在脑子里重构了整个的数据分割和数据操作流程.你的大脑需要一定的时间来形成这个回路,所以不要急,要耐心一点.
Redux的学习其实对于javascript的基础要求也挺高的, ES6的一些新特性,本来的一些特性. 设计模式的东西.
生态系统还是挺大的.
Javascript的水深着呢！基础知识要过关啊！这里头绕不开闭包！this! 对象原型链!
程序设计的思想我感觉都是来源实际生活中的,最好能从生活中找到一些类似的流程来辅助理解.
今天就写这么多.顺便在安利一下奥体森林公园, 去跑步多好啊,时不时看到大长腿的妹子,弄得大叔我也春心荡漾了.呼吸北京最好的氧气。
大门口的特步门店还提供免费的衣服寄存和淋浴. 我理想的跑步就是这样的了. 可以一边跑步一点思考Redux的问题.
