复杂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的这种方案，在路由进入前把所有异步数据都准备不就行了吗？这的确可以解决大部分问题，但是有一些特殊的业务需求，需要动态的根据一些"参数"去发起请求，所以还是摆脱不了这个问题。

为了应对各种各样的需求，我们在写任何存在异步任务的代码时，都要提前做好流程设计，要确保代码的运行是严格符合期望的。