vue源码阅读复盘-watcher模块
回顾目标
数据驱动视图：
理解watcher、dep、observer这三个对象之间的关系
这和VUE对象又有什么关系？
这和视图又有什么关系？
叙述过程
先彻底理解了一下VUE的简介，并写出了一份建议书。关键词有渐进式、自底向上逐层应用、声明式开发、组件化。
之后了解了观察者模式，观察者模式的初衷是建立低耦合的通信机制，定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
记得以前看过一本掘金小册，其中作者的结论是：每个vue对象对应一个watcher，每个observer和watcher通过dep建立一对多关系。
然后开始走读代码。大概读了一遍watcher、observer、deb发现没什么新的收获，开始认为每一个vue对象管理一个watcher,然后每个变量都管理一个observer，每个observer管理一个sub，由observer通知watcher，然后渲染。
但是提出了一个关键性的问题，有一个公共的target是用来存放watcher的，发现这个target和依赖关系非常有关，然后启动浏览器用检查器监察这个值，发现这个值一般是null，然后打开vscode，全局查找，找出是什么时候写的这个值，最后定位这个target在watch读数据*的时候被缓存。
这段话非常的重要，只有当执行用户自定义函数的时候，才会建立依赖关系。
翻看了文档。找到了一段清晰的代码，
var vm = new Vue({
data: { a: 1 },
computed: {
// 仅读取
aDouble: function () {
return this.a * 2
},
// 读取和设置
aPlus: {
get: function () {
return this.a + 1
},
set: function (v) {
this.a = v - 1
}
}
}
})
然后带着上面的问题，去阅读了vue的构造过程，在initState中发现了computed的构造,其中有一个关键的用法：
function initComputed (vm: Component) {
const computed = vm.$options.computed
...
const userDef = computed[key]
makeComputedGetter(userDef, vm)
...
}
function makeComputedGetter (getter: Function
, owner: Component): Function {
const watcher = new Watcher(owner, getter, noop, {
lazy: true
})
...
}
对于观察者来说用户定义的函数是getter，也就是对于框架底层来说，程序员写的computed函数，对组件来说是getter。computed实际上是用包装了一下用户定义的函数。可以把他理解成一种特殊的watcher，根据官方的文档，提到了computed有缓存功能，不会更新相同的结果。简单起见我们就把computed当作watcher理解。
然后开始关注这个函数内部发生了什么:
...
computed: {
// 仅读取
aDouble: function () {
return this.a * 2
},
...
这里读取了this.a。我想起来vue内部的变量都是处理过的。用了observe这个工厂方法加工过，set和get都和watcher和deb耦合。执行aDouble这个函数,computed就作为一个watcher被Dep.target记住了，而a就是一个obsserver,调用了get就会将watcher保存在deps数组中,就好像a调用get就被aDouble盯上（watch）了,下次a变化（调用a.set）就重新执行一遍aDouble。
这个时候我们再回去看wacher对象，发现这个对象有一个cb存放回调函数，而且代码中还出来了属于VNode模块的patch。cb应该是负责重新渲染视图。
所以这就可以解释VUE是如何驱动视图改变的，源自于一种自动更新的一对多机制。这可以解决父子组件的通信问题，父子组件状态同步可以通过向子组件注入父组件的数据引用，可以实现单向数据流。
查看了官方文档，结果发现：
每个组件实例都对应一个 watcher 实例，它会在组件渲染的过程中把“接触”过的数据属性记录为依赖。之后当依赖项的 setter 触发时，会通知 watcher，从而使它关联的组件重新渲染。
证实了掘金那个作者说的没错，每一个vue的确有一个watcher
查看watcher.get的call stack:
get (vue.js:647)
Watcher (vue.js:638)
Vue.$watch (vue.js:1254)
createWatcher (vue.js:1232)
initWatch (vue.js:1217)
initState (vue.js:1105)
Vue._init (vue.js:2110)
Vue (vue.js:2150)
(anonymous) (app.js:7)
我们看到Vue.$watch说明vue下确实有一个watcher
这个watcher目的是什么呢？我们回去看了一下watch的构造函数
constructor (
vm: Component,
expOrFn: string | Function,
cb: Function,
options?: Object = {}
) {
...
this.getter = parsePath(expOrFn)
this.value = this.lazy
? undefined
: this.get()
...
}
在parsePath之中会触发所有vue的内部对象的get的函数句柄，然后被执行,所有的内部数据改动都会导致wacher重新渲染数据
评估结果：
结果不等于目标
开始否认了认为每一个vue对象管理一个watcher
我们推导出了computed和watcher的关系，并认为这是watch唯一的作用
结果等于目标
理解watcher、dep、observer这三个对象之间的关系
每一个用户定义回调函数管理一个watcher,然后每个VUE内部data都管理一个observer，每个observer管理一个sub，由observer通知watcher。
这和VUE对象又有什么关系
VUE对象保存了data数据，每一个data都管理一个observer，computed是一种特殊的watcher,VUE对象渲染视图的时候会要求watcher返回一个值，这个时候watcher执行用户定义的函数句柄，也就是computed当中定义的函数时，每个data被读取的时候会和当前的函数建立依赖关系，当这个data更新的时候会重新渲染视图，重新执行用户定义函数。且当new一个vuew对象的时候watcher会监听所有的内部数据对象。
这和视图又有什么关系
每个watcher负责自动更新视图。
分析原因
开始否认为每一个vue对象管理一个watcher
先看了别人的文章然后带着结论去看的代码，最后只是找怎么支持这个结论的代码段。但是发现了文章之外的内容误以为文章错误了。
watcher是被vue对象直接调用的，很容易让人联想一对一关系，但不确定
dep.target作为关键的变量，作搞清楚这个变量的作用，就可以回答谁依赖谁这个问题。
我们推导出了computed和watcher的关系，并认为这是唯一的作用
当看到watcher.value时。意识到一个vue对象可能需要维护多个watcher，因此原来的假设不成立，那么需要找到watcher具体是做什么的。沿着watcher.get一直往下看，发现了watcher的作用和computed有关联，因此认为computed是watcher的一种表现，而一个vue对象又有n个computed。这才认为作者的观点是错误的。
很多文章中没有找到关于computed和watcher的作用，误以为是别人理解错了，其实这和我的结论并不冲突。
推演规律
自然语言更加容易被人理解，因为首因效应，人对事物的理解不太容易改变，那么我们看别人的文章，我们理解的不是原作者的设计思想，而是经过了非原作者的几层解释的最终结果。
那么这就导致了我对其他人的结论有一种怀疑，想找出反证的点。而这个时候就需要从官方文档中找到依据，作者和团队的文档最具有权威和可行度。
从非自然语言——代码。总结出来的，我们可以在阅读源代码参考别人的文章，但是其中最有价值的部分，不是别人的结论，而是别人阅读的顺序，看别人是如何抓住主干去理解的。综上有两个东西对阅读源代码有益，分别是文章的行文顺序和文章的大标题，文章的大标题一般是对源代码模块的高度概括。
发表评论 (审核通过后显示评论)：