Redux源码分析--数据中心篇
Posted 前端社区
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Redux源码分析--数据中心篇相关的知识,希望对你有一定的参考价值。
在如今的前端浪潮中,React和Redux有着举足轻重的地位。React,Redux再加上用于链接他们的代码库就足矣让一些没有足够经验的开发者迷失到代码的海洋里,很容易让程序员们培养成一种别人怎么写我就怎么写的编码习惯,难怪许多大神会说这是最好的时代但也是最坏的时代。
Redux
今天我想脱离整体来看局部,从源码的角度上来剖析Redux到底是个什么玩意,了解了它的原理才不至于在如今的浪潮中显得手忙脚乱。
前言
抛开React不谈,Redux其实就只是一个管理状态的数据中心,然而作为一个数据中心它的特色在于我们不能够直接修改数据中心里面的数据,我们需要自行定义操作逻辑reducer,以及操作类型action,通过分发不同的action来匹配reducer里面对应的操作,才能达到修改数据的目的。
一般来说我们会通过以下方式来创建一个数据中心
1import { createStore } from 'redux'
2const store = createStore(...blablabla)
这里最为关键的就是createStore这个函数,接下来我想详细地对它做个分析。
createStore方法剖析
createStore.js这个文件纯代码的部分大概有100多行,如果把他们全部贴出来再一一分析并非明智之举,我认为只对关键的部分进行分析是更恰当的做法。要分析一个方法我觉得比较有意义的是看它接收了什么,以及返回了什么。
1) 接收的参数
这个方法接受三个参数,分别是reducer, preloadedState, enhancer。以上都分别可以由开发者进行定义,reducer就是由开发者定义的一个操作方法,它会以旧的状态作为参数,处理过后返回一个新的状态。preloadedState则可以理解成数据中心的初始状态,它是个可选值。
1export default function createStore(reducer, preloadedState, enhancer) {
2 ...
3}
最后的enhancer又是什么呢?从字面上理解它是一个增强器,用于增强createStore。从源码看它的工作方式
1export default function createStore(reducer, preloadedState, enhancer) {
2 .....
3 if (typeof preloadedState === 'function' && typeof enhancer === 'undefined') { // 参数归一
4 enhancer = preloadedState
5 preloadedState = undefined
6 }
7 if (typeof enhancer !== 'undefined') {
8 if (typeof enhancer !== 'function') {
9 throw new Error('Expected the enhancer to be a function.')
10 }
11 return enhancer(createStore)(reducer, preloadedState) // 直接返回一个增强后的`createStore
12 }
13 .....
14}
可见,它接收了原来的createStore作为参数,并且返回了一个增强了的方法,最后用增强过的方法来调用原来传入的参数。了解原理之后我们可以很容易地写出一个状态打印增强器,用于打印dispatch前后的状态信息。
1.....
2function enhancer(createStore) {
3 return (reducer, initialState, enhancer) => {
4 const store = createStore(reducer, initialState, enhancer)
5 function dispatch(action) {
6 console.log('old', store.getState())
7 const res = store.dispatch(action);
8 console.log('new', store.getState())
9 return res
10 }
11 // 用心的dispatch方法来替换原有的dispatch方法
12 return {
13 ...store,
14 dispatch
15 }
16 }
17}
18const store = createStore(reducers, undefined, enhancer)
另外,从Redux的源码可以看到createStore做了一种叫做参数归一的处理,在许多JS库中都会采用这种方式兼容不同情况下的参数传入。当我们不需要传入初始状态,而只需要使用enhancer增强器的时候,我们还可以把代码写成这样
1const store = createStore(reducers, enhancer)
2) 返回值
接下来我们看看返回值。createStore最终会返回一个对象,包含的东西如下
1import $$observable from 'symbol-observable'
2export default function createStore(reducer, preloadedState, enhancer) {
3 .....
4 return {
5 dispatch,
6 subscribe,
7 getState,
8 replaceReducer,
9 [$$observable]: observable
10 }
11}
这些便是我们数据中心为外部提供的全部接口了。最后一个看起来有点奇怪,其他的从字面上应该都比较容易理解,容许许我一一分析。
a. getState--返回当前状态
Redux的核心理念之一就是不支持直接修改状态,它是通过闭包来实现这一点。
1export default function createStore(reducer, preloadedState, enhancer) {
2 let currentState = preloadedState
3 function getState() {
4 .....
5 return currentState
6 }
7}
它先是定义了一个内部的变量currentState,然后通过一个名为getState的方法来返回它的值。这就造成了currentState这个状态对我们而言是只读的,我们没办法直接修改它的值。在代码里面我们可以通过getState这个方法来返回当前状态
1console.log(store.getState())
b. subscribe--构造监听者队列
每个store本身会维护一个监听者队列,我们可以把它想象成一个方法的队列,在每次分发action的时候都会依次调用监听者队列中所有方法。通过这个subscribe方法可以手动地把一些回调函数添加到监听者队列中
1export default function createStore(reducer, preloadedState, enhancer) {
2 ....
3 let currentListeners = []
4 let nextListeners = currentListeners
5 ...
6 function ensureCanMutateNextListeners() {
7 if (nextListeners === currentListeners) {
8 nextListeners = currentListeners.slice()
9 }
10 }
11 ...
12 function subscribe(listener) {
13 .....
14 let isSubscribed = true
15 ensureCanMutateNextListeners()
16 nextListeners.push(listener)
17 return function unsubscribe() {
18 if (!isSubscribed) {
19 return
20 }
21 ....
22 isSubscribed = false
23 ensureCanMutateNextListeners()
24 const index = nextListeners.indexOf(listener)
25 nextListeners.splice(index, 1)
26 }
27 }
28}
逻辑其实很简单,为了减少篇幅我把一些类型检查的代码去掉了。每次调用subscribe的时候传入一个回调函数,subscribe会把它放到一个监听者队列中去,并返回一个unsubscribe的方法。这个unsubscribe方法是让开发者可以方便地从列表中删除对应的回调函数,此外该方法还维护着一个isSubscribed标识订阅状态。
这里面有一个比较有意思的ensureCanMutateNextListeners的方法,按照代码的逻辑,它是要保证监听者的添加与删除并不在currentListeners这个原始的队列里面进行直接操作,我们操作的只是它的一个副本。直到我们调用dispatch方法进行分发的时候,currentListeners与nextListeners才会再一次指向同一个对象,这个在后面的代码里面会看到。
c. dispatch--低调的action分发者
dispatch方法是用来分发action的,可以把它理解成用于触发数据更新的方法。它的核心实现也比较简单
1export default function createStore(reducer, preloadedState, enhancer) {
2 ...
3 function dispatch(action) {
4 ....
5 // 调用reducer
6 try {
7 isDispatching = true
8 currentState = currentReducer(currentState, action)
9 } finally {
10 isDispatching = false
11 }
12 // 调用监听者
13 const listeners = (currentListeners = nextListeners)
14 for (let i = 0; i < listeners.length; i++) {
15 const listener = listeners[i]
16 listener()
17 }
18 return action
19 }
20}
我依旧把一些类型检查的代码去掉,首先dispatch方法会以当前的状态currentState以及我们定义的动作action作为参数来调用当前的reducer方法。另外它使用isDispatching变量来记录分发的状态,正在分发则设置为true。这里需要注意的是我们的reducer方法将会被设置成一个纯函数--它不会产生副作用,并且对于同样的输入它会返回同样的输出。换句话说它不会直接在原来状态的基础上进行修改,而是会直接返回一个新的状态,并对原有状态进行替换。
完成了上面这些之后我们会依次遍历所有的监听者,并且手动调用所有的回调函数。这里需要注意的是之前有讲过的,订阅/取消订阅的时候我们会生成一个currentLIsteners的副本nextListeners并在它上面添加/删除回调函数。然而到了dispatch这一步他们会做一次同步,这样他们就又会指向同一个对象了。
d. replaceReducer--替换当前的reducer
replaceReducer这个方法做的事情其实很简单,它可以用新的reducer替换掉当前的reducer,并且分发一个替换的action,下面是源代码
1export default function createStore(reducer, preloadedState, enhancer) {
2 .....
3 function replaceReducer(nextReducer) {
4 .....
5 currentReducer = nextReducer
6 dispatch({ type: ActionTypes.REPLACE })
7 }
8}
据说这种方式在调试环境下会用得比较多。在正式环境下一般都不会在中途更替reducer,以免得增加维护成本。
e. observable--观察者
这个是比较让我费解的一个功能了,然而Redux的数据中心居然把它作为api开放出来,咱门先贴源码
1export default function createStore(reducer, preloadedState, enhancer) {
2 ....
3 function observable() {
4 const outerSubscribe = subscribe
5 return {
6 ...
7 subscribe(observer) {
8 ....
9 function observeState() {
10 if (observer.next) {
11 observer.next(getState())
12 }
13 }
14 observeState()
15 const unsubscribe = outerSubscribe(observeState)
16 return { unsubscribe }
17 },
18 [$$observable]() {
19 return this
20 }
21 }
22 }
23}
如果直接调用这个接口,它会返回一个对象,而对象里面包含了subscribe方法,并且我们可以把一个包含next字段(它是一个函数)的对象作为subscribe方法的参数,就可以在每次数据变动的时候以当前状态getState()作为参数调用next所携带的函数。
这么说有点拗口,可能给个例子会比较直观
这样就可以做到每次动作被分发的时候都会调用next所携带的方法,并打印出getState()的值。这种观察者模式的写法有什么特殊的意义我也还没有时间去深究,似乎是草案的一部分,估计目前用的也不多,先不深入探究了。
尾声
这篇文章的原标题是Redux源码分析,但由于本人概括能力有限,感觉只用一篇文章要分析完整个Redux的源码有点艰难,所以最后还是决定拆分,这篇文章主要讲解Redux的数据中心store到底是什么玩意,分别对store开放的api进行源码分析,简单了解了一下它的工作原理。
最权威
最全面
最精彩
以上是关于Redux源码分析--数据中心篇的主要内容,如果未能解决你的问题,请参考以下文章
Android 逆向整体加固脱壳 ( DEX 优化流程分析 | DexPrepare.cpp 中 dvmOptimizeDexFile() 方法分析 | /bin/dexopt 源码分析 )(代码片段
redux教程之源码解析2 combineReducers(分析在注释中)
Android 插件化VirtualApp 源码分析 ( 目前的 API 现状 | 安装应用源码分析 | 安装按钮执行的操作 | 返回到 HomeActivity 执行的操作 )(代码片段