各位五一快乐,最近工作比较忙,来拿点工作中遇到的问题水一水。在 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')
}
}
}
}
...
总的来说不是个很难的问题,不过在复杂项目中偶然遇到一次还是挺搞人心态的。不知为何网上也都找不到相关的讨论,故在此抛砖引玉一下。如果大家有更好的想法,欢迎一起交流~