前端中的庫不少,開發這些庫的做者會盡量的覆蓋到你們在業務中千奇百怪的需求,可是總有沒法預料到的,因此優秀的庫就須要提供一種機制,讓開發者能夠干預插件中間的一些環節,從而完成本身的一些需求。前端
本文將從koa
、axios
、vuex
和redux
的實現來教你怎麼編寫屬於本身的插件機制。vue
對於新手來講:
本文能讓你搞明白神祕的插件和攔截器究竟是什麼東西。ios
對於老手來講:
在你寫的開源框架中也加入攔截器或者插件機制,讓它變得更增強大吧!git
首先咱們模擬一個簡單的 axios,這裏不涉及請求的邏輯,只是簡單的返回一個 Promise,能夠經過 config 中的 error 參數控制 Promise 的狀態。github
axios 的攔截器機制用流程圖來表示其實就是這樣的:vuex
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 官方提供的攔截器示例:redux
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 的攔截求,都會接受兩個函數做爲參數,一個是用來處理正常流程,一個是處理失敗流程,這讓人想到了什麼?axios
沒錯,promise.then
接受的一樣也是這兩個參數。api
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(); promise = promise.then(resolved, rejected); } // 最後暴露給用戶的就是響應攔截器處理事後的promise return promise; }; 複製代碼
從axios.run
這個函數看運行時的機制,首先構造一個chain
做爲 promise 鏈,而且把正常的請求也就是咱們的請求參數 axios 也構造爲一個攔截器的結構,接下來
chain
頂部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); } ); 複製代碼
在成功的調用下輸出 result1: extraParams1 extraParams2 message1
(async function() { const result = await axios.run({ message: "message1" }); console.log("result1: ", result); })(); 複製代碼
(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 提供了一個 api 用來在 action 被調用先後插入一些邏輯:
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 中的中間件機制,須要先理解一個方法: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 變得很是強大,本文也會實現一個簡單的洋蔥中間件機制。參考(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"} 複製代碼
axios
把用戶註冊的每一個攔截器構形成一個 promise.then 所接受的參數,在運行時把全部的攔截器按照一個 promise 鏈的形式以此執行。vuex
的實現最爲簡單,就是提供了兩個回調函數,vuex 內部在合適的時機去調用(我我的感受大部分的庫提供這樣的機制也足夠了)。redux
的源碼裏寫的最複雜最繞,它的中間件機制本質上就是用高階函數不斷的把 dispatch 包裝再包裝,造成套娃。本文實現的已是精簡了 n 倍之後的結果了,不過複雜的實現也是爲了不少權衡和考量,Dan 對於閉包和高階函數的運用已經爐火純青了,只是外人去看源碼有點頭禿...koa
的洋蔥模型實現的很精妙,和 redux 有類似之處,可是在源碼理解和使用上我的感受更優於 redux 的中間件。中間件機制實際上是非框架強相關的,請求庫同樣能夠加入 koa 的洋蔥中間件機制(如 umi-request),不一樣的框架可能適合不一樣的中間件機制,這仍是取決於你編寫的框架想要解決什麼問題,想給用戶什麼樣的自由度。
但願看了這篇文章的你,能對於前端庫中的中間件機制有進一步的瞭解,進而爲你本身的前端庫加入合適的中間件能力。
本文所寫的代碼都整理在這個倉庫裏了:
github.com/sl1673495/t…
代碼是使用 ts 編寫的,js 版本的代碼在 js 文件夾內,各位能夠按本身的需求來看。