微信小程序中有大量接口是異步調用,好比 wx.login()
、wx.request()
、wx.getUserInfo()
等,都是使用一個對象做爲參數,並定義了 success()
、fail()
和 complete()
做爲異步調用不一樣狀況下的回調。html
可是,以回調的方式來寫程序,真的很傷,若是有一個過程須要依次幹這些事情:npm
wx.getStorage()
獲取緩存數據,檢查登陸狀態wx.getSetting()
獲取配置信息,wx.login()
使用配置信息進行登陸wx.getUserInfo()
登陸後獲取用戶信息wx.request()
向業務服務器發起數據請求那麼,代碼大概會長這樣小程序
wx.getStorage({ fail: () => { wx.getSetting({ success: settings => { wx.login({ success: ({ code }) => { wx.getUesrInfo({ code, success: (userInfo) => { wx.request({ success: () => { // do something } }); } }); } }); } }); } });
顯然,async/await 能夠一樣邏輯的代碼看起來舒服得多。不過默認狀況下,「微信開發者工具」並不支持 async/await。如何啓用?微信小程序
若是有心,在微信小程序官方文檔中搜索 async
能夠找到「工具⇒開發輔助⇒代碼編譯」頁面中提到了對 async/await 的支持狀況,是在「增長編譯」小節的一個表格中,摘錄一段:數組
在 1.02.1904282 以及以後版本的開發工具中,增長了加強編譯的選項來加強 ES6 轉 ES5 的能力,啓用後會使用新的編譯邏輯以及提供額外的選項供開發者使用。緩存
特性 原有邏輯 加強編譯 Async/Await 不支持 支持
- 支持 async/await 語法,按需注入
regeneratorRuntime
,目錄位置與輔助函數一致
總之呢,就是,只要把「微信開發者工具」更新到 v1.02.1904282
以上,就不須要幹 npm install regenerator
這之類的事情,只須要修改一個配置項就能使用 async/await
特性了。這個配置就在「工具欄⇒詳情⇒本地設置」頁面中。服務器
爲了快速驗證 async/await 可用,在 app.js
的 onLaunch()
事件函數中加一段代碼:微信
(async () => { const p = await new Promise(resolve => { setTimeout(() => resolve("hello async/await"), 1000); }); console.log(p); })();
在短暫的自動編譯運行以後,在調試器界面的 Console 頁籤中能夠看到輸出:微信開發
hello async/await
若是不行,請先檢查「微信開發者工具」的版本——至少,去下載一個最新版本總不會有問題的。app
雖然 async/await 獲得了支持,可是還得把 wx.abcd()
封裝成 Promise 風格才行。
Node.js 在 util 模塊中提供了 promisify
來把 Node.js 風格的回調轉換成 Promise 風格,但顯然它不適用於 wx 風格。仍是本身動手吧,也不用考慮太多,好比 wx 風格的異步調用在形式上都是一致的,它們的特徵以下 :
success: (res) => any
在異步方法成功時回調fail: (err) => any
在異步方法失敗時回調complete: () => any
在異步方法完成(無論成功仍是失敗)時回調因此,若是 wx.abcd()
改爲了 Promise 風格,經過 async/await 來編寫,大概應該是這個樣子
try { const res = wx.abcd(); // do anything in success callback } catch (err) { // do anything in fail callback } finally { // do anything in complete callback }
固然,catch
和 finally
這兩個部分並非必須,也就是說,不必定非得用 try
語句塊。可是,若是不用 catch
,會有一個神坑存在,這個問題後面再說。如今首先要作的是改造。
promisify()
就是一個封裝函數,傳入原來的 wx.abcd
做爲參加,返回一個 Promise 風格的新函數。代碼和解釋以下:
因爲 51cto 博客在顯示代碼時,部分字體不是等寬字體,純代碼張貼出來的標記不能對準,因此先貼圖。但爲了方便試驗,接着貼代碼。
function promisify(fn) { // promisify() 返回的是一個函數, // 這個函數跟傳入的 fn(即 wx.abcd) 簽名相同(或兼容) return async function(args) { // ^^^^ 接受一個單一參數對象 return new Promise((resolve, reject) => { // ^^^^^^^^^^^ 返回一個 Promise 對象 fn({ // ^^ ^ 調用原函數並使用改造過的新的參數對象 ...(args || {}), // ^^^^^^^^ 這個新參數對象得有本來傳入的參數, // ^^ 固然得兼容沒有傳入參數的狀況 success: res => resolve(res), // ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 注入 success 回調,resovle 它 fail: err => reject(err) // ^^^^^^^^^^^^^^^^^^^^^^^^ 注入 fail 回調,reject 它 }); }); }; }
舉例使用它:
const asyncLogin = promisify(wx.login); // 注意別寫成 wx.login(),爲何,我不說 try { const res = asyncLogin(); const code = res.code; // do something with code } catch (err) { // login error } finally { // promisify 裏沒有專門注入 complete 回調, // 由於 complete 的內容能夠寫在這裏 }
wx.async()
不過老實說,把要用的異步方法經過 promisify
一個個處理,寫起來仍是挺煩的,不如寫個工具函數把要用的方法一次性轉換出來。不過一查,wx
下定義了不知道多少異步方法,仍是退而求其次,用到啥轉啥,不過能夠批量轉,轉出來的結果仍是封裝在一個對象中。整個過程就是迭代處理,最後把每一個處理結果聚焦在一塊兒:
function toAsync(names) { // 這裏 names 指望是一個數組 return (names || []) .map(name => ( { name, member: wx[name] } )) .filter(t => typeof t.member === "function") .reduce((r, t) => { r[t.name] = promisify(wx[t.name]); return r; }, {}); }
這個 toAsync
的用法大體是這樣的
const awx = toAsync(["login", "request"]); await awx.login(); await awx.request({...});
有些人可能更習慣單個參數傳入的方式,像這樣
const awx = toAsync("login", "request");
那麼在 toAsync
的定義中,參數改成 ...names
就好,即
function toAsync(...names) { ... }
還沒完,由於我不想在每個 JS 文件中去 import { toAsync } from ...
。因此把它在 App.onLaunch()
中把它注入到 wx
對象中去,就像這樣
App({ onLaunch: function() { // ... wx.async = toAsync; // ... } });
工具準備好了,代碼也大刀闊斧地進行了改造,看起來舒服多了,一運行卻報錯!爲何???
先來看一段原來的代碼,是這樣的
wx.getStorage({ key: "blabla", success: res => { // do with res } });
改造以後是這樣
const res = await awx.getStorage({ key: "blabla" }); // <== runtime error // do with res
awx.getStorage
拋了個異常,緣由是叫 "blabal"
的這個數據不存在。
爲何原來沒有錯,如今卻報錯?
由於原來沒有定義 fail
回調,因此錯誤被忽略了。可是 promisify()
把 fail
回調封裝成了 reject()
,因此 awx.getStorage()
返回的 Promise 對象上,須要經過 catch()
來處理。咱們沒有直接使用 Promise 對象,而是用的 await
語法,因此 reject()
會以拋出異常的形式體現出來。
用人話說,代碼得這樣改:
try { const res = await awx.getStorage({ key: "blabla" }); // <== runtime error // do with res } catch (err) { // 我知道有錯,就是當它不存在! }
傷心了不是?若是沒有傷心,你想一想,每個調用都要用 try ... catch ...
代碼塊,還能不傷心嗎?
處理錯誤真的是個好習慣,但真的不是全部錯誤狀況都須要處理。其實要忽略錯誤也很簡單,直接在每一個 Promise 形式的異步調後面加句話就行,好比
const res = await awx .getStorage({ key: "blabla" }) .catch(() => {}); // ^^^^^^^^^^^^^^^^ 捕捉錯誤,但什麼也不幹
稍微解釋一下,在這裏 awx.getStorage()
返回一個 Promise 對象,對該對象調用 .catch()
會封裝 reject 的狀況,同時它會返回一個新的 Promise 對象,這個對象纔是 await
等待的 Promise。
不過感受 .catch(() => {})
寫起來怪怪的,那就封裝成一個方法吧,這得改 Promise
類的原形
Promise.prototype.ignoreError = function() { return this.catch(() => { }); };
這段代碼放在定義 toAsync()
以前就好。
用起來也像那麼回事
const res = await awx .getStorage({ key: "blabla" }) .ignoreError();
對於單個 await
異步調用,若是不想寫 try ... catch ...
塊,還能夠本身定義一個 ifError(fn)
來處理錯誤的狀況。可是若是須要批量處理錯誤,仍是 try ... catch ...
用起順手:
try { const storeValue = await awx.getStorage({}); const settings = await awx.getSetting(); const { code } = await awx.login(); const userInfo = await awx.getUserInfo({ code }); } catch (err) { // 處理錯誤吧 }
看,不須要對每一個異步調用定義 fail
回調,一個 try ... catch ...
處理全部可能產生的錯誤,這可不也是 async/await 的優點!