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

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

在 Vue 3 中，組合式 API 基本上都會配合<script setup>語法在單文件組件中使用。下面是一個使用組合式 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(`計數(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織的代碼：任何東西都有其對應(yīng)的選項(xiàng)來管理。然而，選項(xiàng)式 API 在單個組件的邏輯復(fù)雜到一定程度時，也面臨了一些無法忽視的限制。這些限制主要體現(xiàn)在需要處理多個邏輯關(guān)注點(diǎn)的組件中，在許多 Vue 2 已經(jīng)上線的生產(chǎn)應(yīng)用中可以看到這一點(diǎn)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

可以同時使用兩種 API 嗎？

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

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

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

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

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

最新評論