前言
前端中的庫很多,開發這些庫的作者會盡可能的覆蓋到大家在業務中千奇百怪的需求,但是總有無法預料到的,所以優秀的庫就需要提供一種機制,讓開發者可以干預外掛中間的一些環節,從而完成自己的一些需求。
本文將從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();
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)
},
);
複製程式碼
- 成功的呼叫
在成功的呼叫下輸出 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
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
想要理解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"}
複製程式碼
總結
axios
把使用者註冊的每個攔截器構造成一個promise.then所接受的引數,在執行時把所有的攔截器按照一個promise鏈的形式以此執行。
- 在傳送到服務端之前,config已經是請求攔截器處理過後的結果
- 伺服器響應結果後,response會經過響應攔截器,最後使用者拿到的就是處理過後的結果了。
vuex
的實現最為簡單,就是提供了兩個回撥函式,vuex內部在合適的時機去呼叫(我個人感覺大部分的庫提供這樣的機制也足夠了)。redux
的原始碼裡寫的最複雜最繞,它的中介軟體機制本質上就是用高階函式不斷的把dispatch包裝再包裝,形成套娃。本文實現的已經是精簡了n倍以後的結果了,不過複雜的實現也是為了很多權衡和考量,Dan對於閉包和高階函式的運用已經爐火純青了,只是外人去看原始碼有點頭禿...koa
的洋蔥模型實現的很精妙,和redux有相似之處,但是在原始碼理解和使用上個人感覺更優於redux的中介軟體。
中介軟體機制其實是非框架強相關的,請求庫一樣可以加入koa的洋蔥中介軟體機制(如umi-request),不同的框架可能適合不同的中介軟體機制,這還是取決於你編寫的框架想要解決什麼問題,想給使用者什麼樣的自由度。
希望看了這篇文章的你,能對於前端庫中的中介軟體機制有進一步的瞭解,進而為你自己的前端庫加入合適的中介軟體能力。
本文所寫的程式碼都整理在這個倉庫裡了:
github.com/sl1673495/t…
程式碼是使用ts編寫的,js版本的程式碼在js資料夾內,各位可以按自己的需求來看。