学一个东西先要正三观，本文不涉及具体技术代码，只谈观念。
背景
（本人第一次在项目中使用react+redux，理解可能有偏差）
本周去支援其他组的开发去了，友组一个部门目前只有一个在职前端。。。是一个平台的二期开发，增加了四个功能模块，一期已有3个模块。
我先了解了他们的项目代码，发现虽然引入了react和redux，但是用的蛮不规范的。react组件拆分不够细，跟业务耦合太强，可复用的太低，结果就是页面长的区别不大，却没有公用组件夹。最可怕的是引入了redux，搭建了基础结构，内部完全没有用redux数据流，没有一个页面redux数据流闭环了，都是setState随时改状态，redux和react组合的优势尽失。
我不想就这样扭曲的用react和redux，如果引用了一款框架，却没有使用他的优势，那么引入一个新框架折腾另外一种写法的意义何在。所以我非常想用真正的redux数据流来管理state，但是我之前也没有react和redux项目经验，入门门槛又不低，我害怕自己会导致项目延期.
但是该团队的前端还是按照一期那种不规范的写法在写项目，并且让我也这么做。因为时间很紧，害怕折腾后会延期，而以前的写法虽然不规范，但是快速。但是我默默决定就是加班也要规范的去用。第一天很不顺利，因为刚上手，写写改改，很多情况找不到标准，只有后面踩坑了或者觉得不方便了，才发觉前面的设计不合适，于是又去改之前的。
打住。。。这样写下去就是开发经历了。。。
理解react\redux
react的入门门槛还可以的，无非是组件拆分，就是要摆正观念，将页面的概念转化成组件的，你要写的是一个个组件，然后页面只是合并合并数个组件。组件拆分一定要摆脱业务逻辑，保证组件能被不同的页面通用。并且组件拆分的越细越有利于重用，这个真的是用过才有体会，最开始demo中一个表单的页面将input、select等都拆成了组件，我很不理解，并且没有按照这个标准去拆分，后来发现没法重用了，每个表单都得自己在写一遍input了，才回头去将input给拆了出来。
redux是一个数据管理体系，可以回忆一下之前没有redux时，我们可能将一些被重复用到的数据存在localstorage中，再写增查改删等接口去操作数据，现在是redux为我们封装了这些处理数据的方式，并提出一套操作规范，（当然存数据的是变量而不是localstorage）。redux的核心是状态-state。
数据在store中，展示方式是state，整个项目公用同一个state，保持state的一致性。
状态的切换全在reducer中进行，reducer一般会定义原始的状态，以及根据action.type划分的state状态切换代码。
而执行通知状态切换的函数在action中，action通过返回一个包含type的对象来告知reducer中相应的状态改变代码片段执行。
在此不得不吐槽一下flux，最开始学习时别人建议我先去把flux搞清楚，flux入门很痛苦啊，文档那么简洁，第一次接触的人对于状态在各处跳动处理表示很晕，而且dispather让一切看起来好麻烦，不停发的addEventListenr，感觉flux并没有封装的很彻底，还是让开发者手动调用事件来触发和修改状态，监听状态切换并作出响应，flux更多的是指明了状态切换的开发规范。看了flux后，再看redux，世界都美好了。首先是去除了dispacher这么麻烦的机制，自己封装了接口监听状态转换，让开发者在规范下只需关注状态转换的处理逻辑，而不需要去监听状态转换。其次开发文档真的很详细，写的也比flux通俗易懂多了，开发文档对于初学者真的太重要了。。。
react+redux适用性
react+redux适合中大型项目
redux和react的入门门槛还是不低的，从react来看为了拆分通用组件所要进行的状态传入、用户交互导致状态变更请求的传出都是需要一定的工作量的，特别是对设计合理的要求，一开始组件模式设计的不好，返工就会很多，而这种设计的合理要求一大部分的影响因素是经验，一开始写不能预料到会发生些哪些状况，设计的往往不是很合理。另一方面，为了达到redux数据流闭环，我们在设计和代码上要做很多工作，就是本来可以一步搞定的事，现在要5步的概念。这就决定了react+redux适应中大型项目，项目越大，越体现他的优势，越复杂的项目，前期为了闭环数据流所做的操作所占的比重越小，后期业务代码和状态变更占的比例越大，让前期的操作变得有意义，而且大型项目用了react后状态可控，非常方便维护和二期开发。但是小项目用react+redux就是折腾了，开发效率会降低。
所以看项目适不适合react+redux，我觉得首先拿出设计图，看一下通用性模块多不多，如果总共也没几个页面，还都长的不怎么一样，即使拆成组件也就是能重用个2次，这种还是别折腾react了。如果你的页面多是展示性的静态页面，就没啥用户交互导致的状态变更，或者只是个一群群的表单提交，也别折腾redux了。
解放生产力
每看到一款新的框架，我总会从这个角度去审视他，如果只是玩玩语法糖，花式翻新，却不能解放程序员的生产力，让程序员觉得更麻烦，他就不是好框架。先不讨论react的virtual dom的高效（我也还不了解其实现），就为了按照这个框架的规范去写，就得花费不少的精力。redux更是，为了闭环，一个状态变更要在多个文件里操作。从这个角度看，是增加了麻烦，并不友好。
但是我觉得react和redux都不能仅仅从这个角度来考虑，要从大项目复杂度来看。如果是一个大项目，组件拆分即使很费劲，但是被重用10次，这种按照框架规范去做的拆分组件消耗的精力就很值得.redux也是为了复杂而生，如果一个页面的多个地方都会同时修改一个state状态，如果不用redux这种机制确实会让状态难以管理，而且redux状态一旦闭环被管理后，是累死一次受益万年的事，以后即使业务有变更，也只用改改reducer中状态切换的业务逻辑代码而已，而且可以轻轻松松给状态添加新的内容。
然而，react通过state更新组件界面，不需要程序员自己操作dom，这一点也是解放了生产力。
说到这里不得不提angular，虽说react是view层，但是react+redux已是可以和MVVM并列的开发模式了，angular的双向绑定机制，数据控制视图，真的是无疑解放了程序员的生产力，对程序员非常友好。但是底层对界面刷新的实现据说没有virtual dom高效，复杂时也确实会导致状态混乱。但是小型项目这些都不是问题，依旧推荐angular，作为一个开发者至今怀恋使用angular的高效时光。
框架本身没有优劣，只有适不适合