前言

我之前开发网站的时候一直用的是 Flux， 自从出了 Redux 之后由于种种原因没有跟进了解，最近手头上的事情基本忙的差不多了，抽空阅读了 Redux 的源码，并整理了这篇博文。

先说重点： Redux 与 React 没有关系，就好像 Javascript 和 Java ，雷锋和雷峰塔的关系一样。 Redux 旨在处理数据的流动。

Redux 是 JavaScript 状态容器，提供可预测化的状态管理。 Redux 是由 Flux 演变而来。

那么 Flux 是什么？ Flux 在这里并不是一个框架，而是提供了一套数据流动的方案，类似 MVVM 的概念。

一些概念点

状态容器

Redux 是一个状态容器，这句话挺难理解的，下面的分析也是我的个人见解，不见得正确，欢迎指正。

我们知道是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。

例子：

可以如下自己实现一个状态机：

const fsm = {    currentState: 0,    create(state) { this.currentState = state },    getState() {        return this. currentState    },    transition(action) {        switch(action.type) {            case 'add':                 this.currentState =  this.currentState + action.num                break            case 'sub':                 this.currentState =  this.currentState - action.num                break                default:                break        }     }}fsm.create(5)fsm.transition({'type':'add', 'num':-1})console.log(fsm.getState())   // ==>  4fsm.transition({'type':'sub', 'num':1})console.log(fsm.getState())   // ==>  3

从上面的例子可以看到状态的改变方式为：输入初始状态值5，此时的 currentState 为0，输入{'type':'add', 'num': 1}，经过条件判断是要将状态值 5 加 -1 变成 4，再输入{'type':'sub', 'num': 1}，经过条件判断是要将状态值 4 减 1 变成 3。

对比 Redux 来看的话， 我们的 fsm 就是 Redux 的 createStore 返回的 store，store.getState() 返回的状态对应 fsm.getState()。 那么 reducer + dispatch + action 对应的就是 fsm.transition()。之后会我们分析源码看看 Redux 是怎样把 reducer + dispatch + action 转成 fsm.transition。

整理了一张 Redux 的状态图如下：

对于 Redux 来说，就是把数据当成状态来处理，reducer 就是根据行为（action） 将当前数据（状态）转成新的状态，新的数据状态可以继续被 reducer 处理。

Action

Action 是把数据从应用传到 stateTree（状态树）的输入动作（payloads）。按照约定来说 action 是一个带有 type 属性的 javascript plain object，对应着 Flux 中的 payload。

Action Creator 是一个创建 Action 的函数，额，其实就是函数式编程搞出的概念，把一个表达式包装成一个函数，返回这个 Action。

对照上面我们自己写的状态机代码可以看出 action 的作用告诉 statetree (状态树)发生什么变化，及所需要的数据是什么。

Reducer

Reducer 的是根据 action 来决定数据应该变化成什么样子的函数，即将上面 fsm 中的switch case 表达式包装而成的函数。

Dispatch

dispatch 是更新状态树的方法，在 dispatch 中会调用 reducer， 且通知监听者数据已发生变化。

从上面的分析应该可以推断出 Redux 暴露的 dispatch 会接受一个 action，来决定根据 reducer 去转换状态树，那么也可以推断出 Redux 一定也需要提供一个接受 reducer 函数的API。

Redux 提供的 createStore(reducers, initialState) API 确实如我们推断，会在此时传入 reducer，以及一个可选的初始状态。 createStore 返回的是一个 store， store 和状态树是不同的，此处的store具有dispatch(action) 方法的对象，真正的状态树是 store.getState()（也就是我们真正要使用的数据）。

Redux 的部分源码分析

export default function createStore(reducer, initialState) {  // 在调用 createStore 的时候，必须传入 reducer， 且 reducer 必须为函数  if (typeof reducer !== 'function') {    throw new Error('Expected the reducer to be a function.')  }  var currentReducer = reducer  var currentState = initialState  var listeners = []  var isDispatching = false    // 返回此时的状态  function getState() {    return currentState  }  // 订阅函数，调用 dispatch 的时候会调用 listener  function subscribe(listener) {        // ...  }  // 发布函数， 在 action 触发状态的改变后，通知所有订阅的 listener  function dispatch(action) {    // 传入的 action 必须为 plain object，也就是 action creator 返回的对象    // 自己传入 action 对象也是可以的    // 但是 Redux 推荐的写法是 action creator 的写法    // 至于写成函数的好处不在这里讨论    if (!isPlainObject(action)) {      throw new Error(        'Actions must be plain objects. ' +        'Use custom middleware for async actions.'      )    }    // 强制要求 action 必须带入 type 属性，比 Flux 有更强的约束    if (typeof action.type === 'undefined') {      throw new Error(        'Actions may not have an undefined "type" property. ' +        'Have you misspelled a constant?'      )    }    if (isDispatching) {      throw new Error('Reducers may not dispatch actions.')    }    try {      isDispatching = true      // 这里就是把 action 和当前状态经过 reducer 处理之后返回一个新的状态      // currentReducer 就是 createStore 传进来的 reducer      // 可以切回去看看上面我总结的图      currentState = currentReducer(currentState, action)    } finally {      isDispatching = false    }    // 通知订阅的事件    listeners.slice().forEach(listener => listener())    return action  }  // 状态初始话，此时的 Action 为 { type: ActionTypes.INIT }  dispatch({ type: ActionTypes.INIT })  // createStore 最后返回一个罕有 dispatch 和 getState 的对象  return {    dispatch,    subscribe,    getState,    replaceReducer  }}

总结

Redux 就像是作者自己的介绍，是一个 JavasSript 的状态容器，所有的数据（状态）的变化都是当前状态和 Action 共同的作用结果。 对于使用者（一般都是指 view）来说，不用关心数据是怎样变化，只需要在 view 层面等待 store 通知自己数据发生变化，然后把数据渲染成页面即可。

这里没有提到 Redux 的另一个比较重要也比较难理解的 Middleware。因为如果在这里说的的话，文章不知道要写多长，而长文我现在也驾驭不住，所以干脆就不写了，后面我会再补一篇理解 Middleware 的文章。

开个脑洞

其实我对 Redux 的这种实现状态的方式并不太喜欢，相对来说 看起来更舒服一些，不知道和 Redux 结合有什么效果。可能画面太美，我不敢想?。

原文 @

作者 @