自己实现一个Redux

Redux是一个可预测的状态容器，提供可预测的状态管理。

什么是状态？状态其实也就是数据，管理状态也就是对数据的管理。那么什么是可预测的状态管理呢？能够监听数据的变化，获取变化的来源，在发生变化时可以触发某些动作，即为状态管理（个人理解）。

如上所示，就是一个最简单的状态管理，实现了数据基本的管理，但是，并未实现监听数据的变化。因此，此处采用订阅者模式，实现数据变化的监听：

代码很简单，订阅事件&触发事件，实现了监听data状态的变化。以上其实就是Redux的核心内容。项目放在github上，欢迎star

问题1

通过changeState方法可以随意更改state，不受控制。
Redux是“可预测的状态管理器”，因此能够引起状态变化的，必须是在我们可预测的范围内。也就是说，如果引起状态的变化不在我们定义好的变化之内，则拒绝处理该变化，Redux是如何做到这一点的呢？talk is cheap, show me the code:

原来如此！通过敢敢单单的switch case语句即可实现。（至于这个方法为什么叫reducer，后面再解释）
原本的createStore里的changeState方法也需要配合改动(方法名字改成dispatch，意为“派发”动作，更符合其功能)：

触发动作时，则需要用以下这种形式：

动作发起者：洞幺洞幺，我是type为“CHANGE_NAME”的动作

处理动作者：收到，已处理完毕，并返回给你变化后的状态，over

动作发起者：洞尧洞尧，我是type为“cxk”的动作

处理动作者：非法类型的动作，拒绝处理，返回初始状态，over

问题2

当store里的数据比较多时，用同一个reducer处理，必然会导致函数很臃肿：

最简单的解决方法，就是按照功能模块对reducer进行拆分：

那么接下来要做的就是，如何把多个reducer组合起来，并最终返回变化后的state。首先将多个reducer按照模块的形式组合在一起：

然后编写一个combineReducer方法，当每次dispatch了action，会依次触发所有reducer，并最终返回变化后的state：

这里可以解释为什么叫reducer了，从上述代码中可以看出，每个reducer其实是（prev， action） => newState这样的一个结构，类似于Array.prototype.reduce的结构，因此称之为reducer。

问题3

想必也能猜到问题3是什么了，上文将reducer按照模块拆分了，但是state本身还没有拆分，如果state过于庞杂，也是不好滴。话不多说，拆：

同时，在createStore里新增一句代码，用于初始化整个state：

因为type不为任何值，因此所有的reducer都会按照default返回初始值，这样就完成了state的初始化,并且在createStore时，也不用再传入initalState了。

middleware（中间件）

国际惯例，什么是middleware？

它提供的是位于action被发起之后，到达reducer之前的扩展点。你可以利用Redux middleware来进行日志记录、创建崩溃报告、调用异步接口或者路由等等。

（网上找的）

说白了，middleware就是对dispatch的扩展，可以利用它实现定制化功能。
举个栗子，我们要实现dispatch时，添加一个日志记录的功能，记录一下action触发前后的状态以及是哪个action触发的，那么可以重写dispatch方法：

假如说我们这时候又想添加一个创建崩溃报告的功能，那么可以这样重写dispatch方法：

那么问题来了，如果我们想要同时具有这两个功能呢？机智的我一下子就想到了，把这俩写到一起不就ok了？

真的是简单到爆了。等等...好像有哪里不对？如果以后想加入更多的功能呢？难道也要把他们都塞进这个新的dispatch方法里面？很明显，不行，那样只会导致dispatch方法越来越臃肿，难以维护。根据我们多年的经验，必然是又要进行拆分了。

从上面的loggerMiddleware和exceptionMiddleware的合作上，可以看出，多个中间件之间的调用顺序应该是类似于

A = (action) => { B(action) }

这样的一种链式结构。为了使middleware更为通用，应该将B作为参数传递进去，因此，可以写出这种结构：

A = (B) => (action) => { B(action) }

这时候会发现，在任意一个中间件里，都有可能用到store，因此，将store作为顶级参数传递进去：

A = (store) => (B) => (action) => { B(action) }

代码如下：

抽离公共方法

每次使用中间件时，都要写一些重复的代码。因此Redux内部有一个方法，可以实现这种链式调用：

（简单的示例，实际的方法比这个更为复杂）

方法实现的比较巧妙，每次将经过上一个中间件处理过的dispatch作为参数传递给下一个中间件，这样就形成了链式调用：

store.dispatch = applyMiddleware(store, loggerMiddleware, exceptionMiddleware)

异步action

在实际项目中，异步是不可避免的。之前的代码中，当我们每次dispatch一个action时，action只能是一个plain object(普通对象，这里指的是直接继承于Object的对象)，否则reducer无法成功解析(按照官方文档的意思，action必须是“可序列化的”,这部分暂时不是很理解)。

和 state 一样，可序列化的 action 使得若干 Redux 的经典特性变得可能，比如时间旅行调试器、录制和重放 action。若使用 Symbol 等去定义 type 值，或者用 instanceof 对 action 做自检查都会破坏这些特性。字符串是可序列化的、自解释型，所以是更好的选择。

因为性能原因，我们无法强制序列化 action，所以 Redux 只会校验 action 是否是普通对象，以及 type 是否定义。

然鹅在实际开发中，存在大量的异步场景，例如最常见的请求调用。我们可以利用中间件，让dispatch可以直接接收一个Function类型的action。Redux就提供了这样一个中间件redux-thunk：

代码其实也很简单，判断了一下action是否是函数，是的话则执行这个action。用这个中间件去增强dispatch的功能，就可以按照下面这种形式写异步的action了：

调用时：

dispatch(getCardInfoAction())

tips：无论嵌套执行了多少个middleware，最终被dispatch的那个action，仍然必须是一个plain object，将处理流程变回同步方式。

当 middleware 链中的最后一个 middleware 开始 dispatch action 时，这个 action 必须是一个普通对象。这是 同步式的 Redux 数据流 开始的地方（译注：这里应该是指，你可以使用任意多异步的 middleware 去做你想做的事情，但是需要使用普通对象作为最后一个被 dispatch 的 action ，来将处理流程带回同步方式）。

小结

到这里，redux的大部分功能其实已经基本实现了，剩余的还有一些细节部分，例如将f1 => f2 => f3(action)这种链式调用变为f1(f2(f3(action)))这种调用形式的compose方法（用在applyMiddleware方法内部）；createStore方法添加有中间件/无中间件的处理；store.subscribe订阅后的退订以及各种判断的处理等。

Redux的源码短小精悍，使用纯JavaScript实现，不依赖任何第三方库，因此也适用于各种框架。其完整的流程图：

参考：

从零实现一个Redux

Redux官方文档