最近公司需要重构一个后台管理系统，原因就是用到的技术比较过时，例如：react的版本是0.14.7，antd的版本还是0.12.4。
之前尝试重构了一个页面，这个页面的数据非常复杂，老的代码解决的方案往往是context，对于这种方式，官网给出了一个Notice：
我理解的这段话的意思应该是首先不要滥用，这样会产生很多magic number从而让代码阅读都不知所云，使用context的场景往往应该是有一个父组件管理很多数据来让它的子组件们共享这些数据。
这种方式很容易让人联想到了redux，为了管理这些复杂的数据，我在下一个页面中使用了React+Redux-Saga+Seamless-Immutable+Reduxsauce这样的一种架构方式。
为什么要这么做
Redux
You Might Not Need Redux，当你不知道你是否需要Redux的时候，那你就是不需要它。我们在使用redux实现一个功能的时候，往往需要修改三个文件：1、View层dispatch一个action；2、Controller层收到这个action并执行一些逻辑，dispatch一个action给Modal层；3、Modal层处理数据。
而在我新开发的这个页面中，涉及到了一些非常复杂的情况：多种用户（供应商、子商户）、多种模式（正常报名、修改报名），以及要修改一些粒度非常小的数据（为一个商户关联商品并将商品信息展示出来，修改关联的商品的图片等）。拿到这种需求的时候，我第一时间就想到了必须使用这个工具，否则数据的庞大和复杂会让我陷入恶梦之中。
saga
起初我只是想学习调研一种新的使用redux的方式。可是随着学习的深入和使用得越来越多，我对它越发着迷。saga其实是redux的一个中间件，它提供了非常优秀的异步处理方式，就是使用Generator函数来让Promise调用扁平化，像编写同步代码一样编写异步代码。其次，saga还提供了很多优秀的方法来控制流程，如：fork执行一个非阻塞操作；Race 同步执行多个 effect，然后一旦有一个完成，取消其他 effect；takeLatest 意味着我们将执行所有操作，然后返回最后一个(the latest one)调用的结果。如果我们触发了多个时间，它只关注最后一个(the latest one)返回的结果等。不仅如此，我从中还摸索到的一种“锁”的概念（后面会讲到，这种方法对于 redux化的Stateless Component非常有用，可以用来模拟生命周期函数而无需使用高阶函数）。
Seamless-Immutable
Shared mutable state is the root of all evil（共享的可变状态是万恶之源）
-- Pete Hunt
我们都知道react的state是不可变的，修改state的时候(特别是引用类型)不能直接使用this.state.foo.bar = newValue，因为React的diff算法是shallow eqaul的。我们可以通过cloneDeep来深拷贝原state，再修改这个拷贝出来的新值，再setState。
或者使用Seamless-Immutable来解决这个问题。一个immutable值一旦生成就不可改变，只要对这个值进行有副作用的操作都会生成一个新的值。同时Immutable值会采用结构共享，即如果对象树中一个节点发生变化，只修改这个节点和受它影响的父节点，其它节点则进行共享。这样也避免了cloneDeep带来的性能消耗。如果每次都生成一个新的对象，那么就可以把这些对象存储下来，实现时间旅行就非常简单了。
Reduxsauce
这个工具主要是用来简化reducer的写法，避免判断action.type而产生的无数switch...case...，以及可以非常轻松地生产出不重复的action.type等功能。
if you trade something off, make sure you get something in return.（如果你付出了一些东西，一定要确保你能获得一些东西），以上介绍了技术选型的原因，一定不要为了使用技术而使用技术，带着明确的目标，下面介绍一下这套系统的搭建方法。
