複雜Vue元件的非同步流程分析
如果一個元件的狀態，依賴於非同步任務的執行，那麼這個狀態就是非同步的，我們稱之為非同步狀態。非同步狀態會引入不確定性，換句話說就是，程式碼執行結果的正確與否完全靠運氣或者靠網速。更糟糕的是，這種不確定性會可能向外擴散向內滲透，進而影響到整個應用的穩定性。
NextTick讓非同步狀態更加難以捉摸
我們知道Vue關於資料檢視雙向繫結的實現是基於觀察者模式，在這個過程中，我們Observe元件狀態、建立Watcher、訂閱事件變化，並在nextTick中flush我們的schedulerQueue。
Vue的這種基於nextTick的處理機制，再加上我們自己的非同步程式碼，兩者結合起來共同影響的那些非同步狀態，會給我們的程式碼穩定性帶來很大挑戰。
如果我們處理不好這種非同步狀態，Vue的表現會變得讓人難以捉摸。具體來說就是watch的handler執行時機、檢視的更新時機等問題，因為他們都依賴於nextTick機制，而在nextTick這個時刻，我們自己的非同步程式碼的執行狀態又是不確定的，這就導致Vue在nextTick時可能面臨的是一個不穩定的非同步狀態。因此，Vue不得不多次執行watch的handler，或者多次更新檢視，以保證最新的狀態都已經得到"應用"。
一個熟悉的問題
我們應該見過這樣的面試題：
(function test() {
setTimeout(function() {console.log(4)}, 0);
new Promise(function executor(resolve) {
console.log(1);
for( var i=0 ; i<10000 ; i++ ) {
i == 9999 && resolve();
}
console.log(2);
}).then(function() {
console.log(5);
});
console.log(3);
})()
---------------------
作者：Front_end_lh
來源：CSDN
原文：https://blog.csdn.net/qq_31628337/article/details/71056294
版權宣告：本文為博主原創文章，轉載請附上博文連結！
複製程式碼
如果我們已經瞭解過js的事件迴圈機制，我們都能輕鬆地預測出程式碼的執行順序，但是一旦跟Vue結合起來，事情就會麻煩很多。
點選檢視一個刻意複雜化的例子以模擬真實專案中的複雜邏輯 ，預測一下執行順序是怎樣的？
能否準確預測程式碼的執行情況，不僅是確保程式穩定執行的重要前提，更是衡量我們對框架理解程度的重要指標。
我們該怎麼做
實際開發中業務元件會不可避免的複雜化，甚至有些業務性很重的子元件還會發起非同步請求，導致非同步狀態分佈在多個元件當中，這個時候對Vue執行過程的分析就很困難了。
或許你會想，直接使用vue-router的這種方案，在路由進入前把所有非同步資料都準備不就行了嗎？這的確可以解決大部分問題，但是有一些特殊的業務需求，需要動態的根據一些"引數"去發起請求，所以還是擺脫不了這個問題。
為了應對各種各樣的需求，我們在寫任何存在非同步任務的程式碼時，都要提前做好流程設計，要確保程式碼的執行是嚴格符合期望的。