業務邏輯

最近開發一個便簽小程序的時候，有這樣一個需求：用戶可以在寫便簽的時候添加一個或多個圖片。

對于這個需求，我們用戶按下保存鍵時，內部具體的實現上是這樣的邏輯：

首先檢測用戶是否傳入了圖片，如果存儲本地圖片地址的數組長度>=1,則將圖片數組放入上傳圖片的函數。 由于小程序網絡請求大小限制，我們只能采取循環上傳單文件，然后收集每次請求的結果--圖片在服務器的地址，最后將結果放在一個數組中供后續的操作使用。 當圖片上傳函數全部執行完畢后，將數組中的圖片數組取出來，賦值到日記對象中，再將整個日記對象提交到服務器。 服務器返回保存成功或失敗。

思路其實非常清晰簡單，但是在代碼實現上卻翻了大跟頭。

異步帶來的問題

小程序的網絡請求是異步的：我們無法通過return來將網絡請求結果返回出來使用。

  wx.request({     //...省略其他屬性     success: function (res) {     },     fail: function (res) {     }  })

例如在微信中發送網絡請求，我們只能使用微信提供的方法wx.xxx，其中請求的結果保存在res中，而res無法直接return得到。

解決：res雖然無法直接獲取，但是我們能通過將需要使用到這個請求結果的業務邏輯代碼放入這個網絡請求的回調函數中直接讀取網絡請求結果，也就是一切都需要通過回調來解決。

  wx.request({     //...省略其他屬性     success: function (res) {      console.log(res);      //接業務邏輯代碼     },     fail: function (res) {      console.log(res);     }  })

例如這個微信的網絡請求，我們可以通過success和fail的回調函數來讀取res的值從而完成依賴res結果的業務邏輯。

回調地獄

雖然解決了結果獲取的問題，但是又產生了另一個問題，當多個請求中有明確的先后順序時，回調會嵌套的很厲害，造成回調地獄，代碼可讀性和可維護性都會很差。

例如對于一個日記頁面，需要先請求到頁面的數據（里面包含了圖片數據和其他數據的地址），再根據頁面數據去請求圖片數據后再請求音頻數據。例如以下代碼：

  //請求頁面整體數據  wx.request({     //...省略其他屬性     success: function (res) {//成功        //請求圖片數據        wx.request({         success: function (res) {//成功           //請求音頻數據           wx.request({             success: function (res) {//成功             },             fail: function (res) {//失敗               console.log("請求失敗:"+res);             }           })         },         fail: function (res) {//失敗           console.log("請求失敗:"+res);         }        })     },     fail: function (res) {//失敗       console.log("請求失敗:"+res);     }  })