Koa的洋蔥中介軟體，Redux的中介軟體，Axios的攔截器讓你迷惑嗎？實現一個精簡版的就徹底搞懂了。

晨曦時夢見兮發表於2020-01-07

ReduxiOS

前言

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

本文將從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被呼叫前後插入一些邏輯：

vuex.vuejs.org/zh/api/#sub…

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資料夾內，各位可以按自己的需求來看。

KOA2 compose 串聯中介軟體實現（洋蔥模型）
2018-10-10
模型
聊聊 Redux 和 Koa 的中介軟體
2019-03-04
Redux
徹底搞懂Scrapy的中介軟體（一）
2018-11-19
Redux 中介軟體的實現原理
2024-08-16
Redux
徹底搞懂Scrapy的中介軟體（二）
2018-11-20
徹底搞懂Scrapy的中介軟體（三）
2019-03-03
? ? ? 新鮮出爐！洋蔥模型的管道實現，你還在愁 go 沒有好用的中介軟體嗎？
2022-01-29
模型Go
redux, koa, express 中介軟體實現對比解析
2018-09-13
ReduxExpress
簡單介紹redux的中介軟體
2018-04-05
Redux
深入理解洋蔥模型中介軟體機制
2019-12-22
模型
如何更好地理解中介軟體和洋蔥模型
2020-11-10
模型
你知道 koa 中介軟體執行原理嗎?
2019-03-04
redux中介軟體
2019-03-01
Redux
Redux中介軟體對閉包的一個巧妙使用
2019-02-28
Redux
在 Golang 中實現一個簡單的Http中介軟體
2021-07-28
GolangHTTP
聊聊 koa 中介軟體
2018-07-31
koa，redux等主流框架的中介軟體設計思想原理分析
2019-03-03
Redux框架
理解Redux中介軟體
2019-03-03
Redux
redux中介軟體的原始碼的一些理解
2018-07-15
Redux原始碼
從原始碼理解Redux和Koa2的中介軟體機制
2018-05-15
原始碼Redux
Express, Koa, Redux中介軟體的區別,寫法和執行流程
2018-07-29
ExpressRedux
web前端技術分享：koa中介軟體是如何實現的？
2021-08-27
Web前端
從使用到原理，手擼一個自己的redux中介軟體
2018-08-09
Redux
Redux專題：中介軟體
2018-09-18
Redux
React+Redux+中介軟體
2018-06-04
ReactRedux
學習Koa - 讓我們寫一箇中介軟體
2018-04-08
學習Koa – 讓我們寫一箇中介軟體
2019-03-04
優雅的redux非同步中介軟體 redux-effect
2019-03-25
Redux非同步
寫一個簡易中介軟體
2018-10-18
redux中介軟體之redux-thunk
2018-04-16
Redux
【Koa】koa-compress中介軟體的使用-壓縮資料
2020-10-17
Koa 系列 —— Koa 中介軟體機制解析
2019-02-16
Redux的中介軟體Middleware不難，我信了^_^
2019-03-02
Redux
深入理解 Redux 中介軟體
2018-06-15
Redux
如何設計一個簡單的訊息中介軟體
2020-09-05
如何手寫一款KOA的中介軟體來實現斷點續傳
2018-09-02
斷點
用 Go 來實現 Koa 的洋蔥模型《Koa for Go》?
2021-01-25
Go模型
Koa2.0原始碼解析-中介軟體的設計
2018-07-18
原始碼

Koa的洋蔥中介軟體，Redux的中介軟體，Axios的攔截器讓你迷惑嗎？實現一個精簡版的就徹底搞懂了。

前言

axios

vuex

redux

koa

總結

相關文章