摘要:于是抱著知其然也要知其所以然的想法,開始閱讀的源代碼。問題讀源代碼時,自然是帶著諸多問題的。源代碼如下在被處理完后,每當有新請求,便會調用,去處理請求。接下來會繼續(xù)寫一些閱讀筆記,因為看的源代碼確實是獲益匪淺。
起因本筆記共四篇
Koa源碼閱讀筆記(1) -- co
Koa源碼閱讀筆記(2) -- compose
Koa源碼閱讀筆記(3) -- 服務器の啟動與請求處理
Koa源碼閱讀筆記(4) -- ctx對象
自從寫了個Koa的腳手架koa2-easy,愈發(fā)覺得Koa的精妙。
于是抱著知其然也要知其所以然的想法,開始閱讀Koa的源代碼。
讀Koa源代碼時,自然是帶著諸多問題的。無論是上一篇所寫的generator函數(shù)如何自動執(zhí)行,還是對于Koa中間件如何加載,next參數(shù)如何來的。都充滿了好奇。
今天寫文章,并不是介紹整個koa-compose如何如何(涉及太寬,準備放在下面幾篇統(tǒng)一介紹)。而是從自身需求出發(fā),找到問題的答案。
而問題就是Koa中間件的加載,和next參數(shù)的來源。
首先的是Koa加載初始化時的函數(shù)(刪除部分):
// Koa類 function Application() { this.middleware = []; } // Koa原型 var app = Application.prototype; // Koa中間件加載函數(shù) app.use = function(fn){ if (!this.experimental) { // es7 async functions are not allowed, // so we have to make sure that `fn` is a generator function assert(fn && "GeneratorFunction" == fn.constructor.name, "app.use() requires a generator function"); } this.middleware.push(fn); return this; };
在這兒不難看出,Koa對象內部有個中間件的數(shù)組,其中所有中間件都會存在其中。
而在服務器啟動時,則會調用并處理該數(shù)組。
源代碼如下:
var co = require("co"); var compose = require("koa-compose"); var fn = co.wrap(compose(this.middleware))
在fn被處理完后,每當有新請求,便會調用fn,去處理請求。
而在這里,co.wrap的作用是返回一個Promise函數(shù),用于后續(xù)自動執(zhí)行generator函數(shù)。
于是不難看出,中間件這兒的重點,是compose函數(shù)。
而compose函數(shù)的源代碼雖然很簡潔,但是也很燒腦。(對我而言)
/** * Compose `middleware` returning * a fully valid middleware comprised * of all those which are passed. * * @param {Array} middleware * @return {Function} * @api public */ // 傳入中間件作為參數(shù) function compose(middleware){ return function *(next){ // next不存在時,調用一個空的generator函數(shù) if (!next) next = noop(); var i = middleware.length; // 倒序處理中間件,給每個中間件傳入next參數(shù) // 而next則是下一個中間件 while (i--) { next = middleware[i].call(this, next); } return yield *next; } } function *noop(){}
在這里,得提一提Koa中間件的調用方式。
app.use(function * (next) { this.set("Koa", "Example"); yield next; }) app.use(function * (next) { this.body = "Hello World" })
在中間件中的next,則是在koa-compose中傳入的。
而這兒, yield next 和 yield *next也是有區(qū)別的。
yield next, next 會作為next()的value返回。
而yield *next則是在generator函數(shù)內執(zhí)行這個generator函數(shù)。
這兩天一直在讀Koa的源代碼,細細看來不是很難,但是被作者的奇思妙想給打動了。
接下來會繼續(xù)寫一些閱讀筆記,因為看Koa的源代碼確實是獲益匪淺。
前端路漫漫,且行且歌
最后附上本人博客地址和原文鏈接,希望能與各位多多交流。
Lxxyx的前端樂園
原文鏈接:Koa源碼閱讀筆記(2) -- compose
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/90834.html
摘要:引言最近空閑時間讀了一下的源碼在閱讀的源碼的過程中,我的感受是代碼簡潔思路清晰不得不佩服大神的水平。調用的時候就跟有區(qū)別使用必須使用來調用除了上面的的構造函數(shù)外,還暴露了一些公用的,比如兩個常見的,一個是,一個是。 引言 最近空閑時間讀了一下Koa2的源碼;在閱讀Koa2(version 2.2.0)的源碼的過程中,我的感受是代碼簡潔、思路清晰(不得不佩服大神的水平)。下面是我讀完之后...
摘要:本筆記共四篇源碼閱讀筆記源碼閱讀筆記源碼閱讀筆記服務器啟動與請求處理源碼閱讀筆記對象起因前兩天閱讀了的基礎,和中間件的基礎。的前端樂園原文鏈接源碼閱讀筆記服務器啟動與請求處理 本筆記共四篇Koa源碼閱讀筆記(1) -- coKoa源碼閱讀筆記(2) -- composeKoa源碼閱讀筆記(3) -- 服務器の啟動與請求處理Koa源碼閱讀筆記(4) -- ctx對象 起因 前兩天閱讀了K...
摘要:本筆記共四篇源碼閱讀筆記源碼閱讀筆記源碼閱讀筆記服務器啟動與請求處理源碼閱讀筆記對象起因前兩天終于把自己一直想讀的源代碼讀了一遍。首先放上關鍵的源代碼在上一篇源碼閱讀筆記服務器啟動與請求處理中,我們已經分析了的作用。 本筆記共四篇Koa源碼閱讀筆記(1) -- coKoa源碼閱讀筆記(2) -- composeKoa源碼閱讀筆記(3) -- 服務器の啟動與請求處理Koa源碼閱讀筆記(4...
摘要:從一個對象里面提取需要的屬性這篇文章一直想寫了還想起那一夜我看到白天的代碼,實在太美了。 koa源碼lib主要文件有 application.js context.js request.js response.js application.js koa主要的邏輯處理代碼整個koa的處理 context.js 將req,res方法 掛載在這,生成ctx上下文對象 requests....
摘要:接上次挖的坑,對相關的源碼進行分析第一篇。和同為一批人進行開發(fā),與相比,顯得非常的迷你。在接收到一個請求后,會拿之前提到的與來創(chuàng)建本次請求所使用的上下文。以及如果沒有手動指定,會默認指定為。 接上次挖的坑,對koa2.x相關的源碼進行分析 第一篇。 不得不說,koa是一個很輕量、很優(yōu)雅的http框架,尤其是在2.x以后移除了co的引入,使其代碼變得更為清晰。 express和ko...
閱讀 1041·2019-08-30 12:57
閱讀 2114·2019-08-30 11:11
閱讀 2177·2019-08-29 15:20
閱讀 1870·2019-08-29 14:12
閱讀 3274·2019-08-28 17:51
閱讀 2378·2019-08-26 13:23
閱讀 789·2019-08-26 10:34
閱讀 3844·2019-08-23 12:37