本文圍繞下面這個例子，講解一下computed初始化及更新時的流程，來看看計算屬性是怎么實現的緩存，及依賴是怎么被收集的。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
<div id="app"> <span @click="change">{{sum}}</span></div><script src="./vue2.6.js"></script><script> new Vue({ el: "#app", data() { return { count: 1, } }, methods: { change() { this.count = 2 }, }, computed: { sum() { return this.count + 1 }, }, })</script> |
初始化 computed
vue初始化時先執行init方法，里面的initState會進行計算屬性的初始化
|
1
|
if (opts.computed) {initComputed(vm, opts.computed);} |
下面是initComputed的代碼
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
var watchers = vm._computedWatchers = Object.create(null); // 依次為每個 computed 屬性定義一個計算watcherfor (const key in computed) { const userDef = computed[key] watchers[key] = new Watcher( vm, // 實例 getter, // 用戶傳入的求值函數 sum noop, // 回調函數 可以先忽視 { lazy: true } // 聲明 lazy 屬性 標記 computed watcher ) // 用戶在調用 this.sum 的時候，會發生的事情 defineComputed(vm, key, userDef)} |
每個計算屬性對應的計算watcher的初始狀態如下：
|
1
2
3
4
5
6
7
|
{ deps: [], dirty: true, getter: ƒ sum(), lazy: true, value: undefined} |
可以看到它的 value 剛開始是 undefined，lazy 是 true，說明它的值是惰性計算的，只有到真正在模板里去讀取它的值后才會計算。
這個 dirty 屬性其實是緩存的關鍵，先記住它。
接下來看看比較關鍵的 defineComputed，它決定了用戶在讀取 this.sum 這個計算屬性的值后會發生什么，繼續簡化，排除掉一些不影響流程的邏輯。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
Object.defineProperty(target, key, { get() { // 從剛剛說過的組件實例上拿到 computed watcher const watcher = this._computedWatchers && this._computedWatchers[key] if (watcher) { // 只有dirty了才會重新求值 if (watcher.dirty) { // 這里會求值，會調用get，會設置Dep.target watcher.evaluate() } // 這里也是個關鍵 等會細講 if (Dep.target) { watcher.depend() } // 最后返回計算出來的值 return watcher.value } }}) |
這個函數需要仔細看看，它做了好幾件事，我們以初始化的流程來講解它：
首先 dirty 這個概念代表臟數據，說明這個數據需要重新調用用戶傳入的 sum 函數來求值了。我們暫且不管更新時候的邏輯，第一次在模板中讀取到 {{sum}} 的時候它一定是 true，所以初始化就會經歷一次求值。
|
1
2
3
4
5
6
|
evaluate () { // 調用 get 函數求值 this.value = this.get() // 把 dirty 標記為 false this.dirty = false} |
這個函數其實很清晰，它先求值，然后把 dirty 置為 false。再回頭看看我們剛剛那段 Object.defineProperty 的邏輯，下次沒有特殊情況再讀取到 sum 的時候，發現 dirty是false了，是不是直接就返回 watcher.value 這個值就可以了，這其實就是計算屬性緩存的概念。
依賴收集
初始化完成之后，最終會調用render進行渲染，而render函數會作為watcher的getter，此時的watcher為渲染watcher。
|
1
2
3
4
5
|
updateComponent = () => { vm._update(vm._render(), hydrating)}// 創建一個渲染watcher，渲染watcher初始化時，就會調用其get()方法，即render函數，就會進行依賴收集new Watcher(vm, updateComponent, noop, {}, true /* isRenderWatcher */) |
看一下watcher中的get方法
|
1
2
3
4
5
6
7
8
9
10
11
12
|
get () { // 將當前watcher放入棧頂，同時設置給Dep.target pushTarget(this) let value const vm = this.vm // 調用用戶定義的函數，會訪問到this.count，從而訪問其getter方法，下面會講到 value = this.getter.call(vm, vm) // 求值結束后，當前watcher出棧 popTarget() this.cleanupDeps() return value } |
渲染watcher的getter執行時（render函數），會訪問到this.sum，就會觸發該計算屬性的getter，即在initComputed時定義的該方法，會把與sum綁定的計算watcher得到之后，因為初始化時dirty為true，會調用其evaluate方法，最終會調用其get()方法，把該計算watcher放入棧頂，此時Dep.target也為該計算watcher。
接著調用其get方法，就會訪問到this.count，會觸發count屬性的getter（如下），就會將當前Dep.target存放的watcher收集到count屬性對應的dep中。此時求值結束，調用popTarget()將該watcher出棧，此時上個渲染watcher就在棧頂了，Dep.target重新為渲染watcher。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
// 在閉包中，會保留對于 count 這個 key 所定義的 depconst dep = new Dep() // 閉包中也會保留上一次 set 函數所設置的 vallet val Object.defineProperty(obj, key, { get: function reactiveGetter () { const value = val // Dep.target 此時就是計算watcher if (Dep.target) { // 收集依賴 dep.depend() } return value },}) |
|
1
2
3
4
5
6
|
// dep.depend()depend () { if (Dep.target) { Dep.target.addDep(this) }} |
|
1
2
3
4
5
6
7
8
9
10
|
// watcher 的 addDep函數addDep (dep: Dep) { // 這里做了一系列的去重操作 簡化掉 // 這里會把 count 的 dep 也存在自身的 deps 上 this.deps.push(dep) // 又帶著 watcher 自身作為參數 // 回到 dep 的 addSub 函數了 dep.addSub(this)} |
|
1
2
3
4
5
6
7
|
class Dep { subs = [] addSub (sub: Watcher) { this.subs.push(sub) }} |
通過這兩段代碼，計算watcher就被屬性所綁定dep所收集。watcher依賴dep，dep同時也依賴watcher，它們之間的這種相互依賴的數據結構，可以方便知道一個watcher被哪些dep依賴和一個dep依賴了哪些watcher。
接著執行watcher.depend()
|
1
2
3
4
5
6
7
|
// watcher.dependdepend () { let i = this.deps.length while (i--) { this.deps[i].depend() }} |
還記得剛剛的 計算watcher 的形態嗎？它的 deps 里保存了 count 的 dep。也就是說，又會調用 count 上的 dep.depend()
|
1
2
3
4
5
6
7
8
9
|
class Dep { subs = [] depend () { if (Dep.target) { Dep.target.addDep(this) } }} |
這次的 Dep.target 已經是 渲染watcher 了，所以這個 count 的 dep 又會把 渲染watcher 存放進自身的 subs 中。
最終count的依賴收集完畢，它的dep為:
|
1
2
3
|
{ subs: [ sum的計算watcher，渲染watcher ]} |
派發更新
那么來到了此題的重點，這時候 count 更新了，是如何去觸發視圖更新的呢？
再回到 count 的響應式劫持邏輯里去：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
// 在閉包中，會保留對于 count 這個 key 所定義的 depconst dep = new Dep() // 閉包中也會保留上一次 set 函數所設置的 vallet val Object.defineProperty(obj, key, { set: function reactiveSetter (newVal) { val = newVal // 觸發 count 的 dep 的 notify dep.notify() } })}) |
好，這里觸發了我們剛剛精心準備的 count 的 dep 的 notify 函數。
|
1
2
3
4
5
6
7
8
9
|
class Dep { subs = [] notify () { for (let i = 0, l = subs.length; i < l; i++) { subs[i].update() } }} |
這里的邏輯就很簡單了，把 subs 里保存的 watcher 依次去調用它們的 update 方法，也就是
- 調用 計算watcher 的 update
- 調用 渲染watcher 的 update
計算watcher的update
|
1
2
3
4
5
|
update () { if (this.lazy) { this.dirty = true }} |
僅僅是把 計算watcher 的 dirty 屬性置為 true，靜靜的等待下次讀取即可（再次執行render函數時，會再次訪問到sum屬性，此時的dirty為true，就會進行再次求值）。
渲染watcher的update
這里其實就是調用 vm._update(vm._render()) 這個函數，重新根據 render 函數生成的 vnode 去渲染視圖了。
而在 render 的過程中，一定會訪問到su 這個值，那么又回到sum定義的get上：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
Object.defineProperty(target, key, { get() { const watcher = this._computedWatchers && this._computedWatchers[key] if (watcher) { // 上一步中 dirty 已經置為 true, 所以會重新求值 if (watcher.dirty) { watcher.evaluate() } if (Dep.target) { watcher.depend() } // 最后返回計算出來的值 return watcher.value } }}) |
由于上一步中的響應式屬性更新，觸發了 計算 watcher 的 dirty 更新為 true。所以又會重新調用用戶傳入的 sum 函數計算出最新的值，頁面上自然也就顯示出了最新的值。
至此為止，整個計算屬性更新的流程就結束了。
總結一下
- 初始化data和computed,分別代理其set以及get方法, 對data中的所有屬性生成唯一的dep實例。
- 對computed中的sum生成唯一watcher,并保存在vm._computedWatchers中
- 執行render函數時會訪問sum屬性，從而執行initComputed時定義的getter方法，會將Dep.target指向sum的watcher,并調用該屬性具體方法sum。
- sum方法中訪問this.count，即會調用this.count代理的get方法，將this.count的dep加入sum的watcher,同時該dep中的subs添加這個watcher。
- 設置vm.count = 2，調用count代理的set方法觸發dep的notify方法，因為是computed屬性，只是將watcher中的dirty設置為true。
- 最后一步vm.sum，訪問其get方法時，得知sum的watcher.dirty為true,調用其watcher.evaluate()方法獲取新的值。
以上就是詳解vue computed的緩存實現原理的詳細內容，更多關于vue computed的緩存實現的資料請關注服務器之家其它相關文章！
原文鏈接：https://segmentfault.com/a/1190000039781877
