引言
在这里我先提出两个问题(文章开端会进行解答):
- 在 Vue 的数据响应零碎中,Dep和 Watcher 各自分担什么工作?
- Vue的数据响应零碎的外围是 Object.defineproperty 肯定是最好的吗?有什么弊病和破绽吗?
一、什么是响应零碎中的 Watcher,它的作用是什么?
响应零碎中的 Watcher 即这个零碎的观察者,它是响应零碎中观察者模式的载体,当响应零碎中的数据产生扭转的时候,它可能晓得并且执行相应的函数以达到某种业务逻辑的目标。打个比方,如果你是一个商家,要寄一批货别离给不同的客户,那么 watcher 就是一个个快递员,收回的动作就是数据产生扭转。你只须要负责寄出去这个动作就行了,如何找到、送到客户则是 watcher 的事件。
每个 watcher 和数据之间的关系要么是 1 对 1,要么是多对多关系(这与 watcher 的类型无关),要不是没有分割。watcher和业务逻辑只有 1 对 1 关系。
二、Watcher 的类型
在 Vue 源码中是没有体现出 Watcher 的类型的,我在这里给 Watcher 增加类型是为了更好地了解 Watcher 这个对象。Watcher在一般的业务逻辑上能够分为以下三类:
- 一般的Watcher:与数据 1 对 1 关系。
- lazy型 Watcher:与数据 1 对 1 关系,然而它是一个惰性求值的观察者,怎么体现呢?对它进行赋值是不会扭转它的值,只有当获取它的值的时候,才会更新最新版的数据(在Vue 中体现为 computed 办法,个别求值是通过办法来求值的)。
- render型Watcher:与数据是 1 对多(不思考传参进子组件)的关系,在一个组件中,渲染函数观察者肯定是最初生成的,所以执行观察者队列的时候,渲染函数观察者在一个组件中是最初执行的。
在这里多嘴一下 lazy 型的观察者是怎么回事吧。lazy型观察者在 Vue 中体现为 computed 属性,个别这个属性是一个函数,以下是一个例子:
computed: {
// getCount 最初解决成一个属性,而后这个办法被存储在 Watcher 的某个属性中
getCount() {return this.a + this.b;}
}
lazy观察者外面有一个 dirty 属性,也就是一个开关作用,只有它为 true 的时候应用 getCount 的getter办法的时候,才会进行调用这个函数。
如果 lazy 观察者所援用的数据(a或者 b 属性)产生扭转后,会将这个放到观察者执行队列中,而后执行这个观察者的时候把 dirty 赋值为 true(代表下次访问getter 办法的时候会执行一遍 lazy 的求值办法(求值后会将 dirty 赋值为false))。等到下一次须要获取这个数据的时候才进行求值,所以它叫做惰性求值。这种形式可能节俭不必要执行函数的开销。
三、Watcher 和 Dep 的关系
看过 Vue 源码的 defineReactive 这个办法,就会发现一个被察看的对象外面每个属性会有一个 Dep 依赖筐来寄存所有察看它的 Watcher。而defineReactive 办法只有初始化每个属性的 dep 却并没有创立观察者(要分清初始化和创立观察者是离开这个事实)。那么这个 Dep 如何增加观察者呢?Vue应用了全局变量,这个变量叫做 Dep.target,它是一个Watcher 类型的变量,来将 Watcher 和Dep进行相互绑定。数据的绑定用图来示意的话如下:
咱们能够明确以下区别:
- $watch办法创立的观察者的时候,如果不设定 immediate 属性,那么是不会进行调用的,而 computed 和render是会进行调用办法的。
- 数据的 Dep 的subs数组寄存这个数据所绑定的观察者对象,观察者对象的 deps 数组中寄存着与这个观察者无关的数据 Dep。所以数据的Dep 与Watcher其实是多对多关系
- $watch和 computed 观察者是在 created 生命钩子函数前就创立结束并且绑定的,而 render 观察者是在 mounted 之前创立并绑定的,所以同一个组件中,render观察者的 id 会大于其余观察者(id是在前面执行队列外面升序排序的时候的根据)。换句话说,在同一个组件的观察者中,当数据产生扭转的时候,渲染函数观察者肯定是最初执行的。 这个很好了解,其余观察者中难免会对数据进行批改,如果渲染函数观察者先执行了,而后其余观察者对数据进行扭转的话,那么没方法将数据精确出现在页面上,导致数据不一致性。
四、讲一下观察者执行队列机制
Vue是如何实现性能优化的呢?最显著的两个点:
- 观察者设定执行队列,批量执行。
- diff算法缩小渲染开销。
第二个不在这外面解说,咱们看一下第一个是怎么回事?
这个队列的长度是怎么定量的呢?
- 最大长度是 100,源码摆在那里。
- 以一个事件循环时间段为收集工夫。(什么是事件循环?能够看一下本博客零碎的其余优良文章)
参考 前端进阶面试题具体解答
它的流程是如下的:
- 未执行时候:如果有更改过数据,那么就将对应的观察者间接推动队列中(执行的时候会进行依据 id 升序排序后执行)
- 在执行中的时候,如果有新的观察者进来了(观察者中更改数据,而后这个数据又绑定观察者),依照 id 升序来进行插入(这相当于在有序数组外面进行插入,能够看做插入排序的其中一步,所以某种意义上来说它就是排序)。
五、解答后面的问题
- Dep是负责存放数据所绑定所有的观察者的对象的容器,只有数据产生扭转,就会通过这个 Dep 来告诉所有观察者进行批改数据。(每个数据都有举世无双的 Dep)。而Watcher 更偏差于一个动作,也就是规定的业务逻辑或者渲染函数,是一个执行者。
-
在 ES5 是很轻便的,很好的。然而在 ES6 呈现后,它就肯定不是最好的,因为 ES6 有一个 Proxy 代理来对立进行解决。(ES6 应用代理实现 Vue 数据响应零碎(TypeScript))
- 弊病:如果一个数据有 1000 个属性,那么就要给这 1000 个属性应用Object.defineProperty,这样在初始化页面的时候会造成卡顿。如果用代理的话,那么只须要执行一次就能够了。
- 破绽:如果咱们拿到了 vm 实例,那么用户是能够在运行的时候通过批改对象属性的描述符(descriptor)来进行批改它,会造成零碎的不确定性。这是因为响应零碎的模式导致必须将数据的描述符的 configuration 设为true,所以在运行的时候可能对它进行批改。