前言:

  笔者之前也有一篇关于applyMiddleware的总结。是applyMiddleware的浅析。

  现在阅读了一下redux的源码。下面说说我的理解。

概要源码:

  

step 1:

   applyMiddleware(thunkMiddleware, createLogger())

  第一次执行applyMiddleware增加两个中间件;使用闭包保存中间件;然后返回一个函数(一开始我奇怪了为什么参数是createStore???)  

step 2:

  为什么参数是createStore? 我看了createStore的源码我就知道了。

  

  我们使用redux的时候是这样调用的

createStore(
rootReducers, //reducer
preloadedState,
applyMiddleware( //enhancer
thunkMiddleware,
createLogger()
)
)

  在第一次调用createStore的时候,

  createStore先判断是否有middlewares(enhancer)的加入,如果有,就不执行createStore后面的操作,return出去执行enhancer()

  注意:执行了  enhancer(createStore)  后,只传入了两个参数  (reducer, preloadState)   ,第三个enhancer 为undefine

step 3:

  执行 enhancer 就要回过头看applyMiddleware源码。

  由于没有第三个参数enhancer,所以这才是真正执行 createStore(), 返回一个没有 middleware 的 store。

step 4:

  首先为每一个middleware以{getState,dispatch}为参数执行一遍,其实是为了给middleware一个原生的{getState,dispatch}两个方法的指针。以便在middleware中调用。

  请看一个简单的middleware

    const logger = fucntion({getState, dispatch}) {
return function(next) {
return function(action){
console.log('dispatching', action)
let result = next(action)
console.log('next state', getState())
return result
}
}
}

  调用后返回的 chain 是一个以next为参数的函数数组。

step 5:

   _dispatch = _compose2['default'].apply(undefined, chain)(store.dispatch)  

  这个_compose2是redux的compose方法,

  

  红框框内的 arguments === store.dispatch,

  因此compose后返回的_dispatch是多个middleWares嵌套而成的函数,每一个next闭包变量都是里层的middleware,并且最终的next是store.dispatch

step last:

  用新的middleware多层嵌套的_dispatch代替store.dispatch,就over了

结论:

  middleware内部的dispatch是原生的没有middleware时的dispatch,

  每一个middleware都带有原生的getState,dispatch和next(下一个middleware),所以我可以在middleware中不调用next,而直接调用dispatch,就跳过了后面的middleware了。

redux:applyMiddleware源码解读的更多相关文章

  1. 通过ES6写法去对Redux部分源码解读

    在Redux源码中主要有四个文件createStore,applyMiddleware,bindActionCreators,combineRedures createStore.js export ...

  2. redux源码解读(一)

    redux 的源码虽然代码量并不多(除去注释大概300行吧).但是,因为函数式编程的思想在里面体现得淋漓尽致,理解起来并不太容易,所以准备使用三篇文章来分析. 第一篇,主要研究 redux 的核心思想 ...

  3. Redux 源码解读 —— 从源码开始学 Redux

    已经快一年没有碰过 React 全家桶了,最近换了个项目组要用到 React 技术栈,所以最近又复习了一下:捡起旧知识的同时又有了一些新的收获,在这里作文以记之. 在阅读文章之前,最好已经知道如何使用 ...

  4. redux源码解读

    react在做大型项目的时候,前端的数据一般会越来越复杂,状态的变化难以跟踪.无法预测,而redux可以很好的结合react使用,保证数据的单向流动,可以很好的管理整个项目的状态,但是具体来说,下面是 ...

  5. redux源码解读(二)

    之前,已经写过一篇redux源码解读(一),主要分析了 redux 的核心思想,并用100多行代码实现一个简单的 redux .但是,那个实现还不具备合并 reducer 和添加 middleware ...

  6. redux middleware 源码分析

    原文链接 middleware 的由来 在业务中需要打印每一个 action 信息来调试,又或者希望 dispatch 或 reducer 拥有异步请求的功能.面对这些场景时,一个个修改 dispat ...

  7. redux的源码解析

    一. redux出现的动机 1. Javascript 需要管理比任何时候都要多的state2. state 在什么时候,由于什么原因,如何变化已然不受控制.3. 来自前端开发领域的新需求4. 我们总 ...

  8. applyMiddleware源码中的闭包

    闭包都是个老掉牙的话题了,这次又提起,是因为重看Redux源码时发现了applyMiddleware里的用法很巧妙.我们先看一个简单的例子. var a = (num) => num + 1 v ...

  9. SDWebImage源码解读之SDWebImageDownloaderOperation

    第七篇 前言 本篇文章主要讲解下载操作的相关知识,SDWebImageDownloaderOperation的主要任务是把一张图片从服务器下载到内存中.下载数据并不难,如何对下载这一系列的任务进行设计 ...

随机推荐

  1. 进度条(ProgressBar)的功能与用法

    进度条也是UI界面中一种非常实用的组件,通常用于向用户显示某个耗时操作完成的的百分比.进度条可以动态的显示进度,因此避免长时间的执行某个耗时的操作,让用户感觉程序失去了响应,从而更好的提高用户界面的友 ...

  2. C# 定时器计划任务

    函数类: public class MyPlan { public void RunMyplan(object source, ElapsedEventArgs e) { //读取配置文件设定的日期时 ...

  3. Quercus

    其实,我不确定Quercus是否可以被认定为一门JVM语言:其次Quercus这个东东分开源版与商业版,开源版只能解释执行.而商业版能编译成Java字节码. 但我知道国内,阿里巴巴很早就在使用它,当然 ...

  4. loadrunner Analysis :SLA(Service Level Agreement服务水平协议)

    SLA是为负载场景定义的具体目标,用于与实际负载结果比较,确定系统是否达到性能目标. 1.1.1     设置SLA(以Transaction Response Time(Average)为例) 可以 ...

  5. POJ1273(最大流)

    Drainage Ditches Time Limit: 1000MS   Memory Limit: 10000K Total Submissions: 70451   Accepted: 2739 ...

  6. android:在ViewPager中使用Button

    最近在项目用用到ViewPager ,其中页面包含有Button,因为之前也有使用个ViewPager ,所以这个也照搬之前的方式,测试后发现点击button无法执行,这个button是在第一页面的默 ...

  7. office如何去除多页签

    写文档会遇到同时打开多个文档,偶尔可能需要对比,而有时office会出现跟浏览器类似的多页签界面.如何去除多页签,office本身没有此加载项,一般都是作为插件或组件形式另外安装,导致我们不知道从哪里 ...

  8. iOS开发中@property的属性weak nonatomic strong readonly等介绍

    @property与@synthesize是成对出现的,可以自动生成某个类成员变量的存取方法.在Xcode4.5以及以后的版本,@synthesize可以省略. 1.atomic与nonatomica ...

  9. 快速排序时间复杂度为O(n×log(n))的证明

    快速排序时间复杂度为O(n×log(n))的证明 之前只知道快速排序的平均时间复杂度为O(n×log(n)),最糟糕时复杂度为O(n^2),但却不知道具体原因,今天好好证明一下,最后部分摘自<算 ...

  10. PLSQL DEVELOPER 使用的一些技巧【转】

    1.登录后默认自动选中My Objects 默认情况下,PLSQL Developer登录后,Brower里会选择All objects,如果你登录的用户是dba,要展开tables目录,正常情况都需 ...