詳解vue中async-await的使用誤區(qū)

更新時(shí)間：2018年12月05日 08:12:33 作者：issaxite

這篇文章主要介紹了vue中async-await的使用誤區(qū),本文通過實(shí)例代碼給大家介紹的非常詳細(xì)，具有一定的參考借鑒價(jià)值，需要的朋友可以參考下

曾經(jīng)見過為了讓鉤子函數(shù)的異步代碼可以同步執(zhí)行，而對鉤子函數(shù)使用async/await，就好像下面的代碼：

// exp-01
export default {
 async created() {
 const timeKey = 'cost';
 console.time(timeKey);
 console.log('start created');
 this.list = await this.getList();
 console.log(this.list);
 console.log('end created');
 console.timeEnd(timeKey);
 },
 mounted() {
 const timeKey = 'cost';
 console.time(timeKey);
 console.log('start mounted');
 console.log(this.list.rows);
 console.log('end mounted');
 console.timeEnd(timeKey);
 },
 data() {
 return {
  list: []
 };
 },
 methods: {
 getList() {
  return new Promise((resolve) => {
  setTimeout(() => {
   return resolve({
   rows: [
    { name: 'isaac', position: 'coder' }
   ]
   });
  }, 3000);
  });
 }
 }
};

exp-01 的代碼最后會(huì)輸出：

start created
start mounted
undefined
end mounted
mounted cost: 2.88623046875ms
{__ob__: Observer}
end created
created cost: 3171.545166015625ms

很明顯沒有達(dá)到預(yù)期的效果，為什么？

根據(jù) exp-01 的輸出結(jié)果，可以看出代碼的執(zhí)行順序，首先是鉤子的執(zhí)行順序：

created => mounted

是的，鉤子的執(zhí)行順序還是正常的沒有被打亂，證據(jù)就是：created鉤子中的同步代碼是在mounted先執(zhí)行的：

start created
start mounted

再看看created鉤子內(nèi)部的異步代碼：

this.list = await this.getList();

可以看見this.list的打印結(jié)果

end mounted
mounted cost: 2.88623046875ms
// 這是created鉤子打印的this.list
{__ob__: Observer}
end created

在mounted鉤子執(zhí)行完畢之后才打印，言外之意是使用async/await的鉤子內(nèi)部的異步代碼并沒有起到阻塞鉤子主線程的執(zhí)行。這里說的鉤子函數(shù)的主線程是指：

beforeCreate => created => beforeMount => mounted => ...

會(huì)寫出以上代碼的原因我估計(jì)有兩個(gè)：

exp-01

正文

剖析一下

前言中針對代碼的執(zhí)行流程分析了一下，很明顯沒有如期望的順序執(zhí)行，我們先來回顧一下期望的順序是什么

// step 1
created() {
 // step 1.1
 let endTime;
 const startTime = Date.now();
 console.log(`start created: ${startTime}ms`);
 // step 1.2
 this.list = await this.getList();
 endTime = Date.now();
 console.log(this.list);
 console.log(`end created: ${endTime}ms, cost: ${endTime - startTime}ms`);
},
// step 2
mounted() {
 let endTime;
 const startTime = Date.now();
 console.log(`start mounted: ${startTime}ms`);
 console.log(this.list.rows);
 endTime = Date.now();
 console.log(`end mounted: ${endTime}ms, cost: ${endTime - startTime}ms`);
}

// step 1 => step 1.1 => step 1.2 => step 2

期望的打印結(jié)果是：

// step 1(created)
start created
// this.list
{__ob__: Observer}
end created
created cost: 3171.545166015625ms

// step 2(mounted)
start mounted
// this.list.rows
[{…}, __ob__: Observer]
end mounted
mounted cost: 2.88623046875ms

對比實(shí)際的打印和期望的打印，就知道問題出在created鉤子內(nèi)使用了await的異步代碼，并沒有達(dá)到我們期望的那種的“異步代碼同步執(zhí)行”的效果，僅僅是一定程度上達(dá)到了這個(gè)效果。

下面來分析一下為什么會(huì)出現(xiàn)這個(gè)非預(yù)期的結(jié)果！

在分析前，讓我們來回顧一下一些javascript的基礎(chǔ)知識！看看下面這段代碼：

(function __main() {
 console.log('start');
 setTimeout(() => {
 console.log('console in setTimeout');
 }, 0);
 console.log('end');
})()

// output
start
end
console in setTimeout

這個(gè)打印順序有沒有讓你想到什么？！

任務(wù)隊(duì)列！

我們都知道JavaScript的代碼可以分成兩類：

同步代碼和異步代碼

同步代碼會(huì)在主線程按照編寫順序執(zhí)行；

異步代碼的觸發(fā)過程（注意是觸發(fā)，比如異步請求的發(fā)起，就是在主線程同步觸發(fā)的）是同步的，但是異步代碼的實(shí)際處理邏輯（回調(diào)函數(shù)）則會(huì)在異步代碼有響應(yīng)時(shí)將處理邏輯代碼推入任務(wù)隊(duì)列（也叫事件隊(duì)列），瀏覽器會(huì)在主線程（指當(dāng)前執(zhí)行環(huán)境的同步代碼）代碼執(zhí)行完畢后以一定的周期檢測任務(wù)隊(duì)列，若有需要處理的任務(wù)，就會(huì)讓隊(duì)頭的任務(wù)出隊(duì)，推入主線程執(zhí)行。

比如現(xiàn)在我們發(fā)起一個(gè)異步請求：

// exp-02
console.log('start');
axios.get('http://xxx.com/getList')
 .then((resp) => {
 console.log('handle response');
 })
 .catch((error) => {
 console.error(error);
 });
console.log('end');

在主線程中，大概首先會(huì)發(fā)生如下過程：

// exp-03
// step 1
console.log('start');

// step 2
axios.get('http://xxx.com/getList'); // 此時(shí)回調(diào)函數(shù)（即then內(nèi)部的邏輯）還沒有被調(diào)用

// step 3
console.log('end');

在看看瀏覽器此時(shí)在干什么！

此時(shí)事件輪詢（Event Loop）登場，其實(shí)并非此時(shí)才登場，而是一直都在！

“事件輪詢”這個(gè)機(jī)制會(huì)以一定的周期檢測任務(wù)隊(duì)列有沒有可執(zhí)行的任務(wù)（所謂任務(wù)其實(shí)就是callback），有即出隊(duì)執(zhí)行。

當(dāng) step 2 的請求有響應(yīng)了，異步請求的回調(diào)函數(shù)就會(huì)被添加到任務(wù)隊(duì)列（Task Queue）或者稱為事件隊(duì)列(Event Queue)，然后等到事件輪詢的下一次檢測任務(wù)隊(duì)列，隊(duì)列里面任務(wù)就會(huì)依次出隊(duì)，進(jìn)入主線程執(zhí)行：即執(zhí)行下面的代碼：

// 假定沒有出錯(cuò)的話
((resp) => {
 console.log('handle response');
})()

到此，簡短科普了任務(wù)隊(duì)列的機(jī)制，聯(lián)想 exp-01 的代碼，大概知道出現(xiàn)非預(yù)期結(jié)果的原因了吧！

created鉤子中的await函數(shù)，雖然是在一定程度上是同步的，但是他還是被掛起了，實(shí)際的處理邏輯（this.list =resp.xxx）則在響應(yīng)完成后才被添加進(jìn)任務(wù)隊(duì)列，并且在主線程的同步代碼執(zhí)行完畢后執(zhí)行。下面是將延時(shí)時(shí)間設(shè)為0后的打?。?

start created
start mounted
undefined
end mounted
mounted cost: 2.88623046875ms
{__ob__: Observer}
end created
created cost: 9.76611328125ms

這側(cè)面說明了await函數(shù)確實(shí)被被掛起，回調(diào)被添加到任務(wù)隊(duì)列，在主線程代碼執(zhí)行完畢后等待執(zhí)行。

然后是為什么說 exp-01 的代碼是一定程度的同步呢？！

同步執(zhí)行的另一個(gè)意思是不是就是：阻塞當(dāng)前線程的繼續(xù)執(zhí)行直到當(dāng)前邏輯執(zhí)行完畢~

看看 exp-01 的打印:

{__ob__: Observer}
end created
created cost: 3171.545166015625ms

end created 這句打印，是主線程的代碼，如果是一般的異步請求的話，這句打印應(yīng)該是在 {__ob__: Observer} 這句打印之前的yo，至于為什么會(huì)這樣，這里就不多解析，自行g(shù)oogle！

另外，這里來個(gè)小插曲，你應(yīng)該注意到，我一直強(qiáng)調(diào)，回調(diào)函數(shù)被添加進(jìn)任務(wù)隊(duì)列的時(shí)機(jī)是在響應(yīng)完成之后，沒錯(cuò)確實(shí)如此的！

但在不清除這個(gè)機(jī)制前，你大概會(huì)有兩種猜想：

1.在觸發(fā)異步代碼的時(shí)，處理邏輯就會(huì)被添加進(jìn)任務(wù)隊(duì)列；
2.上面說到的，在異步代碼響應(yīng)完成后，處理邏輯才會(huì)被添加進(jìn)任務(wù)隊(duì)列；

其實(shí)大可推斷一下

隊(duì)列的數(shù)據(jù)結(jié)構(gòu)特征是：先進(jìn)先出（First in First out）

此時(shí)假如主線程中有兩個(gè)異步請求如下：

// exp-04
syncRequest01(callback01);
syncRequest02(callback02);

假設(shè)處理機(jī)制是第一點(diǎn)描述那樣，那么callback01就會(huì)先被添加進(jìn)任務(wù)隊(duì)列，然后是callback02。

然后，我們再假設(shè)syncRequest01的響應(yīng)時(shí)間是10s，syncRequest02的響應(yīng)時(shí)間是5s。

到這里，有沒有察覺到違和感！

異步請求的實(shí)際表現(xiàn)是什么？是誰快誰的回調(diào)先被執(zhí)行，對吧！那么實(shí)際表現(xiàn)就是callback02會(huì)先于callback01執(zhí)行！

那么基于這個(gè)事實(shí)，再看看上面的假設(shè)（callback01會(huì)執(zhí)行）~

ok！插曲完畢！

解法

首先讓我回顧一下目的，路由組件對異步請求返回的數(shù)據(jù)有強(qiáng)依賴，因此希望阻塞組件的渲染流程，待到異步請求響應(yīng)完畢之后再執(zhí)行。

這就是我們需要做的事情，需要強(qiáng)調(diào)的一點(diǎn)是：我們對數(shù)據(jù)有強(qiáng)依賴，言外之意就是數(shù)據(jù)沒有按預(yù)期返回，就會(huì)導(dǎo)致之后的邏輯出現(xiàn)不可避免的異常。

接下來，我們就需要探討一下解決方案！

組件內(nèi)路由守衛(wèi)了解一下??？

beforeRouteEnter
beforeRouteUpdate (2.2 新增)
beforeRouteLeave

這里需要用到的路由守衛(wèi)是： beforeRouterEnter ，先看代碼：

// exp-05
export default {
 beforeRouteEnter(to, from, next) {
 this.showLoading();
 this.getList()
  .then((resp) => {
  this.hideLoading();
  this.list = resp.data;
  next();
  })
  .catch((error) => {
  this.hideLoading();
  // handle error
  });
 },

 mounted() {
 let endTime;
 const startTime = Date.now();
 console.log(`start mounted: ${startTime}ms`);
 console.log(this.list.rows);
 endTime = Date.now();
 console.log(`end mounted: ${endTime}ms, cost: ${endTime - startTime}ms`);
 },
};

路由守衛(wèi) beforeRouterEnter ，觸發(fā)這個(gè)鉤子后，主線程都會(huì)阻塞，頁面會(huì)一直保持假死狀態(tài)，直到在調(diào)用 beforeRouterEnter 的回調(diào)函數(shù) next ，才會(huì)跳轉(zhuǎn)路由進(jìn)行新路由組件的渲染。

看起這個(gè)解決方案相當(dāng)適合上面我們提出的需求，在調(diào)用 next 前，就可以去拉取數(shù)據(jù)！

但是如剛剛說到的，頁面在一直假死，加入數(shù)據(jù)獲取花費(fèi)時(shí)間過長就難免變得很難看，用戶體驗(yàn)未免太差

為此，在 exp-05 中我在請完成前后分別調(diào)用了 this.showLoading() 和 this.hideLoading() 以便頁面 keep-alive 。

這個(gè)處理假死的loading有沒有讓你想到寫什么，沒錯(cuò)就是下面這個(gè)github跳轉(zhuǎn)頁面是頂部的小藍(lán)條

想想就有點(diǎn)cool，當(dāng)然還有很多的實(shí)現(xiàn)方式提升用戶體驗(yàn)，比如作為body子元素的全屏loading，或者button-loading等等……

當(dāng)然，我們知道阻塞主線程怎么都是阻塞了，loading只是一種自欺欺人式的優(yōu)化（此時(shí)這個(gè)成語可不是什么貶義的詞語）！

因此，不是對數(shù)據(jù)有非常強(qiáng)的依賴，都應(yīng)在路由的鉤子進(jìn)行數(shù)據(jù)抓取，這樣就可以讓用戶“更快”地跳轉(zhuǎn)到目的頁。為避免頁面對數(shù)據(jù)依賴拋出的異常（大概就是 undefined of xxx ），我們可以對初始數(shù)據(jù)進(jìn)行一些預(yù)設(shè)，比如 exp-01 中對 this.list.rows 的依賴，我們可以預(yù)設(shè) this.list ：