koa redux middleware 深入解析

對於現有的一些框架比如koa，express，redux，都需要對資料流進行一些處理，比如koa，express的請求資料處理，包括json.stringify，logger，或者一些安全相關的處理都需要在資料流中進行，還比如redux的整個資料的修改，支援中介軟體來擴充套件使用者對於資料修改的支援。

middleware系統是處理流式資料的利器，實現方便，功能強大。

本文就分別研究一下redux的koa的middleware系統～

對於redux，乙個資料處理中心，它的用法想必大家已經很熟了。

import thunk from
"redux-thunk"
;import
from
"redux"
;const createstorewithmiddleware =

我們直接上redux原始碼：

function
for (var _len =
arguments.length
, middlewares =
array(_len), _key =
0; _key < _len; _key++) 
return
function (createstore) 
}; chain =
middlewares.map(function (middleware) );
, chain)(store.dispatch);
//相當於compose(...chain)(store.dispatch)
return
_extends({}, store,
);};
};}

我們用thunk來具體講一下流程。

thunk的原始碼是：

function
createthunkmiddleware(extraargument) ) => next => action =>
return
next(action);};}
const thunk =
createthunkmiddleware();
thunk.withextraargument
= createthunkmiddleware;
export
default thunk;

實際我們引入過來在redux原始碼裡的就是

() => next => action =>
return
next(action);
};

之間通過chain處理過middlmiddleware，所以chain裡的各個middleware其實是這樣的：

next => action =>
return
next(action);
};

根據compose的作用，我們實際獲得的_dispatch是這樣的：

如果只有乙個middleware，我們傳進來store.dispatch，那麼_dispatch為：

action =>
return
dispatch(action);
};

如果有兩個middleware（我們實際在演示compose的處理），我們得到的其實是。。。之前我們先簡化一下middleware：

function
middleware(next)
}}

第二個middleware傳進來我們得到的是：

function ()
})(action)}}}

第三個middleware:

function ()
})(action)
// *** 1
})(action)}}}

我們會發現，_dispatch觸發之後，需要經過各個自執行的中介軟體。

我們還會發現，我們的執行順序是根據compose的執行順序來的，但是在中介軟體呼叫之後並不會返回，我們還會執行next之後的『***』**。而它的**順序是相反的。

但是我們並不會在next之後執行命令阿？我們的規範也都是以next結尾。

原因？next的後的**其實是可以用的，但是有一點問題就是還是執行順序的問題，如果某個中介軟體是非同步執行，執行順序就無法保證了。

這個情況一直持續到es6 generator函式的出現。。。

對於koa，1.x的時候支援了generator，現在支援了async函式，所以現在的koa的中介軟體系統是「洋蔥圈」式的處理方式，也就是上面的先執行每個中介軟體的before，再倒敘執行***函式。

有個圖直觀的感受一下：

所有的請求經過乙個中介軟體的時候都會執行兩次。

因為koa的每個middleware是無關的，所以我們並不需要像redux的compose一樣用reduceright實現，它的compose實現一會再談，先談一下middleware的工作流程吧。（redux的compose實現之前博文有講）

;我們構建乙個服務，請求來的時候傳入乙個上下文環境給中介軟體，然後請求通過中介軟體處理。

koa的中介軟體形式就是圖上那種的格式，我這裡只講一下最新的async的處理模式吧，因為此原始碼是基於aysnc的處理。

舉個middleware的例子：

async function
middleware(ctx, next)

function
compose (middleware) 
/*** 
@param
context
* @return
* @apipublic
*/return
function (context, next) ))
}catch (err) }}
}

這個compose比較簡單，因為元件間的關聯從返回值變成了context。koa之間中介軟體的聯絡應該就是乙個全域性通用的context引數了。也是koa推薦寫法。

這個compose就是遞迴呼叫所有的middleware。

值得一提的點就是koa為async函式特製的compose函式，async函式的awiat需要每次非同步都是乙個promise，如果為值，那就是同步處理。所以返回的middleware都被包了一層promise.resolve。

它的處理過程就是：

乙個middleware:

async function
middleware(ctx, next)

兩個middleware：

async function
middleware(ctx, next)

next之後的***函式的呼叫順序保證得益於async的函式執行順序。且把await看做then的語法糖。

比較方便的一點就是在try裡面，所有中介軟體的reject都會被catch到，這得益於與promise的乙個特性：

如果resolve的引數是promise物件，則該物件最終的[[promisevalue]]會傳遞給外層promise物件後續的then的onfulfilled/onrejected

// middleware/onerror.js
// global error handling for middlewares
module.exports
=async (ctx, next) =>
catch (err) );
ctx.body
= errbody;
}};

middleware的好處就不提了。

只說一下koa的這種實現的兩個好處：

koa redux middleware 深入解析

JavaScript ECMA 262 深入解析

閉式解解析解

深入淺出學演算法008 求佩爾方程的解

koa redux middleware 深入解析

JavaScript ECMA 262 深入解析

閉式解 解析解

深入淺出學演算法008 求佩爾方程的解

相關推薦

閉式解解析解