摘要:異步編程解決方案筆記最近讀了樸靈老師的深入淺出中異步編程一章,并參考了一些有趣的文章。另外回調函數中的也失去了意義,這會使我們的程序必須依賴于副作用。
JavaScript 異步編程解決方案筆記
最近讀了樸靈老師的《深入淺出NodeJS》中《異步編程》一章,并參考了一些有趣的文章。
在此做個筆記,記錄并鞏固學到的知識。
異步I/O、事件驅動使得單線程的JavaScript得以在不阻塞UI的情況下執行網絡、文件訪問功能,
且使之在后端實現了較高的性能。然而異步風格也引來了一些麻煩,其中比較核心的問題是:
函數嵌套過深
JavaScript的異步調用基于回調函數,當多個異步事務多級依賴時,回調函數會形成多級的嵌套,代碼變成
金字塔型結構。這不僅使得代碼變難看難懂,更使得調試、重構的過程充滿風險。
異常處理
回調嵌套不僅僅是使代碼變得雜亂,也使得錯誤處理更復雜。
異步編程中可能拋出錯誤的情況有兩種:
異步函數錯誤
由于異步函數是立刻返回的,異步事務中發生的錯誤是無法通過try-catch來捕捉的,只能采用由調用方提供錯誤處理回調的方案來解決。
例如Node中常見的function (err, ...) {...}回調函數,就是Node中處理錯誤的約定:
即將錯誤作為回調函數的第一個實參返回。
再比如HTML5中FileReader對象的onerror函數,會被用于處理異步讀取文件過程中的錯誤。
回調函數錯誤
由于回調函數執行時,異步函數的上下文已經不存在了,通過try-catch無法捕捉回調函數內的錯誤。
可見,異步回調編程風格基本上廢掉了try-catch和throw。另外回調函數中的return也失去了意義,這會使我們的程序必須依賴于副作用。
這使得JavaScript的三個語義失效,同時又得引入新的錯誤處理方案,如果沒有像Node那樣統一的錯誤處理約定,問題會變得更加麻煩。
下面對幾種解決方案的討論主要集中于上面提到的兩個核心問題上,當然也會考慮其他方面的因素來評判其優缺點。
Async.js首先是Node中非常著名的Async.js,這個庫能夠在Node中展露頭角,恐怕也得歸功于Node統一的錯誤處理約定。
而在前端,一開始并沒有形成這么統一的約定,因此使用Async.js的話可能需要對現有的庫進行封裝。
Async.js的其實就是給回調函數的幾種常見使用模式加了一層包裝。比如我們需要三個前后依賴的異步操作,采用純回調函數寫法如下:
asyncOpA(a, b, (err, result) => { if (err) { handleErrorA(err); } asyncOpB(c, result, (err, result) => { if (err) { handleErrorB(err); } asyncOpB(d, result, (err, result) => { if (err) { handlerErrorC(err); } finalOp(result); }); }); });
如果我們采用async庫來做:
async.waterfall([ (cb) => { asyncOpA(a, b, (err, result) => { cb(err, c, result); }); }, (c, lastResult, cb) => { asyncOpB(c, lastResult, (err, result) => { cb(err, d, result); }) }, (d, lastResult, cb) => { asyncOpC(d, lastResult, (err, result) => { cb(err, result); }); } ], (err, finalResult) => { if (err) { handlerError(err); } finalOp(finalResult); });
可以看到,回調函數由原來的橫向發展轉變為縱向發展,同時錯誤被統一傳遞到最后的處理函數中。
其原理是,將函數數組中的后一個函數包裝后作為前一個函數的末參數cb傳入,同時要求:
每一個函數都應當執行其cb參數;
cb的第一個參數用來傳遞錯誤。
我們可以自己寫一個async.waterfall的實現:
let async = { waterfall: (methods, finalCb = _emptyFunction) => { if (!_isArray(methods)) { return finalCb(new Error("First argument to waterfall must be an array of functions")); } if (!methods.length) { return finalCb(); } function wrap(n) { if (n === methods.length) { return finalCb; } return function (err, ...args) { if (err) { return finalCb(err); } methods[n](...args, wrap(n + 1)); } } wrap(0)(false); } };
Async.js還有series/parallel/whilst等多種流程控制方法,來實現常見的異步協作。
Async.js的問題是:
在外在上依然沒有擺脫回調函數,只是將其從橫向發展變為縱向,還是需要程序員熟練異步回調風格。
錯誤處理上仍然沒有利用上try-catch和throw,依賴于“回調函數的第一個參數用來傳遞錯誤”這樣的一個約定。
Promise方案ES6的Promise來源于Promise/A+。使用Promise來進行異步流程控制,有幾個需要注意的問題,
在We have a problem with promises一文中有很好的總結。
把前面提到的功能用Promise來實現,需要先包裝異步函數,使之能返回一個Promise:
function toPromiseStyle(fn) { return (...args) => { return new Promise((resolve, reject) => { fn(...args, (err, result) => { if (err) reject(err); resolve(result); }) }); }; }
這個函數可以把符合下述規則的異步函數轉換為返回Promise的函數:
回調函數的第一個參數用于傳遞錯誤,第二個參數用于傳遞正常的結果。
接著就可以進行操作了:
let [opA, opB, opC] = [asyncOpA, asyncOpB, asyncOpC].map((fn) => toPromiseStyle(fn)); opA(a, b) .then((res) => { return opB(c, res); }) .then((res) => { return opC(d, res); }) .then((res) => { return finalOp(res); }) .catch((err) => { handleError(err); });
通過Promise,原來明顯的異步回調函數風格顯得更像同步編程風格,我們只需要使用then方法將結果傳遞下去即可,同時return也有了相應的意義:
在每一個then的onFullfilled函數(以及onRejected)里的return,都會為下一個then的onFullfilled函數(以及onRejected)的參數設定好值。
如此一來,return、try-catch/throw都可以使用了,但catch是以方法的形式出現,還是不盡如人意。
Generator方案ES6引入的Generator可以理解為可在運行中轉移控制權給其他代碼,并在需要的時候返回繼續執行的函數。利用Generator可以實現協程的功能。
將Generator與Promise結合,可以進一步將異步代碼轉化為同步風格:
function* getResult() { let res, a, b, c, d; try { res = yield opA(a, b); res = yield opB(c, res); res = yield opC(d); return res; } catch (err) { return handleError(err); } }
然而我們還需要一個可以自動運行Generator的函數:
function spawn(genF, ...args) { return new Promise((resolve, reject) => { let gen = genF(...args); function next(fn) { try { let r = fn(); if (r.done) { resolve(r.value); } Promise.resolve(r.value) .then((v) => { next(() => { return gen.next(v); }); }).catch((err) => { next(() => { return gen.throw(err); }) }); } catch (err) { reject(err); } } next(() => { return gen.next(undefined); }); }); }
用這個函數來調用Generator即可:
spawn(getResult) .then((res) => { finalOp(res); }) .catch((err) => { handleFinalOpError(err); });
可見try-catch和return實際上已經以其原本面貌回到了代碼中,在代碼形式上也已經看不到異步風格的痕跡。
類似的功能有co/task.js等庫實現。
ES7的async/awaitES7中將會引入async function和await關鍵字,利用這個功能,我們可以輕松寫出同步風格的代碼,
同時依然可以利用原有的異步I/O機制。
采用async function,我們可以將之前的代碼寫成這樣:
async function getResult() { let res, a, b, c, d; try { res = await opA(a, b); res = await opB(c, res); res = await opC(d); return res; } catch (err) { return handleError(err); } } getResult();
和Generator & Promise方案看起來沒有太大區別,只是關鍵字換了換。
實際上async function就是對Generator方案的一個官方認可,將之作為語言內置功能。
async function的缺點是:
await只能在async function內部使用,因此一旦你寫了幾個async function,
或者使用了依賴于async function的庫,那你很可能會需要更多的async function。
目前處于提案階段的async function還沒有得到任何瀏覽器或Node.JS/io.js的支持。
Babel轉碼器也需要打開實驗選項,并且對于不支持Generator的瀏覽器來說,
還需要引進一層厚厚的regenerator runtime,想在前端生產環境得到應用還需要時間。
1. A Study on Solving Callbacks with JavaScript Generators
2. Async Functions
3. 異步操作
4. Promise - JavaScript MDN
5. We have a problem with promises
6. Taming the asynchronous beast with ES7
7. Managing Node.js Callback Hell
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/85897.html
摘要:從最開始的到封裝后的都在試圖解決異步編程過程中的問題。為了讓編程更美好,我們就需要引入來降低異步編程的復雜性。異步編程入門的全稱是前端經典面試題從輸入到頁面加載發生了什么這是一篇開發的科普類文章,涉及到優化等多個方面。 TypeScript 入門教程 從 JavaScript 程序員的角度總結思考,循序漸進的理解 TypeScript。 網絡基礎知識之 HTTP 協議 詳細介紹 HTT...
摘要:異步請求線程在在連接后是通過瀏覽器新開一個線程請求將檢測到狀態變更時,如果設置有回調函數,異步線程就產生狀態變更事件,將這個回調再放入事件循環隊列中。 基礎:瀏覽器 -- 多進程,每個tab頁獨立一個瀏覽器渲染進程(瀏覽器內核) 每個瀏覽器渲染進程是多線程的,主要包括:GUI渲染線程 JS引擎線程 也稱為JS內核,負責處理Javascript腳本程序。(例如V8引擎) JS引擎線程負...
摘要:回調函數模式類似于事件模型,因為異步代碼也會在后面的一個時間點才執行如果回調過多,會陷入回調地獄基礎可以當做是一個占位符,表示異步操作的執行結果。函數可以返回一個,而不必訂閱一個事件或者向函數傳遞一個回調函數。 主要知識點:Promise生命周期、Promise基本操作、Promise鏈、響應多個Promise以及集成PromiseshowImg(https://segmentfaul...
摘要:為什么要異步編程我們在寫前端代碼時,經常會對做事件處理操作,比如點擊激活焦點失去焦點等再比如我們用請求數據,使用回調函數獲取返回值。這些都屬于異步編程。回調有多個狀態,當響應成功和失敗都有不同的回調函數。 為什么要異步編程 我們在寫前端代碼時,經常會對dom做事件處理操作,比如點擊、激活焦點、失去焦點等;再比如我們用ajax請求數據,使用回調函數獲取返回值。這些都屬于異步編程。 也許你...
閱讀 1765·2021-09-22 15:10
閱讀 1261·2021-09-07 09:58
閱讀 2333·2019-08-30 15:44
閱讀 1635·2019-08-26 18:29
閱讀 2033·2019-08-26 13:35
閱讀 759·2019-08-26 13:31
閱讀 720·2019-08-26 11:42
閱讀 1065·2019-08-23 18:39