Vue的执行时序和运行机制深入了解

最近在newfas项目开发过程中，使用watch侦听器来侦听computed计算属性的时候，遇到了一个很奇怪的问题：

我们在一段代码中多次修改computed依赖的变量的时候，不会进入到watch的回调中去，

然后在开发过程中，我们惊奇的发现，如果使用await来把写在created中的修改变量的代码异步化之后，就能多次响应变化，进入到watch的回调中

但是如果修改变量的代码在methods中的时候，无论怎么异步化，都不会多次响应变化

考虑到这种操作实在是太骚，不能说服我们心中那躁动的自我，我们决定对Vue的相关源码来一次研究，并最终找到了结论。

为了能更好的解决问题，我们先分析了Vue的源码，详细了解Vue中对computed，watch、nextTick的实现方法，并输出了文章。描述解决方法之前清看看下列文章

---

系列文章目录：

Vue源码理解之一：computed计算属性

Vue源码理解之二：watch侦听器

Vue源码理解之三：nextTick回调延迟

---

现在回到问题中去，为啥进不到watch的回调中去呢？

先贴一个简单的demo，重现一下问题

跑起来发现：
watch中只会进去一次，进去的val为3；computed也只会进去一次，计算的值为3

这时候我们去reactiveObeserve的get和set中打断点，发现，它set了3次，从1到2到3；但是只get了一次。get的那一次值为3。

根据Vue原理的分析，得出初步结论

1. 我们在代码中只调用了一次testComputed，是在DOM中调用的，只有DOM改变了，才会触发computed
2. set时，虽然改变了test的值，但是因为没有被调用，testComputed的值并没有被修改
3. 全部执行完之后，改变了V-DOM的值触发了DOM的异步更新，进而触发了一次计算属性testComputed的get。
4. 触发时，test的值已经为3了，所以computed也只会进去一次，testComputed的值为3。
5. testComputed改变之后，触发了watch，watch对比之后，发现testComputed改变了，就回调了this.test1 = val。

看起来解释的相当完美。

So easy？才怪。马上就来打打自己的脸

我们将created里的代码修改如下，让testComputed被多次调用

    created() {
        this.$set(this, 'test', '1');
        console.log(this.testComputed)
        this.$set(this, 'test', '2');
        console.log(this.testComputed)
        this.$set(this, 'test', '3');
    },

照理来说，$set为1后，我们js里马上调用了testComputed，虽然DOM里的不会变化，但是computed里的testComputed变化了，理应触发watch的回调才对

但结果是，computed进去三次，从1到2到3，但watch中仍然只会进去一次，进去的val为3；

仔细想想，对了，与computed计算属性在被调用时立刻执行不同，watch侦听器实例是有watcher队列这个概念的，只要观察到数据变化，Vue将开启一个队列，并缓冲在同一事件循环中发生的所有数据改变。如果同一个watcher被多次触发，只会被推入到队列中一次。并且是放在nextTick的回调异步执行的。

那么我们修改一下之前的初步结论

1. set时，testComputed的值被修改，由于被多次调用，testComputed从1变到2到3
2. 被观察到数据变化，开启队列，watch不会被多次触发，只会被推入到队列中一次，并且是放在nextTick的回调异步执行的
3. $set全部执行完之后，改变了V-DOM的值触发了DOM的异步更新，nextTick执行watch的回调。
4. 但此时test的值已经为3了，就回调了this.test1 = val。

perfect!原理说得通了，那么我现在想要每次修改都要能进watch。既然他是异步执行的，而且我们已知nextTick优先选择微任务形式，也就是promise来异步执行，那我们就用同样也是promise的语法糖async/await来修改一下created：

    async created() {
        await this.$set(this, 'test', '1');
        console.log(this.testComputed)
        await this.$set(this, 'test', '2');
        console.log(this.testComputed)
        this.$set(this, 'test', '3');
    },

完美的进入了三次watch，而且其实异步化之后，每一次await都会在刷新DOM之后的才执行，testComputed已经由DOM元素触发了get了，就不需要console.log(this.testComputed)来触发了。

    async created() {
        await this.$set(this, 'test', '1');
        await this.$set(this, 'test', '2');
        this.$set(this, 'test', '3');
    },

简化后的效果相同，都能进入三次watch。

现实开发过程中，在methods中也有一个地方遇到了这个问题，所以我们就把这段代码加到methods中，

methods: {
    async testClick() {
        await this.$set(this, 'test', '4');
        await this.$set(this, 'test', '5');
        this.$set(this, 'test', '6');
    }
},

正当我们满心期待点击按钮之后也会进入三次watch，得到同样的结果时，坑爹的事情发生了，它居然又只进入一次watch，val为6。更奇怪的是computed也居然只被修改了一次。也就是说DOM在三次$set后只被更新了一次。

又跑去看了源码，原来Vue添加event的时候，会给useMacroTask设置为true，并且执行event的回调，所以由事件触发的watch侦听器里的nextTick使用的是宏任务（如setTimeout），他会在所有微任务全部完成之后再触发。所以在methods里想通过async/await来触发多次watch是行不通的，只能用setTimeout才能达到同样的效果。

把代码修改为：

methods: {
    testClick() {
        setTimeout(() => { this.$set(this, 'test', '4'); }, 0);
        setTimeout(() => { this.$set(this, 'test', '5'); }, 0);
        setTimeout(() => { this.$set(this, 'test', '6'); }, 0);
    }
},

就能达到目的了。

结论

文章所述的问题归因于JS的运行机制，参考以下两张图，

1. js异步有一个机制，就是遇到宏任务，先执行宏任务，将宏任务放入eventqueue，然后在执行微任务，将微任务放入eventqueue
2. 这两个queue不是一个queue。当你往外拿的时候先从微任务的queue里拿微任务的回调函数，然后再从宏任务的queue上拿宏任务的回调函数。
3. 再结合Vue源码理解系列文章的结论，就可以解释所有问题了
4. 声明：本文并不支持这么使用watch，只是利用这个问题深挖原理。