Vue数据的响应过程(vue,响应,数据,web开发)

Vue 中可以用 $watch 实例方法观察一个字段，当该字段的值发生变化时，会执行指定的回调函数（即观察者），实际上和 watch 选项作用相同。如下：

以上例切入，我想实现一个功能类似的方法 myWatch。

如何知道我观察的属性被修改了？

—— Object.defineProperty 方法

该方法可以为指定对象的指定属性设置 getter-setter 函数对，通过这对 getter-setter 可以捕获到对属性的读取和修改操作。示例如下：

如此，便拦截到了对 box 属性的修改和读取操作。

但 res 为 undefined，data.box = 2 的修改操作也无效。

get 与 set 函数功能不健全

故修改如下：

有了这些， myWatch 方法便可实现如下：

但存在一个问题，不能给同一属性添加多个依赖（观察者）：

后面的依赖（观察者）会将前者覆盖掉。

如何能够添加多个依赖（观察者）？

—— 定义一个数组，作为依赖收集器：

修改 data.box 后，两个依赖（观察者）都执行了。

若上例 data 对象需新增两个能够响应数据变化的属性 foo bar：

只需执行以下代码即可：

但问题是，不同属性的依赖（观察者）都被收集进了同一个 dep，修改任何一个属性，都会触发所有的依赖（观察者）：

我想可以这样解决：

但实际上这样更好些：

声明 target 全局变量作为依赖（观察者）的中转站，myWatch 函数执行时用 target 缓存依赖，然后调用 data[key] 触发对应的 get 函数以收集依赖，set 函数被触发时会将 dep 里的依赖（观察者）都执行一遍。这里的 get set 函数形成闭包引用了上面的 dep 常量，这样一来，data 对象的每个属性都有了对应的依赖收集器。

且这一实现方式不需要通过 myWatch 函数显式地将 data 里的属性一一转为访问器属性。

但运行以下代码，会发现仍有问题：

四个 myWatch 执行完之后 target 缓存的值变成了最后一个 myWatch 方法调用时所传递的依赖（观察者），故执行 console.log(data.box) 读取 box 属性的值时，会将最后缓存的依赖存入 box 属性所对应的依赖收集器，故而再修改 box 的值时，会打印出 '我是bar的观察者'。

我想可以在每次收集完依赖之后，将全局变量 target 设置为空函数来解决这问题：

经测无误。

但开发过程中，还常碰到需观测嵌套对象的情形：

这时，上述实现未能观测到 gift 的修改，显出不足。

如何进行深度观测？

——递归

通过递归将各级属性均转为响应式属性即可：

这时 gift 虽已是访问器属性，但 myWatch 方法执行时 data[box.gift] 未能触发相应 getter 以收集依赖， data[box.gift] 访问不到 gift 属性，data[box][gift] 才可以，故 myWatch 须改写如下：

如果要读取的字段包括 . ，那么按照 . 将其分为数组，然后使用循环读取嵌套对象的属性值。

这时执行代码后发现，data.box.gift = 'guitar' 还是未能触发相应的依赖，即打印出 '我是gift的观察者' 这句信息。调试之后找到问题：

执行以上代码时，pathArr 即 ['box', 'gift']，循环内 obj = obj[p] 实际上就是 obj = data[box]，读取了一次 box，触发了 box 对应的 getter，收集了依赖：

收集完将全局变量 target 置为空函数，而后，循环继续执行，又读取了 gift 的值，但这时，target 已是空函数，导致属性 gift 对应的 getter 收集了一个“空依赖”，故，data.box.gift = 'guitar' 的操作不能触发期望的依赖。

以上代码有两个问题：

修改 box 会触发“我是gift的观察者”这一依赖

修改 gift 未能触发“我是gift的观察者”的依赖

第一个问题，读取 gift 时，必然经历读取 box 的过程，故触发 box 对应的 getter 无可避免，那么，box 对应 getter 收集 gift 的依赖也就无可避免。但想想也算合理，因为 box 修改时，隶属于 box 的 gift 也算作修改，从这一点看，问题一也不算作问题，划去。

第二个问题，我想可以这样解决：

保证属性读取时 target = fn 即可。

那么：

现在我想，假如我有以下数据：

执行以下代码：

是不是就可以将数据映射到页面，并响应数据的变化？

执行代码发现，data.player = 'Kobe Bryant' 报错，究其原因，render 方法执行时，会去获取 data.player 和 data.team 的值，但此时，target 为 null，那么读取 player 时对应的依赖收集器 dep 便收集了 null，导致 player 的 setter 调用依赖时报错。

那么我想，在 render 执行时便主动去收集依赖，就不会导致 dep 里收集了 null。

细看 myWatch，这方法做的事情其实就是帮助 getter 收集依赖，它的第一个参数就是要访问的属性，要触发谁的 getter，第二个参数是相应要收集的依赖。

这么看来，render 方法既可以帮助 getter 收集依赖（render 执行时会读取 player team），而且它本身就是要收集的依赖。那么，我能不能修改一下 myWatch 的实现，以支持这样的写法：

第一个参数作为函数执行一下便有了之前第一个参数的作用，第二个参数还是需要被收集的依赖，嗯，想来合理。

那么，myWatch 改写如下：

但，对 team 的修改未能触发页面更新，想来因为 render 执行读取 player 收集依赖后 target 变为空函数，导致读取 team 收集依赖时收集到了空函数。这里大家的依赖都是 render，故可将 target = () => {} 这句删去。

myWatch 这样实现还有个好处，假如 data 中有许多属性都需要通过 render 渲染至页面，一句 myWatch(render, render) 便可，无须如此这般繁复：

那么最终：