请不要在 Vue 中滥用“watch”功能，拜托了！
请不要在 Vue 中滥用“watch”功能，拜托了！
随着Vue 3 Composition API风格的普及，使用watch的成本越来越低。现在，我们可以在任何地方使用watch来监听响应式数据。然而，随着业务的推进，你可能会在代码中看到大量的watch。当你接手修改这些充满watch的代码时，我相信你心里肯定会感到非常困惑和无奈。
真实案例剖析
让我们来看一个真实的代码案例：
在上面的示例中，dataList在template中进行渲染。当props.id初始化或者更新时，dataList将进行更新；当props.disableList或props.type更新时，又会触发dataList的更新。上述的过程可以简化成下面的流程图：
我们猛地一看，好像并没有什么大问题，但是当我们几个月之后回来再改这段代码的时候，就会发现这里面的问题了。我们以dataList变量为例，追根溯源来理清这个组件的业务逻辑。
在上述示例代码中，dataList的数据更新会和多个数据的变化相关，首先，它通过props.id上的watch从服务器异步更新。然后，它通过props.disableList和props.type上的watch同步更新。
如果有新的需求需要更新dataList的逻辑，在更新之前，我们必须要理清楚更新的逻辑，这样才能避免改动引发。但是事实却是相反，在我们实践编写代码中，特别是当维护别人的代码（尤其是复杂的代码）时，我们通常不喜欢修改现有的代码，而是在上面添加自己的代码。更改别人的复杂代码可能会触发改动引发，因此，我们通常最保险的做法是添加另一个watch并在那里实现dataList的最新业务逻辑：
但是这样操作的话，经过几次迭代后，这个vue文件变得混乱，充满了许多watch语句，导致了“屎山代码”。当然，这种代码的编写过程也被视为 “防御性编程”。
解决方案
看到前面示例的缺点后，静下心思考一下🤔， 到底可维护的代码应该是什么样的？在我看来，它应该看起来像这样：dataList在template中渲染，然后同步更新dataList，最后从服务器异步获取dataList。整个过程可以可视化为单个线程。现在我们可以尝试进行优化上面的示例。
首先我们梳理一下，代码中dataList的同步变更和异步变更。我们无法更改异步变更，因为从业务角度来看，props.id更新后，就必须要从后端获取新的dataList。但是我们可以将同步变更中的所有代码堆叠到computed中。优化后的代码如下：
在template中，我们不再渲染dataList变量，而是渲染renderDataList。renderDataList是一个computed，其中包含dataList的所有同步相关逻辑。代码逻辑流程图如下：
现在dataList相关的业务逻辑现在已经变成了线性序列。故我们可以做如下调整：
小结
我们在正常的业务代码编写中，应该避免同步和异步更新都乱写在watch中，否则后续维护dataList变量的相关逻辑就会非常痛苦。到时候，watch到处更新dataList值，你完全理不清楚这个值到底因为什么变化而变化。所以我们在日常编码的时候，就应该将数据的来源区分成同步变更还是异步变更。多使用computed计算属性，尽量避免使用watch监听器。