自己实现一个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来进行日志记录、创建崩溃报告、调用异步接口或者路由等等。

Redux流程
(网上找的)

说白了,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 是否定义。

action必须是个普通对象

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

redux-thunk

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

异步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官方文档

posted @ 2019-08-19 15:02 爱夏天的大西瓜 阅读(...) 评论(...) 编辑 收藏