扣丁書屋

前端網紅框架的插件機制全梳理(axios、koa、redux、vuex)

前言

前端中的庫很多,開發這些庫的作者會盡可能的覆蓋到大家在業務中千奇百怪的需求,但是總有無法預料到的,所以優秀的庫就需要提供一種機制,讓開發者可以干預插件中間的一些環節,從而完成自己的一些需求。

本文將從koa、axios、vuexredux的實現來教你怎么編寫屬于自己的插件機制。

  • 對于新手來說: 本文能讓你搞明白神秘的插件和攔截器到底是什么東西。
  • 對于老手來說: 在你寫的開源框架中也加入攔截器或者插件機制,讓它變得更加強大吧!

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都有resolvedrejected兩個方法。

// 把
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();
    promise = 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之后,只需要一句簡短的代碼:

let promise = Promise.resolve(config);

while (chain.length) {
  const { resolved, rejected } = chain.shift();
  promise = 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 action add
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 action add, 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,返回的是


const typeLogMiddleware = dispatch => {
  // 返回的其實還是一個結構相同的dispatch,接受的參數也相同
  // 只是把原始的dispatch包在里面了而已。
  return ({ type, ...args }) => {
    console.log(`type is ${type}`);
    return dispatch({ type, ...args });
  };
};

有了這個思路,就來實現這個 mini-redux 吧:

function compose(...funcs) {
  return funcs.reduce((a, b) => (...args) => a(b(...args)));
}

function createStore(reducer, middlewares) {
  let currentState;

  function dispatch(action) {
    currentState = reducer(currentState, action);
  }

  function getState() {
    return currentState;
  }
  // 初始化一個隨意的dispatch,要求外部在type匹配不到的時候返回初始狀態
  // 在這個dispatch后 currentState就有值了。
  dispatch({ type: "INIT" });

  let enhancedDispatch = dispatch;
  // 如果第二個參數傳入了middlewares
  if (middlewares) {
    // 用compose把middlewares包裝成一個函數
    // 讓dis
    enhancedDispatch = compose(...middlewares)(dispatch);
  }

  return {
    dispatch: enhancedDispatch,
    getState
  };
}

接著寫兩個中間件

// 使用

const otherDummyMiddleware = dispatch => {
  // 返回一個新的dispatch
  return action => {
    console.log(`type in dummy is ${type}`);
    return dispatch(action);
  };
};

// 這個dispatch其實是otherDummyMiddleware執行后返回otherDummyDispatch
const typeLogMiddleware = dispatch => {
  // 返回一個新的dispatch
  return ({ 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方法:

function composeMiddlewares(middlewares) {
  return function wrapMiddlewares(ctx) {
    // 記錄當前運行的middleware的下標
    let index = -1;
    function dispatch(i) {
      // index向后移動
      index = i;

      // 找出數組中存放的相應的中間件
      const fn = middlewares[i];

      // 最后一個中間件調用next 也不會報錯
      if (!fn) {
        return Promise.resolve();
      }

      return Promise.resolve(
        fn(
          // 繼續傳遞ctx
          ctx,
          // next方法,允許進入下一個中間件。
          () => dispatch(i + 1)
        )
      );
    }
    // 開始運行第一個中間件
    return dispatch(0);
  };
}

簡單來說 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;
  await next();
});

在這一層把 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 res of ssh...
res is {"code":200,"result":"req ssh success"}

總結

  1. axios 把用戶注冊的每個攔截器構造成一個 promise.then 所接受的參數,在運行時把所有的攔截器按照一個 promise 鏈的形式以此執行。
  • 在發送到服務端之前,config 已經是請求攔截器處理過后的結果
  • 服務器響應結果后,response 會經過響應攔截器,最后用戶拿到的就是處理過后的結果了。
  1. vuex的實現最為簡單,就是提供了兩個回調函數,vuex 內部在合適的時機去調用(我個人感覺大部分的庫提供這樣的機制也足夠了)。
  2. redux的源碼里寫的最復雜最繞,它的中間件機制本質上就是用高階函數不斷的把 dispatch 包裝再包裝,形成套娃。本文實現的已經是精簡了 n 倍以后的結果了,不過復雜的實現也是為了很多權衡和考量,Dan 對于閉包和高階函數的運用已經爐火純青了,只是外人去看源碼有點頭禿...
  3. koa的洋蔥模型實現的很精妙,和 redux 有相似之處,但是在源碼理解和使用上個人感覺更優于 redux 的中間件。

中間件機制其實是非框架強相關的,請求庫一樣可以加入 koa 的洋蔥中間件機制(如 umi-request),不同的框架可能適合不同的中間件機制,這還是取決于你編寫的框架想要解決什么問題,想給用戶什么樣的自由度。

希望看了這篇文章的你,能對于前端庫中的中間件機制有進一步的了解,進而為你自己的前端庫加入合適的中間件能力。

本文所寫的代碼都整理在這個倉庫里了: https://github.com/sl1673495/tiny-middlewares

代碼是使用 ts 編寫的,js 版本的代碼在 js 文件夾內,各位可以按自己的需求來看。


https://mp.weixin.qq.com/s/V9IrtLA4CW5jnUO-YKzXLg

Vue 新玩具 VueUse

發布于:6月以前  |  371次閱讀  |  詳細內容 ?

從 Vuex 出發,全方位解讀狀態管理全貌

發布于:6月以前  |  333次閱讀  |  詳細內容 ?

60個Vue常見問題匯總及解決方案

發布于:6月以前  |  335次閱讀  |  詳細內容 ?

9個值得推薦的 VUE3 UI 框架

發布于:6月以前  |  495次閱讀  |  詳細內容 ?

史上最全 Vue 前端代碼風格指南

發布于:6月以前  |  323次閱讀  |  詳細內容 ?

Vue3的7種和Vue2的12種組件通信

發布于:6月以前  |  382次閱讀  |  詳細內容 ?

深入淺出 Vue 中的模板編譯

發布于:6月以前  |  321次閱讀  |  詳細內容 ?

深入淺出 Vue 響應式原理源碼剖析

發布于:6月以前  |  284次閱讀  |  詳細內容 ?

Vue 的完整生命周期源碼流程詳解

發布于:6月以前  |  297次閱讀  |  詳細內容 ?

12 個 Vue 開發中的性能優化小技巧

發布于:6月以前  |  343次閱讀  |  詳細內容 ?

一次弄懂 Vue2 和 Vue3 的 nextTick 實現原理

發布于:6月以前  |  398次閱讀  |  詳細內容 ?

10 個 Vue3 精華知識點,你知道幾個?

發布于:6月以前  |  294次閱讀  |  詳細內容 ?

聊聊vue中的keep-alive

發布于:7月以前  |  390次閱讀  |  詳細內容 ?

萬萬沒想到,Vue3 的 setup 還能這么玩

發布于:7月以前  |  328次閱讀  |  詳細內容 ?

20 個頂級的 Vue 組件庫

發布于:7月以前  |  460次閱讀  |  詳細內容 ?

【Vuejs】1148- 關于Vue3實踐的一些問題清單

發布于:7月以前  |  360次閱讀  |  詳細內容 ?

所屬標簽

最多閱讀

iOS 性能檢測新方式?——AnimationHitches 8月以前  |  18061次閱讀
快速配置 Sign In with Apple 2年以前  |  5484次閱讀
APP適配iOS11 3年以前  |  4436次閱讀
App Store 審核指南[2017年最新版本] 3年以前  |  4262次閱讀
所有iPhone設備尺寸匯總 3年以前  |  4184次閱讀
使用 GPUImage 實現一個簡單相機 3年以前  |  3916次閱讀
開篇 關于iOS越獄開發 3年以前  |  3794次閱讀
在越獄的iPhone設置上使用lldb調試 3年以前  |  3719次閱讀
給數組NSMutableArray排序 3年以前  |  3642次閱讀
使用ssh訪問越獄iPhone的兩種方式 3年以前  |  3346次閱讀
UITableViewCell高亮效果實現 3年以前  |  3344次閱讀
關于Xcode不能打印崩潰日志 3年以前  |  3242次閱讀
使用ssh 訪問越獄iPhone的兩種方式 3年以前  |  3083次閱讀
為對象添加一個釋放時觸發的block 3年以前  |  2857次閱讀
使用最高權限操作iPhone手機 3年以前  |  2828次閱讀

手機掃碼閱讀
18禁止午夜福利体验区,人与动人物xxxx毛片人与狍,色男人窝网站聚色窝
<蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>