vue的async-await怎么使用

本文小編為大家詳細介紹“vue的async-await怎么使用”，內容詳細，步驟清晰，細節處理妥當，希望這篇“vue的async-await怎么使用”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。

曾經見過為了讓鉤子函數的異步代碼可以同步執行，而對鉤子函數使用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 的代碼最后會輸出：

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

很明顯沒有達到預期的效果，為什么？

根據 exp-01 的輸出結果，可以看出代碼的執行順序，首先是鉤子的執行順序：

created => mounted

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

start created
start mounted

再看看created鉤子內部的異步代碼：

this.list = await this.getList();

可以看見this.list的打印結果

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

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

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

會寫出以上代碼的原因我估計有兩個：

exp-01

正文

剖析一下

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

// 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

期望的打印結果是：

// 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

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

下面來分析一下為什么會出現這個非預期的結果！

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

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

// output
start
end
console in setTimeout

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

任務隊列！

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

同步代碼 和 異步代碼

同步代碼會在主線程按照編寫順序執行；

異步代碼的觸發過程（注意是觸發，比如異步請求的發起，就是在主線程同步觸發的）是同步的，但是異步代碼的實際處理邏輯（回調函數）則會在異步代碼有響應時將處理邏輯代碼推入任務隊列（也叫事件隊列），瀏覽器會在主線程（指當前執行環境的同步代碼）代碼執行完畢后以一定的周期檢測任務隊列，若有需要處理的任務，就會讓隊頭的任務出隊，推入主線程執行。

比如現在我們發起一個異步請求：

// 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');

在主線程中，大概首先會發生如下過程：

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

// step 2
axios.get('http://xxx.com/getList'); // 此時回調函數（即then內部的邏輯）還沒有被調用

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

在看看瀏覽器此時在干什么！

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

“事件輪詢”這個機制會以一定的周期檢測任務隊列有沒有可執行的任務（所謂任務其實就是callback），有即出隊執行。

當 step 2 的請求有響應了，異步請求的回調函數就會被添加到任務隊列（Task Queue）或者 稱為 事件隊列(Event Queue)，然后等到事件輪詢的下一次檢測任務隊列，隊列里面任務就會依次出隊，進入主線程執行：即執行下面的代碼：

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

到此，簡短科普了任務隊列的機制，聯想 exp-01 的代碼，大概知道出現非預期結果的原因了吧！

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

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

這側面說明了await函數確實被被掛起，回調被添加到任務隊列，在主線程代碼執行完畢后等待執行。

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

同步執行的另一個意思是不是就是：阻塞當前線程的繼續執行直到當前邏輯執行完畢~

看看 exp-01 的打印:

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

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

另外，這里來個小插曲，你應該注意到，我一直強調，回調函數被添加進任務隊列的時機是在響應完成之后，沒錯確實如此的！

但在不清除這個機制前，你大概會有兩種猜想：

1.在觸發異步代碼的時，處理邏輯就會被添加進任務隊列；
2.上面說到的，在異步代碼響應完成后，處理邏輯才會被添加進任務隊列；

其實大可推斷一下

隊列的數據結構特征是：先進先出（First in First out）

此時假如主線程中有兩個異步請求如下：

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

假設處理機制是第一點描述那樣，那么callback01就會先被添加進任務隊列，然后是callback02。

然后，我們再假設syncRequest01的響應時間是10s，syncRequest02的響應時間是5s。

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

異步請求的實際表現是什么？是誰快誰的回調先被執行，對吧！那么實際表現就是callback02會先于callback01執行！

那么基于這個事實，再看看上面的假設（callback01會執行）~

ok！插曲完畢！

解法

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

這就是我們需要做的事情，需要強調的一點是： 我們對數據有強依賴 ，言外之意就是數據沒有按預期返回，就會導致之后的邏輯出現不可避免的異常。

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

組件內路由守衛了解一下！？

beforeRouteEnter
beforeRouteUpdate (2.2 新增)
beforeRouteLeave

這里需要用到的路由守衛是： 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`);
 },
};

路由守衛 beforeRouterEnter ，觸發這個鉤子后，主線程都會阻塞，頁面會一直保持假死狀態，直到在調用 beforeRouterEnter 的回調函數 next ，才會跳轉路由進行新路由組件的渲染。

看起這個解決方案相當適合上面我們提出的需求，在調用 next 前，就可以去拉取數據！

但是如剛剛說到的，頁面在一直假死，加入數據獲取花費時間過長就難免變得很難看，用戶體驗未免太差

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

這個處理假死的loading有沒有讓你想到寫什么，沒錯就是下面這個github跳轉頁面是頂部的小藍條

想想就有點cool，當然還有很多的實現方式提升用戶體驗，比如作為body子元素的全屏loading，或者button-loading等等……

當然，我們知道阻塞主線程怎么都是阻塞了，loading只是一種自欺欺人式的優化（此時這個成語可不是什么貶義的詞語）！

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

list: {
 rows: []
}

這樣就不會拋出異常，待到異步請求完成，基于vue的update機制二次渲染我們的預期數據~

讀到這里，這篇“vue的async-await怎么使用”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注億速云行業資訊頻道。