前端网红框架的插件机制全梳理（axios、koa、redux、vuex）

序言后端中的库许多，合作开发那些库的译者会尽量的全面覆盖到他们在销售业务中五花八门的市场需求，但浑然不觉难以料到的，因此杰出的库就须要提供更多一类监督机制，让合作开发人员能干涉应用程序尾端的许多各个环节，进而顺利完成他们的许多市场需求。

责任编辑将从koa、axios、vuex和redux的同时实现来教你是不是撰写属于他们的应用程序监督机制。

对初学者而言：责任编辑能让你搞知道谜样的应用程序和圣夫龙究竟是甚么小东西。对新手而言：在你写的开放源码架构中也重新加入圣夫龙或是应用程序机制，让它显得更为强悍吧!

axios

具体来说他们演示两个单纯的 axios，这儿不牵涉允诺的方法论，而已单纯的回到两个 Promise，能透过 config 中的 error 模块掌控 Promise 的状态。

axios 的圣夫龙监督机制用时序来则表示只不过是这种的：

时序

const axios = config => { if (config.error) { return Promise.reject({ error: “error in axios” }); } else { return Promise.resolve({ …config, result: config.result }); } };

假如传至的 config 中有 error 模块，就回到两个 rejected 的 promise，反之则回到 resolved 的 promise。

先单纯看一下 axios 官方提供更多的圣夫龙示例：

axios.interceptors.request.use( function(config) { // 在发送允诺之前做些甚么 return config; }, function(error) { // 对允诺错误做些甚么 return Promise.reject(error); } ); // 添加响应圣夫龙 axios.interceptors.response.use(function(response) { // 对响应数据做点甚么 return response; }, function(error) { // 对响应错误做点甚么 return Promise.reject(error); } );

能看出，不管是 request 还是 response 的圣夫龙，都会接受两个函数作为模块，两个是用来处理正常流程，两个是处理失败流程，这让人想到了甚么?

没错，promise.then接受的同样也是这两个模块。

axios 内部正是利用了 promise 的这个监督机制，把 use 传至的两个函数作为两个intercetpor，每两个intercetpor都有resolved和rejected两个方法。

// 把 axios.interceptors.response.use(func1, func2) // 在内部存储为 { resolved: func1, rejected: func2 }

接下来单纯同时实现一下，这儿他们简化一下，把

axios.interceptor.request.use转为

axios.useRequestInterceptor来单纯同时实现：// 先构造两个对象存放圣夫龙 axios.interceptors = { request: [], response: [] }; //注册允诺圣夫龙 axios.useRequestInterceptor =(resolved, rejected) =>{ axios.interceptors.request.push({ resolved, rejected }); };// 注册响应圣夫龙 axios.useResponseInterceptor = (resolved, rejected) =>{ axios.interceptors.response.push({ resolved, rejected }); };//运行圣夫龙 axios.run = config => { const chain = [ { resolved: axios, rejected:undefined } ]; //把允诺圣夫龙往数组头部推 axios.interceptors.request.forEach(interceptor => { chain.unshift(interceptor); });//把响应圣夫龙往数组尾部推 axios.interceptors.response.forEach(interceptor => { chain.push(interceptor); });//把config也包装成两个promise let promise = Promise.resolve(config);// 暴力while循环解忧愁 // 利用promise.then的能力递归执行所有的圣夫龙 while(chain.length) { const { resolved, rejected } = chain.shift(); promisepromise = promise.then(resolved, rejected); } // 最后暴露给用户的是响应圣夫龙处理过后的promise return promise; };

从axios.run这个函数看运行时的监督机制，具体来说构造两个chain作为 promise 链，并且把正常的允诺也是他们的允诺模块 axios 也构造为两个圣夫龙的结构，接下来

把 request 的 interceptor 给 unshift 到chain顶部把 response 的 interceptor 给 push 到chain尾部

以这种一段调用代码为例：

// 允诺圣夫龙1 axios.useRequestInterceptor(resolved1, rejected1); // 允诺圣夫龙2 axios.useRequestInterceptor(resolved2, rejected2); // 响应圣夫龙1 axios.useResponseInterceptor(resolved1, rejected1); // 响应圣夫龙 axios.useResponseInterceptor(resolved2, rejected2);

这种子构造出来的 promise 链是这种的chain结构：

[ 允诺圣夫龙2，// ↓config 允诺圣夫龙1，// ↓config axios允诺核心方法, // ↓response 响应圣夫龙1, // ↓response 响应圣夫龙// ↓response ]

至于为甚么 requestInterceptor 的顺序是反过来的，仔细看看代码就知道 XD。

有了这个chain之后，只须要一句简短的代码：

letpromise =Promise.resolve(config); while (chain.length) { const{ resolved, rejected } = chain.shift(); promisepromise = promise.then(resolved, rejected); }return promise;

promise 就会把这个链从上而下的执行了。

以这种的一段测试代码为例：

axios.useRequestInterceptor(config => { return { …config, extraParams1: “extraParams1”}; }); axios.useRequestInterceptor(config => { return { …config, extraParams2: “extraParams2”}; }); axios.useResponseInterceptor(resp => { const{ extraParams1, extraParams2, result: { code, message } } = resp;return `${extraParams1} ${extraParams2} ${message}`; }, error => { console.log(“error”, error); } );

(1) 成功的调用

在成功的调用下输出 result1: extraParams1 extraParams2 message1

(async function() { const result = await axios.run({ message: “message1” }); console.log(“result1: “, result); })();

(2) 失败的调用

(async function() { const result = await axios.run({ error: true }); console.log(“result3: “, result); })();

在失败的调用下，则进入响应圣夫龙的 rejected 分支：

具体来说打印出圣夫龙定义的错误日志：

error { error: error in axios }

然后由于失败的圣夫龙

error=> { console.log(error, error) },

没有回到任何小东西，打印出result3: undefined

能看出，axios 的圣夫龙是非常灵活的，能在允诺阶段任意的修改 config，也能在响应阶段对 response 做各种处理，这也是因为用户对允诺数据的市场需求是非常灵活的，没有必要干涉用户的自由度。

vuex

vuex 提供更多了两个 api 用来在 action 被调用前后插入许多方法论：

https://vuex.vuejs.org/zh/api/#subscribeaction

store.subscribeAction({ before: (action, state) => { console.log(`before action ${action.type}`); }, after: (action, state) => { console.log(`after action ${action.type}`); } });

只不过这有点像 AOP(面向切面编程)的编程思想。

在调用store.dispatch({ type: add })的时候，会在执行前后打印出日志

before actionadd add after action add

来单纯同时实现一下：

import { Actions, ActionSubscribers, ActionSubscriber, ActionArguments } from“./vuex.type”; class Vuex { state= {}; action = {}; _actionSubscribers = []; constructor({state, action }) { this.state = state; this.action = action; this._actionSubscribers = []; } dispatch(action) {// action前置监听器 this._actionSubscribers.forEach(sub => sub.before(action, this.state)); const { type, payload } = action; //执行action this.action[type](this.state, payload).then(() => {// action后置监听器 this._actionSubscribers.forEach(sub => sub.after(action, this.state)); }); } subscribeAction(subscriber) { //把监听者推进数组 this._actionSubscribers.push(subscriber); } } const store = new Vuex({state: { count: 0}, action: { async add(state, payload) { state.count += payload; } } }); store.subscribeAction({ before: (action,state) => { console.log(`before action ${action.type}, before count is ${state.count}`); }, after: (action, state) => { console.log(`after action ${action.type}, after count is ${state.count}`); } }); store.dispatch({ type: “add”, payload: 2 });

此时掌控台会打印如下内容：

before actionadd, before count is 0 after action add, after count is 2

轻松同时实现了日志功能。

当然 Vuex 在同时实现应用程序功能的时候，选择性的将 type payload 和 state 暴露给外部，而不再提供更多进一步的修改能力，这也是架构内部的一类权衡，当然他们能对 state 进行直接修改，但不可避免的会得到 Vuex 内部的警告，因为在 Vuex 中，所有 state 的修改都应该透过 mutations 来进行，但 Vuex 没有选择把 commit 也暴露出来，这也约束了应用程序的能力。

redux

想要理解 redux 中的尾端件监督机制，须要先理解两个方法：compose

function compose(…funcs: Function[]) { return funcs.reduce((a, b) => (…args: any) =>a(b(…args))); }

单纯理解的话，是compose(fn1, fn2, fn3) (…args) = > fn1(fn2(fn3(…args)))

它是一类高阶聚合函数，相当于把 fn3 先执行，然后把结果传给 fn2 再执行，再把结果交给 fn1 去执行。

有了这个前置知识，就能很轻易的同时实现 redux 的尾端件监督机制了。

虽然 redux 源码里写的很少，各种高阶函数各种柯里化，但抽丝剥茧以后，redux 尾端件的监督机制能用一句话来解释：

把 dispatch 这个方法不断用高阶函数包装，最后回到两个强化过后的 dispatch

以 logMiddleware 为例，这个 middleware 接受原始的 redux dispatch，回到的是

有了这个思路，就来同时实现这个 mini-redux 吧：

接着写两个尾端件

// 使用 const otherDummyMiddleware = dispatch => { // 回到两个新的dispatchreturn action => { console.log(`type in dummy is ${type}`); returndispatch(action); }; }; // 这个dispatch只不过是otherDummyMiddleware执行后回到otherDummyDispatch const typeLogMiddleware = dispatch => { // 回到两个新的dispatchreturn ({ type, …args }) => { console.log(`type is ${type}`); return dispatch({ type, …args }); }; }; // 尾端件从右往左执行。 const counterStore = createStore(counterReducer, [ typeLogMiddleware, otherDummyMiddleware ]); console.log(counterStore.getState().count); counterStore.dispatch({ type: “add”, payload: 2 }); console.log(counterStore.getState().count); // 输出： // 0 // type is add // type in dummy is add // 2

koa

koa 的洋葱模型想必各位都听说过，这种灵活的尾端件监督机制也让 koa 显得非常强悍，责任编辑也会同时实现两个单纯的洋葱尾端件监督机制。参考(umi-request 的尾端件监督机制)

洋葱圈

对应这张图来看，洋葱的每两个圈是两个尾端件，它即能掌管允诺进入，也能掌管响应回到。

它和 redux 的尾端件监督机制有点类似，本质上都是高阶函数的嵌套，外层的尾端件嵌套着内层的尾端件，这种监督机制的好处是能他们掌控尾端件的能力(外层的尾端件能影响内层的允诺和响应阶段，内层的尾端件只能影响外层的响应阶段)

具体来说他们写出Koa这个类

class Koa { constructor() { this.middlewares = []; } use(middleware) {this.middlewares.push(middleware); } start({ req }) { const composed = composeMiddlewares(this.middlewares); const ctx = { req, res: undefined }; return composed(ctx); } }

这儿的 use 是单纯的把尾端件推入尾端件队列中，那核心是怎样去把那些尾端件组合起来了，下面看composeMiddlewares方法：

单纯而言 dispatch(n)对应着第 n 个尾端件的执行，而 dispatch(n)又拥有执行 dispatch(n + 1)的权力，

因此在真正运行的时候，尾端件并不是在平级的运行，而是嵌套的高阶函数：

dispatch(0)包含着 dispatch(1)，而 dispatch(1)又包含着 dispatch(2) 在这个模式下，他们很容易联想到try catch的监督机制，它能 catch 住函数以及函数内部继续调用的函数的所有error。

那么他们的第两个尾端件就能做两个错误处理尾端件：

// 最外层管控全局错误 app.use(async (ctx, next) => { try { // 这儿的next包含了第二层以及第三层的运行 await next(); } catch (error) { console.log(`[koa error]: ${error.message}`); } });

在这个错误处理尾端件中，他们把 next 包裹在 try catch 中运行，调用了 next 后会进入第二层的尾端件：

//第二层日志尾端件 app.use(async (ctx, next) => { const { req } = ctx;console.log(`req is ${JSON.stringify(req)}`); await next(); // next过后已经能拿到第三层写进ctx的数据了 console.log(`res is ${JSON.stringify(ctx.res)}`); });

在第二层尾端件的 next 调用后，进入第三层，销售业务方法论处理尾端件

// 第三层核心服务尾端件 // 在真实场景中这一层一般用来构造真正须要回到的数据写入ctx中 app.use(async (ctx,next) => { const { req } = ctx; console.log(`calculating the res of ${req}…`); const res = { code: 200, result: `req ${req} success` }; //写入ctx ctx.res = res; awaitnext(); });

在这一层把 res 写入 ctx 后，函数出栈，又会回到第二层尾端件的await next()后面

console.log(`req is ${JSON.stringify(req)}`); await next(); // <- 回到这儿 console.log(`res is ${JSON.stringify(ctx.res)}`);

这时候日志尾端件就能拿到ctx.res的值了。

想要测试错误处理尾端件就在最后重新加入这个尾端件

// 用来测试全局错误尾端件 //注释掉这两个尾端件服务才能正常响应 app.use(async (ctx, next) => {throw new Error(“oops! error!”); });

最后要调用启动函数：

app.start({ req: “ssh” });

掌控台打印出结果：

req is “ssh”calculating the resof ssh… res is {“code”:200,“result”:“req ssh success”}

总结

(1) axios 把用户注册的每个圣夫龙构造成两个 promise.then 所接受的模块，在运行时把所有的圣夫龙按照两个 promise 链的形式以此执行。

在发送到服务端之前，config 已经是允诺圣夫龙处理过后的结果服务器响应结果后，response 会经过响应圣夫龙，最后用户拿到的是处理过后的结果了。