关于vue3 option api新玩法分享

可能一些朋友看到标题，瞬间就不淡定了，vue3+option api，在大家都在使用setup做组合式API的今天，这不就是开历史的倒车吗？别急啊，我们这么做，也是有苦衷的。

这是2个月之前在一篇介绍script setup的文章里面，我发布一个评论。事情就如同评论所说，考虑到成员之间水平不一样，太灵活了，你写代码煮面条我也煮面条，彼此之间反而互相看不懂代码了。那做eslint规范约束吧，约束到最后得到一个长得像option api但效果又没有option api好的规范，最终团队默默退回了option api了。

可能有些朋友还不知道什么是option api，什么是setup吧？这里先简单解释一下，所谓option api，就是vue2的那套写法：

export default {
    data(){
        return {/*...*/}
    },
    methods:{},
    mounted(){}
}

而所谓script setup或者组合式api，是vue3的一个新写法，它允许我们在setup作用域下完成整个页面的逻辑编写：

export default defineComponent({
    setup(){
        const a = ref(0)
        onMounted(()=>{
            a.value = 100
        })
        return {
            a
        }
    }
})

// 或者在<script setup>里面直接写
const a = ref(0)
onMounted(()=>{
    a.value = 100
})

正当我们感叹时代变化真快，团队无法在时代的新潮流玩耍的时候，一个突入其来的bug，为团队成员打开了新思路。

事情是这样的，团队一个成员在做组件集成monaco editor(一个微软开发的代码编辑器组件)的时候，发现退出页面的时候直接将浏览器卡死了。一般浏览器卡死，肯定是js死循环造成的，于是整个团队开始对他的代码进行review，仔细检查每一处循环，查看每一处判断条件，生怕漏了哪一个可能照成判断逃逸导致循环无法停止的地方。

然而他的代码在option api下显得规规矩矩，review起来通俗易懂，在代码实现上找不到可以挑剔的地方。但是卡死浏览器的问题依然存在，总不该是vue3或者是monaco的问题吧？于是祭出注释debug法，从beforeUnmount开始注释掉：

export default defineComponent({
  ...
  beforeUnmount() {
  //   console.log("dispose");
  //   this.edt && this.edt.dispose();
  }
})

this.edt是monaco editor的实例对象。真的是幸运，第一次注释就找到原因，退出页面不卡死了。但是引起浏览器卡死的，是monaco的释放内存？

这肯定不可能，于是我重新读代码，直到眼光放在this.edt的声明上：

export default defineComponent({
  data(){
      return {
          ...
          edt:null as editor.IStandaloneCodeEditor|null
      }
  }
  ...
  mounted(){
      this.edt = editor.create(...)
  }
})

注释掉data里面的edt声明，同时恢复在beforeUnmount时释放内存。这时候ts抛错了，edt在this里面不存在。好在vite并不会理会ts的错误，页面正常运行，退出时也不会引起浏览器卡死。那么答案呼之欲出，罪魁祸首就是你，vue的响应式变量功能！我猜测是monaco的editor实例里有一堆相互引用的属性，原本没有proxy的情况下，销毁就销毁了，但是加上了vue的proxy之后，相互引用层层嵌套导致一直无法销毁造成死循环。

而在vue2写js的时候，这些第三方库都是很随便的用一个运行时this.xxx去挂载。但是vue3对ts的支持加强，团队开始使用ts，之前运行时this.xxx的用法会报错，于是很多成员为了解决这个错误，同时又想获得类型提示，就直接在data里面声明这个属性。

像这次，就是将第三方库操作对象挂载在data里面，恰好跟proxy结合导致bug的发生。既然在没有proxy的环境下执行是正常的，那么option api里有没有可以挂载无响应属性的地方呢？

“为什么不直接挂在setup里面呢？setup里面的变量不加ref的话是没有响应式的，我们不在setup里面写逻辑，不代表我们不能用setup呀。”

团队里面另一位成员一语惊醒梦中人：

export default defineComponent({
  setup(){
      const edt:editor.IStandaloneCodeEditor|null = null
      return {
          edt
      }
  },
  data(){
      return {
          ...
          // edt:null as editor.IStandaloneCodeEditor|null
      }
  }
  ...
  mounted(){
      this.edt = editor.create(...)
  },
  beforeUnmount() {
      console.log("dispose");
      this.edt && this.edt.dispose();
  }
})

这样，ts不报错了，也可以进行类型提示。页面也不卡死了，第三库如愿以偿的在没有proxy的作用下运行。会写hook的同学笑了，后面可以把逻辑抽象到ts里面了。组合式api写不好的同学也没有灰心，因为还是在他熟悉的option api体系下开发，而且可以写得更加出色。

把setup当作option api的一部分，把不会用到模板里的变量挂在setup里，把页面模板会用到的变量挂在data里，而通过this都能访问到两者，也可以为两者提供类型检查。相比vue2来说，团队成员代码里不会再出现运行时挂载最终导致相互覆盖的事情发生，这无疑已经是一个巨大的进步。

这就是我要说的option api的新玩法，也是vue3的新功能。因为团队的不适应，暂时放弃了setup里写逻辑的能力，改用于挂载非响应式变量和抽象出来的hook。

但更重要的是我们要有一个认识，在代码世界里面没有必要把事物对立起来，彼此之间都有长处，那应该是取决于自身的情况把彼此的长处容纳进来，即不要为了新而新，也无须因为旧而排斥，适合自己的才是最好的。

总结

到此这篇关于vue3 option api新玩法的文章就介绍到这了,更多相关vue3 option api新玩法内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论