答应我，在vue中不要滥用watch好吗？.docxVIP

第

答应我，在vue中不要滥用watch好吗？

上周五晚上8点，开开心心的等着产品验收完毕后就可以顺利上线。结果产品突然找到我说要加需求，并且维护这一块业务的同事已经下班走了，所以只有我来做。虽然内心一万头草泥马在狂奔，但是嘴里还是一口答应没问题。由于这一块业务很复杂并且我也不熟悉，加上还饿着肚子，在梳理代码逻辑的时候我差点崩溃了。需要修改的那个vue文件有几千行代码，迭代业务对应的ref变量有10多个watch。我光是梳理这些watch的逻辑就搞了很久，然后小心翼翼的在原有代码上面加上新的业务逻辑，不敢去修改原有逻辑（担心搞出线上bug背锅）。

滥用watch带来的问题

首先我们来看一个例子：

template

{{dataList}}

/template

scriptsetuplang=ts

import{ref,watch}fromvue

constdataList=ref([]);

constprops=defineProps([disableList,type,id]);

watch(

()=props.disableList,

()={

//根据disableList逻辑很复杂同步计算出新list

constnewList=getListFromDisabledList(dataList.value);

dataList.value=newList;

{deep:true}

watch(

()=props.type,

()={

//根据type逻辑很复杂同步计算出新list

constnewList=getListFromType(dataList.value);

dataList.value=newList;

watch(

()=props.id,

()={

//从服务端获取dataList

fetchDataList();

{immediate:true}

/script

上面这个例子在template中渲染了dataList，当props.id更新时和初始化时从服务端异步获取dataList。当props.disableList和props.type更新时，同步的计算出新的dataList。

代码逻辑流程图是这样的：

乍一看上面的代码没什么问题，但是当一个不熟悉这一块业务的新同学接手这一块代码时问题就出来了。

我们平时接手一个不熟悉的业务首先要找一个切入点，对于前端业务，切入点肯定是浏览器渲染的页面。在Vue中，页面由模板渲染而来，找到模板中使用的响应式变量和他的来源，就能理解业务逻辑。以dataList变量为例，梳理dataList的来源基本就可以理清业务逻辑。

在我们上面的这个例子dataList的来源就是发散的，有很多个来源。首先是watch了props.id从服务端异步获取。然后是watch了props.disableList和props.type，同步更新了dataList。这个时候一个不熟悉业务的同学接到产品需求要更新dataList的取值逻辑，他需要先熟悉dataList多个来源的取值逻辑，熟悉完逻辑后再分析我到底应该是在哪个watch上面去修改业务逻辑完成产品需求。

但是实际上我们维护别人的代码时（特别是很复杂的代码）一般都不愿意去改代码，而是在原有代码的基础上再去加上我们的代码。因为去改别人的复杂代码很容易搞出线上bug，然后背锅。所以在这里我们的做法一般都是再加一个watch，然后在这个watch中去实现产品最新的dataList业务逻辑。

watch(

()=props.xxx,

()={

//加上产品最新的业务逻辑

constnewList=getListFromXxx(dataList.value);

dataList.value=newList;

迭代几次业务后这个vue文件里面就变成了一堆watch，屎山代码就是这样形成的。当然不排除有的情况是故意这样写的，为的就是稳定自己在团队里面的地位，因为离开了你这坨代码没人敢动。

使用computed解决问题

我们看了上面的反例，那么一个易维护的代码是怎么样的呢？我认为应该是下面这样的：

dataList在template中渲染，然后同步更新dataList，最后异步从服务端异步获取dataList，整个过程能够被穿成一条线。此时新来