Redux源码分析

摘要：在得到新的状态后，依次调用所有的监听器，通知状态的变更。执行完后，获得数组，它保存的对象是第二个箭头函数返回的匿名函数。部分源码利用这个属性，所有子组件均可以拿到这个属性。

Redux使用中的几个点：

Redux三大设计原则

Create Store

Redux middleware

combineReducer

Provider与Connect

Redux流程梳理

Redux设计特点

在传统的 MVC 架构中，我们可以根据需要创建无数个 Model，而 Model 之间可以互相监听、触发事件甚至循环或嵌套触发事件，这些在 Redux 中都是不允许的。因为在 Redux 的思想里，一个应用永远只有唯一的数据源。
实际上，使用单一数据源的好处在于整个应用状态都保存在一个对象中，这样我们随时可以提取出整个应用的状态进行持久化（比如实现一个针对整个应用的即时保存功能）。此外，这样的设计也为服务端渲染提供了可能。

在 Redux 中，我们并不会自己用代码来定义一个 store。取而代之的是，我们定义一个 reducer，它的功能是根据当前触发的 action 对当前应用的状态（state）进行迭代，这里我们并没有直接修改应用的状态，而是返回了一份全新的状态。

Redux 提供的 createStore 方法会根据 reducer 生成 store。最后，我们可以利用 store. dispatch
方法来达到修改状态的目的。

在 Redux 里，我们通过定义 reducer 来确定状态的修改，而每一个 reducer 都是纯函数，这意味着它没有副作用，即接受一定的输入，必定会得到一定的输出。

这样设计的好处不仅在于 reducer 里对状态的修改变得简单、纯粹、可测试，更有意思的是，Redux 利用每次新返回的状态生成酷炫的时间旅行（time travel）调试方式，让跟踪每一次因为触发 action 而改变状态的结果成为了可能。

我们从store的诞生开始说起。create store函数API文档如下：

createStore(reducer, [initialState], enhancer)

可以看出，它接受三个参数：reducer、initialState 和 enhancer 。Store enhancer 是一个组合 store creator 的高阶函数，返回一个新的强化过的 store creator。这与 middleware 相似，它也允许你通过复合函数改变 store 接口。

再来看看他的返回值：

{
    dispatch: f (action),
    getState: f (),
    replaceReducer: f (nextReducer),
    subscribe: f (listener),
    Symbol(observable): f ()    
}

store的返回值就是一个普通对象，里面有几个常用的方法：

dispatch：就是我们最常用的dispatch方法，派发action。

getState：通过该方法，我们可以拿到当前状态树state。

replaceReducer：这个方法主要用于 reducer 的热替换，下面介绍该方法。

subscribe：添加一个变化监听器。每当 dispatch（action）的时候就会执行，state 树中的一部分可能已经变化。

observable：观察者模式，用于处理订阅关系。

这里挑几个方法介绍：

在完成基本的参数校验之后，在 createStore 中声明如下变量及 getState 方法：

var currentReducer = reducer
var currentState = initialState
var listeners = [] // 当前监听 store 变化的监听器
var isDispatching = false // 某个 action 是否处于分发的处理过程中
/**
* Reads the state tree managed by the store.
 *
* @returns {any} The current state tree of your application.
 */
function getState() {
 return currentState
} 

getState方法就是简单返回当前state，如果state没有被reducer处理过，他就是initialState。

在 getState 之后，定义了 store 的另一个方法 subscribe：

function subscribe(listener) {
 listeners.push(listener)
 var isSubscribed = true
 return function unsubscribe() {
 if (!isSubscribed) {
 return
 }
 isSubscribed = false
 var index = listeners.indexOf(listener)
 listeners.splice(index, 1)
 }
} 

Store 允许使用store.subscribe方法设置监听函数，一旦 State 发生变化，就自动执行这个函数。

显然，只要把 View 的更新函数（对于 React 项目，就是组件的render方法或setState方法）放入listen，就会实现 View 的自动渲染。你可能会感到奇怪，好像我们在 Redux 应用中并没有使用 store.subscribe 方法？事实上，

React Redux 中的 connect 方法隐式地帮我们完成了这个工作。

store.subscribe方法返回一个函数，调用这个函数就可以解除监听。

dispatch是redux的核心方法：

function dispatch(action) {
    if (!isPlainObject(action)) {
        throw new Error(
            "Actions must be plain objects. " +
            "Use custom middleware for async actions."
        )
    }
    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
        currentState = currentReducer(currentState, action)
    } finally {
        isDispatching = false
    }
    listeners.slice().forEach(listener => listener())
    return action
} 

判断当前是否处于某个 action 的分发过程中，这个检查主要是为了避免在 reducer 中分发 action 的情况，因为这样做可能导致分发死循环，同时也增加了数据流动的复杂度。

确认当前不属于分发过程中后，先设定标志位，然后将当前的状态和 action 传给当前的reducer，用于生成最新的 state。这看起来一点都不复杂，这也是我们反复强调的 reducer 工作过程——纯函数、接受状态和 action 作为参数，返回一个新的状态。

在得到新的状态后，依次调用所有的监听器，通知状态的变更。需要注意的是，我们在通知监听器变更发生时，并没有将最新的状态作为参数传递给这些监听器。这是因为在监听器中，我们可以直接调用 store.getState() 方法拿到最新的状态。

最终，处理之后的 action 会被 dispatch 方法返回。

function replaceReducer(nextReducer) {
    if (typeof nextReducer !== "function") {
      throw new Error("Expected the nextReducer to be a function.");
    }

    currentReducer = nextReducer;
    dispatch({ type: ActionTypes.INIT });
  }

这是为了拿到所有 reducer 中的初始状态（你是否还记得在定义 reducer 时，第一个参数为previousState，如果该参数为空，我们提供默认的 initialState）。只有所有的初始状态都成功获取后，Redux 应用才能有条不紊地开始运作。

It provides a third-party extension point between dispatching an action, and the moment it reaches
the reducer

它提供了一个分类处理 action 的机会。在middleware 中，你可以检阅每一个流过的 action，挑选出特定类型的action 进行相应操作，给你一次改变 action 的机会。

常规的同步数据流模式的流程图如下：

不同业务需求下，比如执行action之前和之后都要打log；action触发一个异步的请求，请求回来之后渲染view等。需要为这一类的action添加公共的方法或者处理，使用redux middleware流程图如下：

每一个 middleware 处理一个相对独立的业务需求，通过串联不同的 middleware 实现变化多样的功能。比如上面的业务，我们把处理log的代码封装成一个middleware，处理异步的也是一个middleware，两者串联，却又相互独立。

使用middleware之后，action触发的dispatch并不是原来的dispatch，而是经过封装的new dispatch，在这个new dispatch中，按照顺序依次执行每个middleware，最后调用原生的dispatch。

我们来看下logger middleware如何实现的：

export default store => next => action => {
    console.log("dispatch:", action); 
    next(action);
    console.log("finish:", action);
 } 

这里代码十分简洁，就是在next调用下一个middleware之前和之后，分别打印两次。

Redux 提供了 applyMiddleware 方法来加载 middleware，该方法的源码如下：

import compose from "./compose";

export default function applyMiddleware(...middlewares) {
    return function (next) {
        return function (reducer, initialState) {
            let store = next(reducer, initialState);
            let dispatch = store.dispatch;
            let chain = [];
            var middlewareAPI = {
                getState: store.getState,
                dispatch: (action) => dispatch(action),
            };
            chain = middlewares.map(middleware => middleware(middlewareAPI));
            dispatch = compose(...chain)(store.dispatch);

            return {
                ...store,
                dispatch,
            };
        }
    }
}
 

其中compose源码如下：

function compose(...funcs) {
    return arg => funcs.reduceRight((composed, f) => f(composed), arg);
} 

使用的时候，如下：

const newStore = applyMiddleware([mid1, mid2, mid3, ...])(createStore)(reducer, initialState); 

ok，相关源码已就位，我们来详细解析一波。

函数式编程思想设计 ：middleware 的设计有点特殊，是一个层层包裹的匿名函数，这其实是函数式编程中的
currying，它是一种使用匿名单参数函数来实现多参数函数的方法。applyMiddleware 会对 logger 这个middleware 进行层层调用，动态地将 store 和 next 参数赋值。currying 的 middleware 结构的好处主要有以下两点。

易串联：currying 函数具有延迟执行的特性，通过不断 currying 形成的 middleware 可以累积参数，再配合组合（compose）的方式，很容易形成 pipeline 来处理数据流。

 共享 store: 在 applyMiddleware 执行的过程中，store 还是旧的，但是因为闭包的存在，applyMiddleware 完成后，所有的 middleware 内部拿到的 store 是最新且相同的。

给 middleware 分发 store：newStore创建完成之后，applyMiddleware 方法陆续获得了3个参数，第一个是 middlewares 数组[mid1, mid2, mid3, ...]，第二个是 Redux 原生的 createStore ，最后一个是 reducer。然后，我们可以看到 applyMiddleware 利用 createStore 和 reducer 创建了一个 store。而 store 的 getState方法和 dispatch 方法又分别被直接和间接地赋值给 middlewareAPI 变量 store：

const middlewareAPI = {
 getState: store.getState,
 dispatch: (action) => dispatch(action),
};
chain = middlewares.map(middleware => middleware(middlewareAPI)); 

然后，让每个 middleware 带着 middlewareAPI 这个参数分别执行一遍。执行完后，获得 chain数组 [f1, f2, ... , fx, ..., fn]，它保存的对象是第二个箭头函数返回的匿名函数。因为是闭包，每个匿名函数都可以访问相同的 store，即 middlewareAPI。

middlewareAPI 中的 dispatch 为什么要用匿名函数包裹呢？
我们用 applyMiddleware 是为了改造 dispatch，所以 applyMiddleware 执行完后，dispatch 是变化了的，而 middlewareAPI 是 applyMiddleware 执行中分发到各个 middleware 的，所以必须用匿名函数包裹 dispatch，这样只要 dispatch 更新了，middlewareAPI 中的 dispatch 应用也会发生变化。

组合串联 middleware：这一层只有一行代码，却是 applyMiddleware 精华之所在dispatch = compose(...chain)(store.dispatch); ，其中 compose 是函数式编程中的组合，它将 chain 中的所有匿名函数 [f1, f2, ... , fx, ..., fn]组装成一个新的函数，即新的 dispatch。当新 dispatch 执行时，[f1, f2, ... , fx, ..., fn]，从右到左依次执行。

compose(...funcs) 返回的是一个匿名函数，其中 funcs 就是 chain 数组。当调用 reduceRight时，依次从 funcs 数组的右端取一个函数 fx 拿来执行，fx 的参数 composed 就是前一次 fx+1 执行的结果，而第一次执行的 fn（n 代表 chain 的长度）的参数 arg 就是 store.dispatch。所以，当 compose 执行完后，我们得到的 dispatch 是这样的，假设 n = 3：

dispatch = f1(f2(f3(store.dispatch)))); 

这时调用新 dispatch，每一个 middleware 就依次执行了。

在 middleware 中调用 dispatch 会发生什么：经过 compose 后，所有的 middleware 算是串联起来了。可是还有一个问题，在分发 store 时，我们提到过每个 middleware 都可以访问 store，即 middlewareAPI 这个变量，也可以拿到 store 的dispatch 属性。那么，在 middleware 中调用 store.dispatch() 会发生什么，和调用 next() 有区别吗？现在我们来说明两者的不同：

const logger = store => next => action => {
 console.log("dispatch:", action);
 next(action);
 console.log("finish:", action);
};
const logger = store => next => action => {
 console.log("dispatch:", action);
 store.dispatch(action);
 console.log("finish:", action);
}; 

在分发 store 时我们解释过，middleware 中 store 的 dispatch 通过匿名函数的方式和最终compose 结束后的新 dispatch 保持一致，所以，在 middleware 中调用 store.dispatch() 和在其他任何地方调用的效果一样。而在 middleware 中调用 next()，效果是进入下一个 middleware，下图就是redux middleware最著名的洋葱模型图。

如果一个项目过大，我们通常按模块来写reducer，但是redux create store只接受一个reducer参数，所以我们需要合并reducer。这里就用到了redux提供的combineReducer辅助函数：

combineReducers({
      layout,
      home,
      ...asyncReducers
  })

这个函数用起来很简单，就是传入一个对象，key是模块reducer对应的名字， 值是对应reducer。值是一个function，相当于是一个新的reducer，源码如下：

export default function combineReducers(reducers) {
  var reducerKeys = Object.keys(reducers)
  var finalReducers = {}
  for (var i = 0; i < reducerKeys.length; i++) {
    var key = reducerKeys[i]

    if (process.env.NODE_ENV !== "production") {
      if (typeof reducers[key] === "undefined") {
        warning(`No reducer provided for key "${key}"`)
      }
    }

    if (typeof reducers[key] === "function") {
      finalReducers[key] = reducers[key]
    }
  }
  var finalReducerKeys = Object.keys(finalReducers)

  if (process.env.NODE_ENV !== "production") {
    var unexpectedKeyCache = {}
  }

  var sanityError
  try {
    assertReducerSanity(finalReducers)
  } catch (e) {
    sanityError = e
  }

  return function combination(state = {}, action) {
    if (sanityError) {
      throw sanityError
    }

    if (process.env.NODE_ENV !== "production") {
      var warningMessage = getUnexpectedStateShapeWarningMessage(state, finalReducers, action, unexpectedKeyCache)
      if (warningMessage) {
        warning(warningMessage)
      }
    }

    var hasChanged = false
    var nextState = {}
    for (var i = 0; i < finalReducerKeys.length; i++) {
      var key = finalReducerKeys[i]
      var reducer = finalReducers[key]
      var previousStateForKey = state[key]
      var nextStateForKey = reducer(previousStateForKey, action)
      if (typeof nextStateForKey === "undefined") {
        var errorMessage = getUndefinedStateErrorMessage(key, action)
        throw new Error(errorMessage)
      }
      nextState[key] = nextStateForKey
      hasChanged = hasChanged || nextStateForKey !== previousStateForKey
    }
    return hasChanged ? nextState : state
  }
}

源码不是很多，除去一些验证代码，剩下的就是说：return一个function，我们暂时称呼他combination，就相当于是与一个总的reducer，每次action都会走到combination中，combination会遍历输入的reducer，将action放到每个reducer中执行一下，计算出返回结果就是nextState，nextState于previousState如果!==说明改变了，返回nextState，否则返回执行之前的state。

这也解释了不同模块actionType如果相同的话，两个模块的reducer都会走一遍的问题，在actionType名称前面加上模块前缀即可解决问题。

Provider与Connet组件都是React-Redux提供的核心组件，两者看起来功能一样，都是帮助容器组件获取store中的数据，但是原理与功能却不同。

Provider组件在所有组件的最外层，其接受store作为参数，将store里的state使用context属性向下传递。部分源码：

export default class Provider extends Component {
 getChildContext() {
 return { store: this.store }
 }
 constructor(props, context) {
 super(props, context)
 this.store = props.store
 }
 render() {
 const { children } = this.props
 return Children.only(children)
 }
} 

利用context这个属性，Provider所有子组件均可以拿到这个属性。

connect实现的功能是将需要关联store的组件和store的dispatch等数据混合到一块，这块就是一个高阶组件典型的应用：

import hoistStatics from "hoist-non-react-statics"
export default function connect(mapStateToProps, mapDispatchToProps, mergeProps, options = {}) {
 // ...
 return function wrapWithConnect(WrappedComponent) {
 // ...
 class Connect extends Component {
 // ...
 render() {
 // ...
 if (withRef) {
 this.renderedElement = createElement(WrappedComponent, {
 ...this.mergedProps,
 ref: "wrappedInstance"
 })
 } else {
 this.renderedElement = createElement(WrappedComponent,
 this.mergedProps
 )
 }
 return this.renderedElement
 }
 }
 // ...
 return hoistStatcis(Connect, WrappedComponent);
 }
} 

还是先从他的四个参数说起：

connect 的第一个参数定义了我们需要从 Redux 状态树中提取哪些部分当作 props 传给当前组件。一般来说，这也是我们使用 connect 时经常传入的参数。事实上，如果不传入这个参数，React 组件将永远不会和 Redux 的状态树产生任何关系。具体在源代码中的表现为：

export default function connect(mapStateToProps, mapDispatchToProps, mergeProps, options = {}) {
 const shouldSubscribe = Boolean(mapStateToProps)
 // ...
 class Connect extends Component {
 // ...
 trySubscribe() {
 if (shouldSubscribe && !this.unsubscribe) {
 this.unsubscribe = this.store.subscribe(this.handleChange.bind(this))
 this.handleChange()
 }
 }
 // ...
 }
} 

mapStateToProps会订阅 Store，每当state更新的时候，就会自动执行，重新计算 UI 组件的参数，从而触发 UI 组件的重新渲染。

mapStateToProps的第一个参数总是state对象，还可以使用第二个参数，代表容器组件的props对象。

这块的源码相对较简单：

const mapState = mapStateToProps || defaultMapStateToProps 
class Connect extends Component { 
    computeStateProps(store, props) {
        if (!this.finalMapStateToProps) {
          return this.configureFinalMapState(store, props)
        }

        const state = store.getState()
        const stateProps = this.doStatePropsDependOnOwnProps ?
          this.finalMapStateToProps(state, props) :
          this.finalMapStateToProps(state)

        if (process.env.NODE_ENV !== "production") {
          checkStateShape(stateProps, "mapStateToProps")
        }
        return stateProps
      }

      configureFinalMapState(store, props) {
        const mappedState = mapState(store.getState(), props)
        const isFactory = typeof mappedState === "function"

        this.finalMapStateToProps = isFactory ? mappedState : mapState
        this.doStatePropsDependOnOwnProps = this.finalMapStateToProps.length !== 1

        if (isFactory) {
          return this.computeStateProps(store, props)
        }

        if (process.env.NODE_ENV !== "production") {
          checkStateShape(mappedState, "mapStateToProps")
        }
        return mappedState
      }
}

这块原理很简单，进行一些参数校验，判断第一个参数mapStateToProps返回值是否为function，如果是递归调用，不是的话算出返回值。如果没传这个参数，默认给{}。

我们可能会疑惑为什么传给 connect 的第一个参数本身是一个函数，react-redux 还允许这个函数的返回值也是一个函数呢？
简单地说，这样设计可以允许我们在 connect 的第一个参数里利用函数闭包进行一些复杂计算的缓存，从而实现效率优化的目的

当我们使用的时候：

const mapStateToProps = (state, props) => ({
    home: state.home,
    layout: state.layout
});

使用ownProps作为参数后，如果容器组件的参数发生变化，也会引发 UI 组件重新渲染

人如其名，它接受 store 的 dispatch 作为第一个参数，同时接受 this.props 作为可选的第二个参数。利用这个方法，我们可以在 connect 中方便地将 actionCreator 与 dispatch 绑定在一起（利用 bindActionCreators 方法），最终绑定好的方法也会作为 props 传给当前组件。这块的源码与mapStateToProps一样，就不贴了。

bindActionCreator

function bindActionCreator(actionCreator, dispatch) {
  return (...args) => dispatch(actionCreator(...args))
}

前两个参数返回的对象，都要跟组件自身的props merge一下，形成一个新的对象赋值给对应组件，我们可以在这一步做一些处理，这个参数就是干这个的，该参数签名：

mergeProps(stateProps, dispatchProps, ownProps): props

默认情况如果没传该参数，返回Object.assign(ownProps, stateProps, dispatchProps)。

如果指定这个参数，可以定制 connector 的行为。

[pure = true] (Boolean): 如果为 true，connector 将执行 shouldComponentUpdate 并且浅对比 mergeProps 的结果，避免不必要的更新，前提是当前组件是一个“纯”组件，它不依赖于任何的输入或 state 而只依赖于 props 和 Redux store 的 state。默认值为 true。

[withRef = false] (Boolean): 如果为 true，connector 会保存一个对被包装组件实例的引用，该引用通过 getWrappedInstance() 方法获得。默认值为 false。

这个connect组件还干了一件事，状态缓存判断。当store变了的时候，前后状态判断，如果状态不等，更新组件，并且完成事件分发。

上面讲了大量的函数源码，这么些函数之间的关系：

初始化阶段：

createStore创建一个store对象

将store对象通过参数给Provider组件

Provider组件将store通过context向子组件传递

Connect组件通过context获取到store，存入自己的state

componentDidMount里面订阅store.subscribe事件

更新数据阶段：

用户事件触发

actionCreator生成action交给dispatch

实际上交给了封装后的中间层（compose(applyMiddleware(...))）

请求依次通过每个中间件，中间件通过next进行下一步

最后一个中间件将action交给store.dispatch

dispatch内部将action交给reducer执行

combineReducer将每个子reducer执行一遍算出新的state

dispatch内部调用所有订阅事件

Connect组件handleChange事件触发判断新state和旧state是否===

并且判断新的state是否与mapStateToProps shallowEqual

不等则setState触发更新

匿名函数&&闭包使用

redux核心函数大量使用了匿名函数和闭包来实现数据共享和状态同步。

函数柯里化使用

使用函数柯里化s实现参数复用，本质上是降低通用性，提高适用性。

核心状态读取是拷贝而不是地址

对于state这种核心状态使用getState()计算出新的state，而不是直接返回一个state对象。

观察者订阅者是核心实现

使用观察者订阅者模式实现数据响应。

context这个api的使用

平时开发不常接触的api实现Provider与Connect通信。