• 前言
    react已经出来很久了,其生态圈之庞大,一锅炖不下!各种react-xx,已让我们不堪重负,github上随便一个demo,引入的模块至少都是五指之数+。看着头疼,嚼之无味……。
    在此建议新学者,可以从基础的核心模块学起,前期不要考虑那些数量繁多的马仔小弟,边学边写,个人感觉前期核心要学的流程大致如下:
    React ——> React + redux + React-redux ——> React + redux + React-redux + React-router ——> React + redux + React-redux + React-router ;
    其它的,看情况学习和了解,我也很菜,以上感悟都是针对初学者,希望可以减少他们在学习过程中接触过多的东西,而影响学习信心和乐趣。
  • 文档
    React小书(作者从无到有,讲述了React的起源,通俗易懂)Note: 第三阶段的文档现在开始收费查看了,不过对于搞前端的人来说不用钱也可以来个亲密接触的(大家自己想办法)
    Redux莞式教程(抛开需求讲实用性都是耍流氓,作者扮演一位PM给我们上了生动的一课,深入浅出,简明扼要)
    React-Router文档(一部中规中矩的翻译之作)

以上是整理的一些说明和文档资料,没有看过的可以去了解一下。下面将开始本文的主题:redux的中间件applyMiddleware。

都说名字越长,越让学者害怕,applyMiddleware的名字看起来就挺吓人,那么为什么会出现中间件,它是做什么的?它为什么叫中间件?为什么说可以用来解决异步dispatch?经过一段时间的了解,让我渐渐明白了它的工作原理,现在让我们带问题,怀着简单,轻松的心态走进applyMiddleware大讲堂:

  1. 为什么会出现中间件?
    我们知道redux的核心,就是控制和管理所有的数据输入输出,因此有了dispatch,由于dispatch是一个很纯的纯函数,就是单纯的派发action来更改数据,其功能简单且固定。
    假如现在产品经理A某有个需求,要求记录每次的dispatch记录,我们怎么办呢?最简单直接的办法就是在每一个dispatch的前面加上:

    console.log('dispatching', action);
    dispatch(action)

    假如又来一个产品B说,我需要记录每次数据出错的原因,我们怎么办呢?然后我们又需要在对每一个dispatch做修改

    try{
    dispatch(action)
    }catch(err){
    console.error('错误报告: ', err)
    }  

    如果我们的程序中有很多的dispatch,我们就需要添加很多的重复代码,虽然编辑器提供批量替换,但这无疑是产生了很多样板代码。
    因为所有的需求都是和dispatch息息相关,所以只要我们把日志放进dispatch函数里,不就好了吗,我们只需要更改dispatch函数,把dispatch进行一层封装。
    大概的封装就是下面这样:

    let next = store.dispatch
    store.dispatch = function dispatchAndLog(action) {
    console.log('dispatching', action)
    next(action)
    }

    Redux把这个封装的入口写成了一个函数,就叫applyMiddleware。
    由此我们明白了applyMiddleware的功能:改造dispatch函数,产生真假dispatch,而中间件就是运行在假真(dispatchAndLog和next)之间的代码。
    这里我们要对applyMiddleware进行一个准确的定义,它只是一个用来加工dispatch的工厂,而要加工什么样的dispatch出来,则需要我们传入对应的中间件函数(比如上例中的dispatchAndLog),下面我们构造一个精简版的applyMiddleware:

    const applyMiddleware = function(middleware){
    let next = store.dispatch;
    store.dispatch = middleware(store)(next); // 这里传入store,是因为中间件中有可能会用到getState获取数据,比如打印当前用户等需求
    } applyMiddleware(dispatchAndLog) 
  2. 中间件的串联融合。
    中间件的功能各不相同,它们都要融入到dispatch中,在派发action的时候,按照顺序一个个的执行,这是一个费脑经的事情。
    假如现在我们有两个中间件 logger和collectError两个中间件函数,那么大概的执行顺序就是 dispatch——>logger改造——>collectError改造。这里我们能看到后面的中间件需要接收到前面改造后的dispatch,
    在前面,我们是直接修改store.dispatch,现在我们换一种写法,让每一个中间件函数,接收一个dispatch,然后返回一个改造后的dispatch,来作为下一个中间件函数的next,以此类推,用ES6的写法大概代码如下:
    const logger = store => next => action => {
    console.log('dispatching', action)
    return next(action)
    } const collectError = store => next => action => {
    try {
    return next(action)
    } catch (err) {
    console.error('Error!', err)
    }
    }

    然后,我们改造一下applyMiddleware,来接收一个middlewares数组:

    function applyMiddleware(middlewares) {
    middlewares = middlewares.slice()
    middlewares.reverse() let dispatch = store.dispatch
    middlewares.forEach(middleware =>
    dispatch = middleware(store)(dispatch)
    )
    return Object.assign({}, store, { dispatch })
    }

    上面的middleware(store)(dispatch) 就相当于是 const logger = store => next => {},这就是构造后的dispatch,继续向下传递。这里middlewares.reverse(),进行数组反转的原因,是最后构造的dispatch,实际上是最先执行的。因为在applyMiddleware串联的时候,每个中间件只是返回一个新的dispatch函数给下一个中间件,实际上这个dispatch并不会执行。只有当我们在程序中通过store.dispatch(action),真正派发的时候,才会执行。而此时的dispatch是最后一个中间件返回的包装函数。然后依次向前递推执行。
    我们拿logger和collectError来说明:

    构造过程:

    let next = store.dispatch;
    let dispatch1 = logger(store)(next);
    // 这时候的console.log('dispatching', action) 是没有执行的 let dispatch2 = collectError(store)(dispatch1);
    // 这时候的console.log('Error!', err) 也是没有执行的 store.dispatch = dispatch2;

    执行过程:

    store.dispatch(action); //假如我们程序中派发了某个action
    
    //相当于是下面这样
    dispatch2(action); //此时执行了 console.log('Error', err) //由于collectError中间件中的next是接收的logger返回函数即dispatch1,所以在开始执行
    dispatch1(action); //此时执行了 console.log('dispatching', action) // 这个例子不太合理,因为错误报告是先 try 的 next(action),但是正常的流程是如此。

    未完待续……

05-04 02:59