可能一些朋友看到標(biāo)題，瞬間就不淡定了，vue3+option api，在大家都在使用setup做組合式API的今天，這不就是開歷史的倒車嗎？別急啊，我們這么做，也是有苦衷的。

這是2個(gè)月之前在一篇介紹script setup的文章里面，我發(fā)布一個(gè)評(píng)論。事情就如同評(píng)論所說，考慮到成員之間水平不一樣，太靈活了，你寫代碼煮面條我也煮面條，彼此之間反而互相看不懂代碼了。那做eslint規(guī)范約束吧，約束到最后得到一個(gè)長(zhǎng)得像option api但效果又沒有option api好的規(guī)范，最終團(tuán)隊(duì)默默退回了option api了。

可能有些朋友還不知道什么是option api，什么是setup吧？這里先簡(jiǎn)單解釋一下，所謂option api，就是vue2的那套寫法：

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

而所謂script setup或者組合式api，是vue3的一個(gè)新寫法，它允許我們?cè)趕etup作用域下完成整個(gè)頁(yè)面的邏輯編寫：

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

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

正當(dāng)我們感嘆時(shí)代變化真快，團(tuán)隊(duì)無法在時(shí)代的新潮流玩耍的時(shí)候，一個(gè)突入其來的bug，為團(tuán)隊(duì)成員打開了新思路。

事情是這樣的，團(tuán)隊(duì)一個(gè)成員在做組件集成monaco editor(一個(gè)微軟開發(fā)的代碼編輯器組件)的時(shí)候，發(fā)現(xiàn)退出頁(yè)面的時(shí)候直接將瀏覽器卡死了。一般瀏覽器卡死，肯定是js死循環(huán)造成的，于是整個(gè)團(tuán)隊(duì)開始對(duì)他的代碼進(jìn)行review，仔細(xì)檢查每一處循環(huán)，查看每一處判斷條件，生怕漏了哪一個(gè)可能照成判斷逃逸導(dǎo)致循環(huán)無法停止的地方。

然而他的代碼在option api下顯得規(guī)規(guī)矩矩，review起來通俗易懂，在代碼實(shí)現(xiàn)上找不到可以挑剔的地方。但是卡死瀏覽器的問題依然存在，總不該是vue3或者是monaco的問題吧？于是祭出注釋debug法，從beforeUnmount開始注釋掉：

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

this.edt是monaco editor的實(shí)例對(duì)象。真的是幸運(yùn)，第一次注釋就找到原因，退出頁(yè)面不卡死了。但是引起瀏覽器卡死的，是monaco的釋放內(nèi)存？

這肯定不可能，于是我重新讀代碼，直到眼光放在this.edt的聲明上：

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

注釋掉data里面的edt聲明，同時(shí)恢復(fù)在beforeUnmount時(shí)釋放內(nèi)存。這時(shí)候ts拋錯(cuò)了，edt在this里面不存在。好在vite并不會(huì)理會(huì)ts的錯(cuò)誤，頁(yè)面正常運(yùn)行，退出時(shí)也不會(huì)引起瀏覽器卡死。那么答案呼之欲出，罪魁禍?zhǔn)拙褪悄?，vue的響應(yīng)式變量功能！我猜測(cè)是monaco的editor實(shí)例里有一堆相互引用的屬性，原本沒有proxy的情況下，銷毀就銷毀了，但是加上了vue的proxy之后，相互引用層層嵌套導(dǎo)致一直無法銷毀造成死循環(huán)。

而在vue2寫js的時(shí)候，這些第三方庫(kù)都是很隨便的用一個(gè)運(yùn)行時(shí)this.xxx去掛載。但是vue3對(duì)ts的支持加強(qiáng)，團(tuán)隊(duì)開始使用ts，之前運(yùn)行時(shí)this.xxx的用法會(huì)報(bào)錯(cuò)，于是很多成員為了解決這個(gè)錯(cuò)誤，同時(shí)又想獲得類型提示，就直接在data里面聲明這個(gè)屬性。

像這次，就是將第三方庫(kù)操作對(duì)象掛載在data里面，恰好跟proxy結(jié)合導(dǎo)致bug的發(fā)生。既然在沒有proxy的環(huán)境下執(zhí)行是正常的，那么option api里有沒有可以掛載無響應(yīng)屬性的地方呢？

“為什么不直接掛在setup里面呢？setup里面的變量不加ref的話是沒有響應(yīng)式的，我們不在setup里面寫邏輯，不代表我們不能用setup呀。”

團(tuán)隊(duì)里面另一位成員一語(yǔ)驚醒夢(mèng)中人：

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不報(bào)錯(cuò)了，也可以進(jìn)行類型提示。頁(yè)面也不卡死了，第三庫(kù)如愿以償?shù)脑跊]有proxy的作用下運(yùn)行。會(huì)寫hook的同學(xué)笑了，后面可以把邏輯抽象到ts里面了。組合式api寫不好的同學(xué)也沒有灰心，因?yàn)檫€是在他熟悉的option api體系下開發(fā)，而且可以寫得更加出色。

把setup當(dāng)作option api的一部分，把不會(huì)用到模板里的變量掛在setup里，把頁(yè)面模板會(huì)用到的變量掛在data里，而通過this都能訪問到兩者，也可以為兩者提供類型檢查。相比vue2來說，團(tuán)隊(duì)成員代碼里不會(huì)再出現(xiàn)運(yùn)行時(shí)掛載最終導(dǎo)致相互覆蓋的事情發(fā)生，這無疑已經(jīng)是一個(gè)巨大的進(jìn)步。

這就是我要說的option api的新玩法，也是vue3的新功能。因?yàn)閳F(tuán)隊(duì)的不適應(yīng)，暫時(shí)放棄了setup里寫邏輯的能力，改用于掛載非響應(yīng)式變量和抽象出來的hook。

但更重要的是我們要有一個(gè)認(rèn)識(shí)，在代碼世界里面沒有必要把事物對(duì)立起來，彼此之間都有長(zhǎng)處，那應(yīng)該是取決于自身的情況把彼此的長(zhǎng)處容納進(jìn)來，即不要為了新而新，也無須因?yàn)榕f而排斥，適合自己的才是最好的。

總結(jié)

到此這篇關(guān)于vue3 option api新玩法的文章就介紹到這了,更多相關(guān)vue3 option api新玩法內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論