異步處理方案系列- 1.callback

• 本篇博客還沒有上傳 github

• github 首頁(star+watch，一手動態直達)： github.com/HCThink/h-b…

• 掘金 link , 掘金 專欄

• segmentfault 主頁

原創禁止私自轉載

---

異步處理方案系列- 1.callback

引言

異步/異步操做，已是前端領域一個老生常談的話題.也是作前端開發中常常面臨的一個問題.

然而異步的問題每每比較複雜且難於處理, 特別是異步問題還常常不是單獨出現,每每存在比較多樣的組合關係.

在實際處理中就顯得更加複雜而難於處理. 特別是在 io 操做頻繁，或者 node server 中，常常遇到很是複雜的組合型異步。

舉個業務開發中常見的例子:

eg: 省市縣三級級聯問題

這個問題很是常見, 假設數據量較大, 咱們大多數狀況下不會一次加載全部的數據, 而後作前端級聯的方案.

而是採起三個數據接口,在下拉改變的時候去動態請求的方式.這就造成一種很常見的多個異步串行的模型.

怎麼處理這樣的問題, 怎麼較好的維護多個異步之間的關係, 怎麼讓代碼正常執行的同時,在邏輯和結構上更可讀呢?

我將會梳理

• callback
• cps
• thunk
• defer / promise(非 es6)
• promise(ES6)
• generator -> co.
• async / await

這幾種處理方式. 加上兩種模式

• 事件監聽
• 訂閱發佈模型

列出一個系列的博客去討論這個問題. 看咱們在不一樣階段, 使用不一樣技術,如何處理相同的問題. 在不一樣方案之間橫向對比, 去深刻了解 技術變遷以及背後的處理思路和邏輯的變化.

callback

什麼是回調呢? 這麼問彷佛有點多餘, 每一個寫過 javascript 的開發者, 或多或少都會接觸到回調. 回調的使用成本很低, 實現回調函數就像傳遞通常的參數變量同樣簡單.因爲函數式編程極好的支持,以致於這項技術使用基本沒有障礙.咱們隨手就能寫出一個回調

Ajax.get('http://xxxx', {}, (resp) => {
    // .....
})
複製代碼

可是呢,要真給回調下一個定義, 也還真很差回答.

咱們不妨從一些側面去看看回調

• 回調是一種處理特定問題的模式, 伴隨着函數式編程而生. 函數式編程中很重要的技術之一就是回調函數
• 當一個函數做爲主調函數的參數時, 它每每會在特定的時間和場景(上下文)中執行.
• 執行過程當中,回調函數選擇性接收函數內部的數據, 或者狀態(內存), 通過處理選擇性返回,或者改變狀態（hock）.

callback 業務模型

說這麼多, 咱們不如從代碼的角度去解決一個串行的異步模型.

爲了說明問題, 咱們將問題簡化成 A B C 三個異步(多是 io, 網絡請求, 或者其餘.爲了方面描述, 咱們採用 settimeout 來模擬), 這三個異步耗時不肯定, 可是必須按照 A B C 的順序處理他們的返回結果.

處理這個問題, 咱們基本上有兩種思路:

1. 控制異步發出的順序, 在 a 返回以後再發 b 請求, 這樣將問題串行化(省市縣模型中常常須要省的返回值去請求省所對應的市).
2. 同時發出異步請求,控制處理的順序.

方案一: 串行化請求

// 模擬 ajax 函數
function ajax(url) {
    return function (cb) {
        setTimeout(function() {
            cb({
                url
            });
        }, Math.random() * 3000);
    }
}

// 初始化出三個請求
const A = ajax('/ofo/a');
const B = ajax('/ofo/b');
const C = ajax('/ofo/c');

// 控制請求順序
log('ajax A send...');
A(function (a) {
    log('ajax A receive...');

    log('ajax B send...');
    B(function (b) {
        log('ajax B receive...');

        log('ajax C send...');
        C(function (C) {
            log('ajax C receive...');
        });
    })
})
複製代碼

代碼很簡單, 大可能是方案也是這麼走的, 由於 A 的返回值能夠做爲 B 的參數. 可是相應的這個模式的總時間一定大於三個請求的時間之和.輸出以下:

ajax A send...
ajax A receive...
ajax B send...
ajax B receive...
ajax C send...
ajax C receive...
複製代碼

方案二: 自由請求,串行化處理

是相對不那麼通用的方案, 可是處理沒有直接數據依賴的串行請求很是合適.

// 發送容器
const sender = [];
// 稍做改造
function ajax(url, time) {
    return function(cb) {
        // 記錄發送順序, 必須有序
        sender.push(url);
        setTimeout(function() {
            const data = {
                from: url,
                reso: 'ok'
            };

            // 將 data, 回調傳遞給一個處理函數
            dealReceive({url, cb, data});
        }, time);
    }
}


// 按照順序處理返回結果

// 返回結果容器
const receiver = {};
function dealReceive({url, cb, data}) {
    // 記錄返回結果.能夠無序
    receiver[url] = {cb, data};
    for (var i = 0; i < sender.length; i++) {
        let operate = receiver[sender[i]];
        if(typeof operate === 'object') {

            operate.cb.call(null, operate.data);
        } else {
            return;
        }
    }
}

// 手動模擬出請求時間, A 最耗時.b 最快, 更好說明問題
const A = ajax('/ofo/a', 4000);
const B = ajax('/ofo/b', 600);
const C = ajax('/ofo/c', 2000);


// 注意咱們的調用方式 是沒有任何控制的
// A,B,C 依次發出. 還能夠按照這個順序處理 A,B,C 的返回值
A(function (a) {
    log(a);
});

B(function (b) {
    log(b);
});

C(function (c) {
    log(c);
});

複製代碼

輸出:

{"from":"/ofo/a","reso":"ok"}
{"from":"/ofo/b","reso":"ok"}
{"from":"/ofo/c","reso":"ok"}
複製代碼

這種方案總耗時基本上是耗時最長的 ajax 的耗時。

值得注意的是, A,B,C 的調用上沒有作任何控制. A 最耗時, 可是要最最早處理 A 的返回數據. 實現這一點的關鍵就在於咱們 dealReceive 有個輪詢, 這個輪詢不是定時觸發的,而是每當請求回來時, 觸發輪詢. 整個過程輪詢 3 次.

基本上 callback 處理組合異步模型的思路說完了.串行是容易處理的一種模型, 若是出現 c 依賴 a,b 都正確返回的模型時, 基本上咱們暴力一點就是轉化爲串行關係. 儘管 a, b 沒有關係. 或者呢咱們就在 a, b 的回調裏作標誌位. 和 dealReceive 相似.

單個異步不須要有太多處理, callback 的一些細節也不作討論. 主要討論是回調在實際場景中的處理問題方案

回調兩面性

咱們仍是落入俗套的分析一下回調的優缺點.其實主要是缺點.

• 優勢: 使用成本低, 處理簡單問題很是方便.可以拿到主調函數內部的環境.等等.
• 大多數人認爲的缺點:

1. 回調很 low: 多是由於, 實現回調函數就像傳遞通常的參數變量同樣簡單.因爲函數式編程極好的支持,以致於這項技術使用基本沒有障礙.也沒有比較嚴格的模式要求.你們習覺得常了.
2. 回調地獄(代碼橫向發展): 其實這並非回調的錯. 當咱們遇到回調無底洞的時候，也無需驚慌,其實這根本不是什麼問題, 由於一樣有協程和 monad 無底洞。由於若是你把任何一個抽象使用地足夠頻繁的話，都一樣會創造一個無底洞。

使用回調上的建議: 沒有使用障礙致使回調的濫用, 大部分問題都用了簡單的回調堆疊來解決. 實際上咱們有不少基於回調的模式能夠避免這些問題.好比: cps, cps 進一步轉化爲 thunk.等等.

這樣看來, 回調沒有缺點, 是這樣麼? 不是的. 回調有很是致命的機制上的缺點, 這個問題可能在 node 中爆發，除非自身改變，或者被吃掉。

所謂的機制就是：你可能在用回調處理複雜問題的時候,對本身能力產生懷疑,這些異步之間的關係是那麼難以梳理清晰,而又難以寫出容易維護的代碼.

其實這都不是你的錯.

• 使用回調處理異步每每意味着,你捨棄了返回值,而使用回調接收異步操做結果. 而這正是用回調風格來編程會很困難的根本緣由: 回調風格不返回任何值，因此難以組合[函數式編程中函數有良好的輸入和輸出是函數能夠組合的根本]。
• 一個沒有返回值的函數執行的效果實際上是利用它的反作用
• 一個沒有返回值和利用反作用的函數其實就是一個黑洞。
• 因此，使用回調風格來編程沒法避免會是指令式的，它其實是經過把一系列嚴重依賴於反作用的操做安排好執行順序，而不是經過函數的調用來把輸入輸出值對應好。若是你是經過回調組織程序執行流程, 而不是靠理順值的關係來解決問題的, 是很難編寫出正確的並行程序
• 這種問題也間接的致使了回調難於調試,定位問題和維護.

最終的結果就是: 你崩潰了

注：系列博客陸續推出，稍安勿躁。