組合式 API 是一系列 API 的集合，使我們可以使用函數(shù)而不是聲明選項(xiàng)的方式書寫 Vue 組件。它是一個(gè)概括性的術(shù)語，涵蓋了以下方面的 API：

• 響應(yīng)性 API：例如ref()和reactive()，使我們可以直接創(chuàng)建響應(yīng)式狀態(tài)、計(jì)算屬性和偵聽器。
• 生命周期鉤子：例如onMounted()和onUnmounted()，使我們可以在組件各個(gè)生命周期階段添加邏輯。
• 依賴注入：例如provide()和inject()，使我們可以在使用響應(yīng)性 API 時(shí)，利用 Vue 的依賴注入系統(tǒng)。

在 Vue 3 中，組合式 API 基本上都會(huì)配合<script setup>語法在單文件組件中使用。下面是一個(gè)使用組合式 API 的組件示例：

<script setup>
import { ref, onMounted } from 'vue'
// 響應(yīng)式狀態(tài)
const count = ref(0)

// 更改狀態(tài)、觸發(fā)更新的函數(shù)
function increment() {
  count.value++
}
// 生命周期鉤子
onMounted(() => {
  console.log(`計(jì)數(shù)器初始值為 ${count.value}。`)
})
</script>

<template>
  <button @click="increment">點(diǎn)擊了：{{ count }} 次</button>
</template>

雖然這套 API 的風(fēng)格是基于函數(shù)的組合，但組合式 API 并不是函數(shù)式編程。組合式 API 是以 Vue 中數(shù)據(jù)可變的、細(xì)粒度的響應(yīng)性系統(tǒng)為基礎(chǔ)的，而函數(shù)式編程更強(qiáng)調(diào)數(shù)據(jù)不可變。

為什么要有組合式 API？

更好的邏輯復(fù)用

組合式 API 最基本的優(yōu)勢是它使我們能夠通過組合函數(shù)來實(shí)現(xiàn)更加簡潔高效的邏輯復(fù)用。它解決了所有mixins的缺陷，那是選項(xiàng)式 API 中一種邏輯復(fù)用機(jī)制。

更靈活的代碼組織

許多用戶都喜歡選項(xiàng)式 API，因?yàn)樵谀J(rèn)情況下就能夠?qū)懗鲇薪M織的代碼：任何東西都有其對(duì)應(yīng)的選項(xiàng)來管理。然而，選項(xiàng)式 API 在單個(gè)組件的邏輯復(fù)雜到一定程度時(shí)，也面臨了一些無法忽視的限制。這些限制主要體現(xiàn)在需要處理多個(gè)邏輯關(guān)注點(diǎn)的組件中，在許多 Vue 2 已經(jīng)上線的生產(chǎn)應(yīng)用中可以看到這一點(diǎn)。

我們以 Vue CLI GUI 中的文件瀏覽器組件為例：這個(gè)組件承擔(dān)了以下幾個(gè)邏輯關(guān)注點(diǎn)：

• 追蹤當(dāng)前文件夾的狀態(tài)，展示其內(nèi)容
• 處理文件夾的相關(guān)操作(打開、關(guān)閉和刷新)
• 支持創(chuàng)建新文件夾
• 可以切換到只展示收藏的文件夾
• 可以開啟對(duì)隱藏文件夾的展示
• 處理當(dāng)前工作目錄中的變更

這個(gè)組件最原始的版本是由選項(xiàng)式 API 寫成的。而如果用組合式 API 重構(gòu)這個(gè)組件，將會(huì)變成：

現(xiàn)在與同一個(gè)邏輯關(guān)注點(diǎn)相關(guān)的代碼被歸為了一組：我們無需再為了一個(gè)邏輯關(guān)注點(diǎn)在不同的選項(xiàng)塊間來回滾動(dòng)切換。此外，我們現(xiàn)在可以不費(fèi)吹灰之力地將這一組代碼移動(dòng)到一個(gè)外部文件中，不再需要為了抽象而重新組織代碼，大大降低了重構(gòu)成本，這在長期維護(hù)的大型項(xiàng)目中非常關(guān)鍵。

更好的類型推導(dǎo)

近幾年來，越來越多的開發(fā)者開始使用TypeScript書寫更健壯可靠的代碼，TypeScript還提供了非常好的IDE 開發(fā)支持。然而選項(xiàng)式 API 是在 2013

年創(chuàng)建的，那時(shí)并沒有想到需要進(jìn)行類型推導(dǎo)。因此我們做了一些荒謬復(fù)雜的類型體操來實(shí)現(xiàn)對(duì)選項(xiàng)式 API 的類型推導(dǎo)。但盡管做了這么多的努力，選項(xiàng)式 API 的類型推導(dǎo)仍然無法適配混入和依賴注入。

因此，很多想要搭配 TS 使用 Vue 的開發(fā)者采用了由vue-class-component提供的Class API。然而，基于 Class 的 API 非常依賴 ES 裝飾器，在 Vue 2019 年開發(fā)完成后，它仍是一個(gè)僅處于 vue 2的語言功能。我們認(rèn)為將這樣一種不穩(wěn)定的方案作為官方 API 的一種實(shí)現(xiàn)形式風(fēng)險(xiǎn)過高，在那之后裝飾器提案還進(jìn)行了一些較大的變動(dòng)，在書寫這篇文檔時(shí)仍未到達(dá) vue 3。另外，基于 Class 的 API 和選項(xiàng)式 API 在邏輯復(fù)用和代碼組織方面有相同的限制。

相比之下，組合式 API 主要利用基本的變量和函數(shù)，它們本身就是類型友好的。用組合式 API 重寫的代碼可以享受到完整的類型推導(dǎo)，不需要書寫太多類型標(biāo)注。大多數(shù)時(shí)候，用 TypeScript 書寫的組合式 API 代碼和用 JavaScript 寫都差不太多！這也同樣讓許多純 JavaScript 用戶能從IDE 中享受到部分類型推導(dǎo)功能。

生產(chǎn)包體積更小

搭配<script setup>使用組合式 API 比等價(jià)情況下的選項(xiàng)式 API 更高效，對(duì)代碼壓縮也更友好。這是由于<script setup>;形式書寫的組件模板被編譯為了一個(gè)內(nèi)連函數(shù)，和<script setup>中的代碼位于同一作用域。不像選項(xiàng)式 API 需要依賴this上下文對(duì)象訪問屬性，被編譯的模板可以直接訪問<script setup>中定義的變量，無需一個(gè)代碼實(shí)例從中代理。這對(duì)代碼壓縮更友好，因?yàn)樽兞康拿挚梢宰兊酶?，但?duì)象的屬性名則不能。

與選項(xiàng)式 API 的關(guān)系

組合式 API 是否覆蓋了所有場景？

對(duì)于有狀態(tài)的邏輯來說，的確如此。當(dāng)使用組合式 API 時(shí)，只需要用到一小部分選項(xiàng)：props，emits，name和inheritAttrs。如果使用<script setup>，那么inheritAttrs應(yīng)該是唯一一個(gè)需要用額外的<script>塊書寫的選項(xiàng)了。

如果你在代碼中只使用了組合式 API(以及上述必需的選項(xiàng))，得益于編譯時(shí)標(biāo)記你可以減小生產(chǎn)包大概幾 kb 左右的體積，因?yàn)閬G掉了 Vue 之中關(guān)于選項(xiàng)式 API 的所有代碼。注意這也會(huì)影響你依賴中的 Vue 組件。

可以同時(shí)使用兩種 API 嗎？

可以。你可以在一個(gè)選項(xiàng)式 API 組件中使用setup()選項(xiàng)。

然而，我們只推薦你在就舊項(xiàng)目中這樣使用。它們長期基于選項(xiàng)式 API 開發(fā)、又可能想要集成新的功能，或是想要集成基于組合式 API 的第三方庫。

選項(xiàng)式 API 會(huì)被廢棄嗎？

不會(huì)，我們沒有任何計(jì)劃這樣做。選項(xiàng)式 API 也是 Vue 不可分割的一部分，也有很多開發(fā)者喜歡它。我們也意識(shí)到組合式 API 主要適用于非常大型的項(xiàng)目，而對(duì)于中小型項(xiàng)目來說選項(xiàng)式 API 仍然是一個(gè)不錯(cuò)的選擇。

到此這篇關(guān)于什么是Vue3的組合式 API的文章就介紹到這了,更多相關(guān)Vue3組合式 API內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論