Redux源码解析系列 (二)牛鼻的createStore

前言
在上一章了解了【Redux 源码解析系列(一) -- Redux的实现思想】之后，我们正式进入源码解析~

Redux 其实是用来帮我们管理状态的一个框架，它暴露给我们四个接口，分别是：

• createStore
• combineReducers
• bindActionCreators
• applyMiddleware
• compose

本篇文章，我们来解析createStore
下面我来对其进行解析~

INIT
这个方法是redux保留用的，用来初始化reducer的状态 

export const ActionTypes = { 
  INIT: '@@redux/INIT' 
} 

前面说 createStore的作用就是：创建一个store来管理app的状态，唯一改变状态的方式就是dispatch一个action，最终返回一个object。

return { 
    dispatch, 
    subscribe, 
    getState, 
    replaceReducer, 
    [$$observable]: observable 
} 

不过replaceReducer,跟[$$observable]:都不常用~ ，所以这里只对前三的接口做解析。

createStore
在一个app里，只能有一个store，如果你想指明不同的state对应不同的action，可以用combineReducers去合并不同的reducer。

参数：

• reducer(function):就是通过传入当前State，还有action，计算出下一个state，返回回来。
• preloadedState(any):initial state
• enhancer(function):增强store的功能，让它拥有第三方的功能，比如middleware.Redux里面唯一的enhancer就是applyMiddleware()

export default function createStore(reducer, preloadedState, enhancer) { 
// 第一段说的就是当第二个参数没有传preloadedState，而直接传function的话，就会直接把这个function当成enhancer 
  if (typeof preloadedState === 'function' && typeof enhancer === 'undefined') { 
    enhancer = preloadedState 
    preloadedState = undefined 
  } 
  // 当第三个参数传了但是不是function也会报错 
  if (typeof enhancer !== 'undefined') { 
    if (typeof enhancer !== 'function') { 
      throw new Error('Expected the enhancer to be a function.') 
    } 
    //关键的一个就在于这里了，在前一篇讲applyMiddleware的时候介绍了这么做的意义， 
    //实际就是把createStore这件事在applyMiddleware里面做，转移了锅。 
    return enhancer(createStore)(reducer, preloadedState) 
  } 
 
  if (typeof reducer !== 'function') { 
    throw new Error('Expected the reducer to be a function.') 
  } 
 
  let currentReducer = reducer 
  let currentState = preloadedState 
  let currentListeners = [] 
  let nextListeners = currentListeners 
  let isDispatching = false 
} 

上面是第一个part，在校验完参数的正确之后，终于可以干点正事儿了。createStore最终会返回一个Object.

{ 
 dispatch, 
 subscribe, 
 getState 
} 

接下来看看里面都做了什么：

getState
getState作用就是将当前state的状态返回回来，没啥好说的~

function getState() { 
   return currentState 
} 

subscribe
作用：添加监听函数listener,它会在每次dispatch action的时候调用。

参数：listener(function): 在每一次dispatch action的时候都会调用的函数

返回：返回一个移除listener的函数

// 这个函数的作用就是，如果发现nextListeners，nextListeners指向同一个堆栈的话，就浅复制一份，这样改nextListeners就不会改到currentListeners 
function ensureCanMutateNextListeners() { 
    if (nextListeners === nextListeners) { 
      nextListeners = currentListeners.slice() 
    } 
} 
 
function subscribe(listener) { 
    if (typeof listener !== 'function') { 
      throw new Error('Expected listener to be a function.') 
    } 
 
    let isSubscribed = true 
 
    ensureCanMutateNextListeners() 
    // 直接将监听的函数放进nextListeners里 
    nextListeners.push(listener) 
 
    return function unsubscribe() { 
    // 如果已经移除了就直接返回 
      if (!isSubscribed) { 
        return 
      } 
 
      isSubscribed = false 
 
      ensureCanMutateNextListeners() 
      // 没有移除的话，先找到位置，通过splice移除 
      const index = nextListeners.indexOf(listener) 
      nextListeners.splice(index, 1) 
    } 
  } 

在使用的时候就可以：

const unsubscribe = store.subscribe(() => 
  console.log(store.getState()) 
) 
 
unsubscribe() 
dispatch 

dispatch
dispatch 作为一个重点函数~ 其实它的作用就是触发状态的改变。

参数：action(object),它是一个描述发生了什么的对象，其中type是必须的属性。

返回：这个传入的object

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?' 
      ) 
    } 
    // 防止多次dispatch请求同时改状态，一定是前面的dispatch结束之后，才dispatch下一个 
    if (isDispatching) { 
      throw new Error('Reducers may not dispatch actions.') 
    } 
 
    try { 
      isDispatching = true 
      currentState = currentReducer(currentState, action) 
    } finally { 
      isDispatching = false 
    } 
    // 在dispatch的时候，又将nextListeners 赋值回currentListeners， 
    const listeners = currentListeners = nextListeners 
    for (let i = 0; i < listeners.length; i++) { 
      const listener = listeners[i] 
      listener() 
    } 
 
    return action 
  } 

在上面一系列完成之后，需要初始化appState的状态。当INIT action被dispatched 的时候，每个reducer都会return回它的初始状态。

dispatch({ type: ActionTypes.INIT }) 

自问自答环节
为什么createStore中既存在currentListeners也存在nextListeners？
在上面的源码中，createStore函数为了保存store的订阅者，不仅保存了当前的订阅者currentListeners而且也保存了nextListeners。createStore中有一个内部函数ensureCanMutateNextListeners:

function ensureCanMutateNextListeners() { 
    if (nextListeners === currentListeners) { 
      nextListeners = currentListeners.slice() 
    } 
} 

这个函数实质的作用是确保可以改变nextListeners,如果nextListeners与currentListeners一致的话，将currentListeners做一个拷贝赋值给nextListeners,然后所有的操作都会集中在nextListeners,比如我们看订阅的函数subscribe:

function subscribe(listener) { 
// ...... 
    let isSubscribed = true 
 
    ensureCanMutateNextListeners() 
    nextListeners.push(listener) 
 
    return function unsubscribe() { 
        // ...... 
        ensureCanMutateNextListeners() 
        const index = nextListeners.indexOf(listener) 
        nextListeners.splice(index, 1) 
} 

我们发现订阅和解除订阅都是在nextListeners做的操作，然后每次dispatch一个action都会做如下的操作:

function dispatch(action) { 
    try { 
      isDispatching = true 
      currentState = currentReducer(currentState, action) 
    } finally { 
      isDispatching = false 
    } 
    // 相当于currentListeners = nextListeners const listeners = currentListeners 
    const listeners = currentListeners = nextListeners 
    for (let i = 0; i < listeners.length; i++) { 
      const listener = listeners[i] 
      listener() 
    } 
    return action 
  } 

我们发现在dispatch中做了const listeners = currentListeners = nextListeners，相当于更新了当前currentListeners为nextListeners,然后通知订阅者，到这里我们不禁要问为什么要存在这个nextListeners?　　 　　其实代码中的注释也是做了相关的解释:

The subscriptions are snapshotted just before every dispatch() call.If you subscribe or unsubscribe while the listeners are being invoked, this will not have any effect on the dispatch() that is currently in progress.However, the next dispatch() call, whether nested or not, will use a more recent snapshot of the subscription list.

来让我这个六级没过的渣渣翻译一下: 订阅者(subscriptions)在每次dispatch()调用之前都是一份快照(snapshotted)。如果你在listener被调用期间，进行订阅或者退订，在本次的dispatch()过程中是不会生效的，然而在下一次的dispatch()调用中，无论dispatch是否是嵌套调用的，都将使用最近一次的快照订阅者列表。用图表示的效果如下:

我们从这个图中可以看见，如果不存在这个nextListeners这份快照的话，因为dispatch导致的store的改变，从而进一步通知订阅者，如果在通知订阅者的过程中发生了其他的订阅(subscribe)和退订(unsubscribe),那肯定会发生错误或者不确定性。例如:比如在通知订阅的过程中，如果发生了退订，那就既有可能成功退订(在通知之前就执行了nextListeners.splice(index, 1))或者没有成功退订(在已经通知了之后才执行了nextListeners.splice(index, 1))，这当然是不行的。因为nextListeners的存在所以通知订阅者的行为是明确的，订阅和退订是不会影响到本次订阅者通知的过程。

还是看不懂是什么意思？？？？？一个简单粗俗的例子：

当在执行这段代码到第三个listener的时候：

for (let i = 0; i < listeners.length; i++) { 
  const listener = listeners[i] 
  listener() 
} 

你突然把第2个listener给splice了。这样的话此时上面的循环本来是执行完第三个要执行第四个了，但是由于数组中的第2个listener被splice掉了，所以数组后面的元素都要往前移动一个位置，这时数组的第四个listener就移动到原先第三个的位置了，数组的第五个listener就移动到原先第四个的位置了，因此循环本要执行第四个的，结果由于第四个往前移动了，实际执行的是原先的第五个，所以导致原先的第四个没有被执行。。

没错，上面讲的就是这样的！！！！哈哈哈明白了吧！！！！

但是这里又有一个问题了：

JavaScript不是单线程的吗？为啥在执行循环的时候，会执行unsubscribe()操作
百思不得其解的情况下，去Redux项目下开了一个issue，得到了维护者的回答:

得了，我们再来看看测试相关的代码吧。看完之后我了解到了。的确，因为JavaScript是单线程语言，不可能出现出现想上述所说的多线程场景，但是我忽略了一点，执行订阅者函数时，在这个回调函数中可以执行退订或者订阅事件。例如:

const store = createStore(reducers.todos) 
const unsubscribe1 = store.subscribe(() => { 
    const unsubscribe2 = store.subscribe(()=>{}) 
}) 

这不就实现了在通知listener的过程中混入订阅subscribe与退订unsubscribe吗？

为什么Reducer中不能进行dispatch操作？
我们知道在reducer函数中是不能执行dispatch操作的。一方面，reducer作为计算下一次state的纯函数是不应该承担执行dispatch这样的操作。另一方面，即使你尝试着在reducer中执行dispatch,也并不会成功，并且会得到"Reducers may not dispatch actions."的提示。因为在dispatch函数就做了相关的限制:

function dispatch(action) { 
    if (isDispatching) { 
      throw new Error('Reducers may not dispatch actions.') 
    } 
    try { 
      isDispatching = true 
      currentState = currentReducer(currentState, action) 
    } finally { 
      isDispatching = false 
    } 
 
    //...notice listener 
} 

在执行dispatch时就会将标志位isDispatching置为true。然后如果在currentReducer(currentState, action)执行的过程中由执行了dispatch，那么就会抛出错误('Reducers may not dispatch actions.')。之所以做如此的限制，是因为在dispatch中会引起reducer的执行，如果此时reducer中又执行了dispatch，这样就落入了一个死循环，所以就要避免reducer中执行dispatch。

参考文献：

1. https://github.com/MrErHu/blog/issues/18
2. https://zhuanlan.zhihu.com/p/57316118

 【编辑推荐】