背景
事情是这样的，我的组员在写一个项目，项目里有一个 Home.vue 页面，大概结构是这样，Home.vue 就是本项目的首页，项目初始化后加载的顺序是 App.vue -> Home.vue
image.png
在 App.vue 加载的时候，项目需要去请求本项目所需要使用到的字典，这部分逻辑写在了 Pinia 中，大概代码如下
image.png
接着会在 App.vue 的 onMounted 中去执行 setup 方法，去请求所有字典，这应该也是很多项目中初始化数据的方式~
image.png
接着，在 Home.vue 初始化的时候，需要去使用这些字典去完成某些操作，且只是初始化时需要完成这个操作
image.png
我们到控制台中看到，确实能获取到所有字典，那就说明没问题了吗？？？？？
image.png
生产事故
问题来了，昨天服务器不知道咋的，字典接口响应很慢，差不多有2秒，我们可以来模拟一下，看看什么效果，我这里使用 setTimeout 来模拟请求2秒
image.png
好，现在来看看 Home.vue 里输出了什么
image.png
完蛋，Home.vue 初始化时拿不到数据，做不了对应操作，在发版日的晚上12点的时候，测试那边反馈了这个 BUG，我马上赶过去看了一下，马上就看出了问题所在，其实很多人也能看出来
因为请求太久了，导致 Home.vue 在 onMounted 时拿不到数据，执行不了后续操作，导致页面 BUG
解决问题
我并没有急，我让我的组员自己想想应该怎么解决，锻炼一下他解决问题的能力，他觉得加个 watch 是不是就可以了！！！
image.png
但是可惜的是，并不会触发监听，只能换一种办法，他查了一下百度，说可以用 Pinia 的 $subscribe 方法，就可以监听 Pinia 数据的变化了~
image.png
看看效果，确实能监听到变化，但是变化了几次就会执行几次啊，他说那就用防抖去做。。。。
image.png
我说防抖也有问题啊。。比如我们只需要 setup 执行后引起的变化监听，而不需要其他，就比如这个 otherSetup 也会引起变化监听，但我们并不想要这次变化
image.png
这种写法的不确定性太大了，而且不太合理，肯定不能这么写啊！！！
巧用 Promise
最后还是我帮他解决的，我觉得问题有两个：
- 1、组员在做项目的时候没考虑兜底
- 2、组件的基础不够扎实
在做这种需求的时候肯定要考虑到请求响应慢的时候的兜底啊，不能想当然。再有就是基础不够扎实，这种场景一看就可以使用 Promise 去兜底
我先封装一个函数，这函数返回两个东西
- readyResolve： 一个resolve函数
- onReady： 接收回调函数，只有在readyResolve执行后才会执行
image.png
接着回到 Pinia 文件中，首先将 onReady 暴露出去
image.png
接着在 setup 执行完的时候去执行 readyResolve 函数，为了提高可读性，我这里使用 Promise.all 代替之前的写法
image.png
然后到 Home.vue 页面中，只需要往 onTestStoreSteuped 中传回调函数即可
image.png
最终达到了想要的效果，无论请求多久，Home.vue 中的操作始终能在请求之后去执行
image.png
而且这样做的好处就是，无论你有多少页面需要使用请求后的数据，都可以往 onTestStoreSteuped 中传回调，请求完都会一一执行的~
通过这次的生产事故，我告诫组员们，平时学的东西要在开发项目中想一下怎么应用，而不是只是死记硬背，没有实践，那么这样只会是纸上谈兵罢了，没啥卵用，应付应付面试可能可以，做项目写的代码质量不会高的~
作者：Sunshine_Lin
链接：
https://juejin.cn/post/7306423214493237282
网友评论