各位五一快乐，最近工作比较忙，来拿点工作中遇到的问题水一水。在 Vue 中我们经常使用 watch 来监听响应式变量的变化。有时，我们需要监听多个变量，但执行同样的逻辑，这时写多个 watch 就很浪费。不难想到，可以使用 computed 把这几个变量组合起来，这样只需监听这个单独的计算属性就可以了。
下面的例子展示了这一用法：当 id 和 Post 表单的 title 属性变化时，打印一行日志。
<!-- App.vue -->
<script>
export default {
data() {
return {
id: 1,
post: {
title: 'hello world',
desc: 'Lorem ipsum'
}
}
},
computed: {
mutableParams() {
return {
id: this.id,
title: this.post.title
}
}
},
watch: {
mutableParams: {
handler() {
console.log('triggered')
}
}
}
}
</script>
<template>
<div>ID: <input v-model="id" /></div>
<div>Post Title: <input v-model="post.title" /></div>
<div>Post Desc: <input v-model="post.desc" /></div>
</template>
但现实往往并没有那么简单。假设我们需要把 Post 表单封装成一个单独的组件：
<!-- PostForm.vue -->
<script>
export default {
props: {
modelValue: {
type: Object,
required: true
}
},
methods: {
emit(key, value) {
this.$emit('update:modelValue', { ...this.modelValue, [key]: value })
}
}
}
</script>
<template>
<div>Post Title: <input :value="modelValue.title" @input="emit('title', $event.target.value)" /></div>
<div>Post Desc: <input :value="modelValue.desc" @input="emit('desc', $event.target.value)" /></div>
</template>
然后用这个组件替换掉上文的例子：
<!-- App.vue -->
...
<template>
<div>ID: <input v-model="id" /></div>
- <div>Post Title: <input v-model="post.title" /></div>
- <div>Post Desc: <input v-model="post.desc" /></div>
+ <post-form v-model="post" />
</template>
看上去一切天衣无缝。但倘若你编辑了 Post 表单的 desc 属性，会发现日志依旧被打出了，即使我们并没有监听 desc 的变化。这显然是与我们的预期不符的。
……
……
相信各位身经百战的读者们很快就能发现问题所在。当 PostForm 封装为组件之后，无论是修改 title 还是 desc ，都会为 post 对象赋一个新值。而 Vue 的 computed 通过依赖收集机制，将 this.post 作为了依赖。一旦 post 对象改变，就会重新触发 computed 生成新的 mutableParams 对象，进而触发 watch 的逻辑。
那么我们该如何解决这个问题呢？
一个显而易见的想法是，既然问题出在每次编辑都会产生一个新的 post 对象，那么我们只要让编辑前后的 post 对象保持不变就可以了。基于这种思路，可做出如下改动：
<!-- PostForm.vue -->
...
methods: {
emit(key, value) {
- this.$emit('update:modelValue', { ...this.modelValue, [key]: value })
+ this.$emit('update:modelValue', Object.assign(this.modelValue, { [key]: value }))
}
}
...
虽然这样解决了问题，但这并不是种好做法。该方法本质上是直接修改了组件 prop 的值，而这是官方文档中明确不推荐的，会让数据流变得混乱。这种场景下我们把对象作为值类型，还是使用不可变数据结构更好一些。
另一个问题是，一个合理的组件设计，调用者只需关注它对外暴露的接口，而无需关心内部实现。但这种情况下不同的内部实现却会影响到外部逻辑的正确性，这显然是不合理的。更何况很多时候我们根本无法控制某个第三方组件的内部实现。
还有个比较简单粗暴的想法是，既然是 watch computed value 引发的问题，那干脆回归到最原始的模式，只 watch primitive value，这样就不用考虑引用变化的问题。在这种做法上 Vue3 有着绝对的优势，因为 Vue3 的 watch API 支持传入多个值：
<!-- App.vue -->
<script setup>
import PostForm from './PostForm.vue'
import {watch, ref} from 'vue'
const id = ref(1)
const post = ref({ title: 'hello world', desc: 'Lorem ipsum' })
watch([() => id.value, () => post.value.title], () => {
console.log('triggered')
})
</script>
在老项目中，如果要一个一个写 watch option 也太蠢了。可以利用 computed + 循环 + $watch 来模拟类似的效果：
mounted() {
Object.keys(this.mutableParams).forEach(key => {
this.$watch(() => this.mutableParams[key], () => {
console.log('triggered')
})
})
}
姑且不提这种做法很不优雅，即使它可以解决示例的这一个问题，但也难以成为一种通用的解决方案。如果我们的 mutableParams 需可动态配置、会增减字段，或是存在更深的嵌套层次等，就很难继续按照这个思路写下去了。
我们还是需要循其本。当我们使用 watch 时，我们期望的效果是当 watch 的目标值变化时触发监听。但 watch 的实现原理是，当目标的依赖变化时触发监听。虽然在绝大多数的情况下两者的效果是相等的，但它们并不是彼此的充要条件。
如果我们监听的目标值发生了变化，那么一定是它的依赖发生了变化，但反过来，当它的依赖发生变化时，并不能推出目标值最终也一定变化了。而这个例外，最容易出现的情况就是在 watch 一个 computed value 时。
严格来说，问题的根源是我们期望的“变化”与代码层面的“变化”定义不同。因此，如果我们能够自定义判断是否“变化”的方法（类似重写 JavaBean 的 equals 方法），这个问题就迎刃而解了。
与 Vue 响应式原理类似的状态管理库 MobX 就内置了类似的方法。在 MobX 中，可以在定义 computed 或 watch 时提供一个自定义的比较函数，如下例所示：
const data = observable({
id: 1,
post: {
title: 'hello world',
desc: 'Lorem ipsum'
}
})
const mutableParams = computed(() => ({
id: data.id,
title: data.post.title
}))
// 相当于 Vue 中的 watch
reaction(
() => mutableParams.get(),
() => console.log('triggered'),
// 对前后的值做一次浅比较，结果不同时才触发监听器逻辑
// 也可以换成深比较，或任何自定义的比较逻辑
{ equals: comparer.shallow }
)
runInAction(() => {
// 不会触发 console.log
data.post = {
title: 'hello world',
desc: 'something else'
}
})
Vue 并没有提供这种开箱即用的内置选项，不过在有了思路之后也很容易自己实现。考虑到无论哪种比较方式的必要条件都是依赖发生变化，我们只需在 watch 内部额外做一层判断即可。
<!-- App.vue -->
...
watch: {
mutableParams: {
handler(newValue, oldValue) {
// equals 是任意的判断相等性的方法
if (!equals(newValue, oldValue)) {
console.log('triggered')
}
}
}
}
...
总的来说不是个很难的问题，不过在复杂项目中偶然遇到一次还是挺搞人心态的。不知为何网上也都找不到相关的讨论，故在此抛砖引玉一下。如果大家有更好的想法，欢迎一起交流~
网友评论