摘要：前言本文作者站在自己的角度深入淺出算了別這么裝逼分析在設(shè)計(jì)過(guò)程中通過(guò)構(gòu)建異步數(shù)據(jù)流的思路。看上去那是相當(dāng)?shù)耐昝溃鶕?jù)咱們寫(xiě)代碼的思路咱們來(lái)比對(duì)一下原版吧。時(shí)直接返回傳入函數(shù)函數(shù)。

本文作者站在自己的角度深入淺出...算了別這么裝逼分析 redux applyMiddleware 在設(shè)計(jì)過(guò)程中通過(guò) compose 構(gòu)建異步數(shù)據(jù)流的思路。自己假設(shè)的一些場(chǎng)景幫助理解，希望大家在有異步數(shù)據(jù)流并且使用redux的過(guò)程中能夠有自己的思路（脫離thunk or saga）構(gòu)建自己的 enhancer.如果你看完本文之后還想對(duì)我有更多的了解，可以移步我的github；

實(shí)際場(chǎng)景中遇到一個(gè)這樣的問(wèn)題：商品詳情頁(yè)的微信頁(yè)面，未注冊(cè)的用戶(hù)點(diǎn)擊購(gòu)買(mǎi)一個(gè)商品，我們希望能夠?qū)崿F(xiàn)靜默登錄就有如下幾個(gè)步驟：

獲取code；

獲取openId、AccessToken；

根據(jù)openId、獲取openId、AccessToken；獲取用戶(hù)信息實(shí)現(xiàn)自動(dòng)注冊(cè)然后登錄；

跳到商品購(gòu)買(mǎi)頁(yè)。

這是就是一個(gè)典型異步數(shù)據(jù)流的過(guò)程。在上一個(gè)函數(shù)執(zhí)行到某個(gè)時(shí)候再去調(diào)用下一個(gè)函數(shù)，使得這些個(gè)函數(shù)能夠順序執(zhí)行。我們簡(jiǎn)化一下，構(gòu)建如下的函數(shù)數(shù)組使得他們能夠順序執(zhí)行吧：

const fucArr = [
    next=>{
        setTimeout(()=>{
              console.log(1);
              next()
        }, 300)
    },
    next=>{
        setTimeout(()=>{
              console.log(2);
              next()
        }, 200)
      },
    next=>{
        setTimeout(()=>{
              console.log(3);
              next()
        }, 100)
    }
]

擼起袖子就開(kāi)始干了起來(lái)，有三個(gè)函數(shù)，基于走一步看一步思想（瞎胡說(shuō)的）那我就先執(zhí)行兩個(gè)吧

    fucArr[0]( fucArr[1] );// funcArr[1] 運(yùn)行報(bào)錯(cuò) TypeError: next is not a function

報(bào)錯(cuò)，因?yàn)?b>fucArr[1]中有next函數(shù)調(diào)用，也得接收一個(gè)函數(shù)，這下就麻煩了，fucArr[1]又不能直接傳參調(diào)用（因?yàn)闀?huì)比fucArr[0]先執(zhí)行），于是乎我們需要婉轉(zhuǎn)一點(diǎn)。

    fucArr[0]( ()=>fucArr[1](()=>{}) ); //1 2 

兩個(gè)函數(shù)順序執(zhí)行搞定了那三個(gè)函數(shù)豈不是，沒(méi)錯(cuò),小case。

    fucArr[0]( ()=>fucArr[1](()=>{ fucArr[2](()=>{}) }) );// 1 2 3

那我想在數(shù)組后面再加一個(gè)函數(shù)內(nèi)心os:不加，去死,這樣寫(xiě)下去真是要沒(méi)玩沒(méi)了了;

既然是個(gè)數(shù)組，那咱們就循環(huán)吧，思路肯定是：1.下個(gè)函數(shù)重新整合一下，作為參數(shù)往上一個(gè)函數(shù)傳；2.當(dāng)?shù)奖闅v到數(shù)組末尾的時(shí)候傳入一個(gè)空函數(shù)進(jìn)去避免報(bào)錯(cuò)。

OK開(kāi)始，既然是循環(huán)那就來(lái)個(gè)for循環(huán)吧，既然是下一個(gè)函數(shù)傳給上一個(gè)當(dāng)參數(shù)，得讓相鄰的兩個(gè)函數(shù)出現(xiàn)在同一個(gè)循環(huán)里啦。于是有了起手式：

    for (let index = 0; index < fucArr.length; index++) {
        const current = array[index];
        const next = array[index + 1];
        current(()=>next())
    }

起手后發(fā)現(xiàn)不對(duì)呀，我需要喝口熱水，壓壓驚，冷靜一下，仔細(xì)觀察一下上面咱們代碼的結(jié)構(gòu)發(fā)現(xiàn)咱們的函數(shù)結(jié)構(gòu)其實(shí)是醬紫的:

    a(()=>{
        b(c)
    })

實(shí)際就上上一個(gè)函數(shù)調(diào)用被 ()=> 包裹后的下一個(gè)函數(shù)直接調(diào)用并傳入一個(gè)函數(shù)c，而函數(shù)c會(huì)在函數(shù)b的運(yùn)行的某個(gè)時(shí)刻被調(diào)用，并且能接收下一個(gè)函數(shù)作為參數(shù)然后......再說(shuō)下去就沒(méi)玩沒(méi)了了，因此c函數(shù)的模式其實(shí)也是被一個(gè)()=>{}包裹住的函數(shù)；然后再觀察我們上面的模式?jīng)]有c傳遞，因此模式應(yīng)該是:

    a(c=>{
        b(c)
    })
    // 我們?cè)偻聦?xiě)一層
    a(
        d=>{
            (
                c=>b(c)
            )(
                d=>c(d)
            )// 為了避免你們看不懂我在寫(xiě)啥，我告訴你你，這玩意兒是函數(shù)自調(diào)用
        }
    )
    // 怎么樣是不是有一種豁然開(kāi)朗的趕腳

我們發(fā)現(xiàn)每次新加入一個(gè)函數(shù)，都是重新構(gòu)建一次a函數(shù)里的參數(shù)，以下我將這個(gè)參數(shù)簡(jiǎn)稱(chēng)函數(shù)d

于是乎我們來(lái)通過(guò)循環(huán)構(gòu)建這個(gè)d

為了讓循環(huán)體都能拿到d，因此它肯定是在循環(huán)的上層作用域

而且d具有兩個(gè)特性：

能接受一個(gè)函數(shù)作為參數(shù)，這個(gè)函數(shù)還能接收另一個(gè)函數(shù)作為參數(shù)，并會(huì)在某個(gè)時(shí)刻進(jìn)行調(diào)用

每次循環(huán)都會(huì)根據(jù)當(dāng)前d，然后加入當(dāng)前函數(shù)，按照相同模式進(jìn)行重構(gòu)；

ps: 我們發(fā)現(xiàn)這兩個(gè)特性其實(shí)和咱們傳入的每個(gè)函數(shù)特性是一致的。

   于是乎咱們把第一個(gè)數(shù)組的函數(shù)組作為起始函數(shù)：

    var statusRecord = fucArr[0];
    for (let index = 1; index < fucArr.length; index++) {
        statusRecord = next=>statusRecord(()=>fucArr[index](next))
    }

  寫(xiě)完發(fā)現(xiàn)這樣是錯(cuò)誤的，如果調(diào)用函數(shù)statusRecord那就會(huì)變成，自己調(diào)自己，自己調(diào)自己，自己調(diào)自己，自己調(diào)自己~~皮一下很開(kāi)心~~...的無(wú)限遞歸。
  在循環(huán)記錄當(dāng)前狀態(tài)的場(chǎng)景下，有一個(gè)經(jīng)典的demo大家了解過(guò)：在一個(gè)li列表中注冊(cè)點(diǎn)擊事件，點(diǎn)擊后alert出當(dāng)前index；具體就不詳述了于是statusRecord，就改寫(xiě)成了下面這樣

    statusRecord = ((statusRecord)=>(next)=>statusRecord(()=>fucArr[index](next))(statusRecord))

  為什么index不傳呢？因?yàn)閕ndex是let定義，可以看做塊級(jí)作用域，又有人要說(shuō)js沒(méi)有塊級(jí)作用域，我：你說(shuō)得對(duì)，再見(jiàn)。
  最后咱們得到的還是這個(gè)模型要調(diào)用，別忘了傳入一個(gè)函數(shù)功最后數(shù)組最后一個(gè)函數(shù)調(diào)用。不然會(huì)報(bào)錯(cuò)

    statusRecord(()=>{}) // 輸出1、2、3

那咱們的功能就此實(shí)現(xiàn)了；不過(guò)可以?xún)?yōu)化一哈。咱們上面的代碼有幾個(gè)要素:

數(shù)組循環(huán)

狀態(tài)傳遞

初始狀態(tài)為數(shù)組的第一個(gè)元素

最終需要拿到單一的返回值

不就是活脫脫用來(lái)描述reduce的嗎？于是乎我們可以這樣擼

    //pre 前一個(gè)狀態(tài)、 cur當(dāng)前循環(huán)函數(shù)、next 待接收的下一個(gè)
      fucArr.reduce((pre, cur)=>{
          return (next)=>pre(()=>cur(next))
      })(()=>{})// 1 2 3

   以上異步順序調(diào)用的問(wèn)題咱們已經(jīng)理解了，咱們依次輸出了1，2，3。但是咱們現(xiàn)實(shí)業(yè)務(wù)中常常是下一個(gè)函數(shù)執(zhí)行，和上一個(gè)函數(shù)執(zhí)行結(jié)果是關(guān)聯(lián)的。咱們就想能不能改動(dòng)題目貼合實(shí)際場(chǎng)景，上一個(gè)函數(shù)告訴下一個(gè)函數(shù)`console.log(n)`，于是乎題目做了一個(gè)小調(diào)整。

    const fucArr = [
        next=>{
            setTimeout(()=>{
                console.log(1);
                next(2)
            }, 300)
        },
        // 函數(shù)2
        (next,n)=>{
        console.log(n);
            next(3)
        },
        // 函數(shù)3
        (next,n)=>{
        console.log(n);
            next(4)
        }
    ]

    fucArr.reduce((pre,cur)=>{
        return (next)=>pre((n)=>cur(next,n))
    })((n)=>{console.log(n)})// 1 2 3 4

   哇，功能又實(shí)現(xiàn)了，我們真棒。現(xiàn)在我們來(lái)回憶一下redux里中間件里傳入函數(shù)格式

store=>next=>action=>{
    // dosomething...
    next()
}

    在某一步中store會(huì)被剝掉，在這就不細(xì)說(shuō)了，于是咱們題目再變個(gè)種

    const fucArr = [
        next=>n=>{
            setTimeout(()=>{
                console.log(n);
                next(n+1)
            }, 300)
        },
        // 函數(shù)2
        next=>n=>{
            setTimeout(()=>{
                console.log(n);
                next(n+1)
            }, 300)
        },
        // 函數(shù)3
        next=>n=>{
            setTimeout(()=>{
                console.log(n);
                next(n+1)
            }, 300)
        }
    ]

臥槽，我們發(fā)現(xiàn)之于之前遇到的問(wèn)題，這個(gè)實(shí)現(xiàn)就舒服很多了。因?yàn)槟銈魅氲暮瘮?shù)應(yīng)該是直接調(diào)用，因?yàn)槲覀冃枰恼{(diào)用的函數(shù)體其實(shí)是傳入函數(shù)調(diào)用后返回的那個(gè)函數(shù)，不需要我們通過(guò)()=>{...}這種額外的包裝。
于是咱們的實(shí)現(xiàn)就變成了：

    fucArr.reduce((pre,cur)=>{
        return (next)=>pre(cur(next))
    })((n)=>{console.log(n)})

我們自信滿(mǎn)滿(mǎn)的node xxx.js了一下發(fā)現(xiàn)?????what fuck 為啥什么都沒(méi)有輸出，喝第二口水壓壓驚分析一下：

    // before 之前的第一個(gè)函數(shù)和函數(shù)模型
    next=>{
        setTimeout(()=>{
            console.log(1);
            next(n+1)
        }, 300)
    }
    a(c=>{
        b(c)
    })

    // ------------
    // after 現(xiàn)在的第一個(gè)函數(shù)和函數(shù)模型
    next=>n=>{
        setTimeout(()=>{
            console.log(n);
            next(n+1)
        }, 300)
    }
    a(b(c))
    // 發(fā)現(xiàn)現(xiàn)在的第一個(gè)函數(shù)調(diào)用之后，一個(gè)函數(shù)。這個(gè)函數(shù)還要再接收一個(gè)參數(shù)去啟動(dòng)

(⊙v⊙)嗯沒(méi)錯(cuò)，經(jīng)過(guò)精妙的分析我知道要怎么做了。

    fucArr.reduce((pre,cur)=>{
        return (next)=>pre(cur(next))
    })((n)=>{console.log(n)})(1)// 1 2 3 4

我們來(lái)把這個(gè)功能包裝成方法,就叫他compose好了。

    const compose = fucArr=>{
        if(fucArr.length === 0) return;
        if(fucArr.length === 1)    return fucArr[0]((n)=>{console.log(n)})(1)
        fucArr.reduce((pre,cur)=>{
            return (next)=>pre(cur(next))
        })((n)=>{console.log(n)})(1)
    }

看上去那是相當(dāng)?shù)耐昝溃鶕?jù)咱們寫(xiě)代碼的思路咱們來(lái)比對(duì)一下原版吧。

length === 0 時(shí)： 返回一個(gè)傳入什么返回什么的函數(shù)。

length === 1 時(shí)： 直接返回傳入函數(shù)函數(shù)。

length > 1 時(shí)： 構(gòu)建一個(gè)a(b(c(....)))這種函數(shù)調(diào)用模型并返回，使用者自定義最后一環(huán)需要運(yùn)行的函數(shù)，并且能夠定義進(jìn)入第一環(huán)的初始參數(shù)

    // 原版
    function compose(...funcs) {
        if (funcs.length === 0) {
            return arg => arg
        }

        if (funcs.length === 1) {
            return funcs[0]
        }

        return funcs.reduce((a, b) => (...args) => a(b(...args)))
    }

最后說(shuō)一點(diǎn)題外話，在整個(gè)實(shí)現(xiàn)的過(guò)程中確保異步調(diào)用順序還有很多方式。親測(cè)可用的方式有:

bind

遞歸調(diào)用

通過(guò)new Promise 函數(shù)，將resolve作為參數(shù)方法傳入上一個(gè)函數(shù)然后改變Promise狀態(tài)...，

如果大家有興趣可以自己實(shí)現(xiàn)一下，為了不把大家的思路帶歪，在寫(xiě)的過(guò)程中并沒(méi)有體現(xiàn)出來(lái)。

感謝@MrTreasure幫我指出文章中的問(wèn)題，如果覺(jué)得我寫(xiě)對(duì)你有一定的幫助，那就點(diǎn)個(gè)贊吧，因?yàn)槟墓膭?lì)是我最大的動(dòng)力。