在這篇文章中,我們將介紹 Vue 提供的兩種 API 風格:選項式(Options API)與組合式(Composition API),這兩種寫法會影響開發時處理邏輯的方式,也會左右整體程式架構與後續維護策略。
在實務開發中,團隊往往會根據需求、過往專案的開發習慣或 Vue 版本的不同,選擇其中一種作為主要開發風格。因此,若能清楚了解兩種 API 的語法差異與設計理念,不僅能更快理解專案程式碼,也能在查閱官方文件📚或學習延伸套件教學時,對應到正確的使用方式 💡。
這篇文章會分享兩種 API 的官方學習資源與核心概念,未來在面對不同類型的專案或閱讀他人程式碼時,能快速理解架構與技術選擇背後的考量。
先來看看要怎麼在官方文件中切換兩種不同的 API 風格。請先前往官方網站,接著在畫面左側找到 API 風格偏好(API Preference)選項,這裡就可以切換不同API風格。
切換後右側的主要內容(例如 程式碼範例、內文說明 等)也會自動更新,對應目前所選擇的風格。
(前往官方文件囉! 圖片來源)
看完官方文件的基本介紹後,如果想練習看看,可以到導覽列找到 Docs 前往 Tutorial ,有 15 項練習範例教學,能帶我們快速認識 Vue 常見且核心的用法。
(下方編號介紹對應圖片中編號 圖片來源)
介紹並說明如何完成這項練習範例,如果在過程中卡關,也可以按左下角「看答案!(Show me!)」按鈕來查看解答。
右上角的「文A」圖示可以切換語言,根據個人需求切換成方便閱讀的語言。
撰寫程式解答練習範例。
可以透過預覽畫面立即檢查成果,看看最後有沒有寫對囉!如果寫錯也會跳提示。
完成 互動教程(Tutorial) 練習的差不多了,可以繼續前往「示例」複習更多用法💪。同樣可以透過API 風格偏好(API Preference)切換不同的 API 風格來閱讀程式碼。
(示例畫面 圖片來源)
從區塊分明的開發方式開始。
Vue 的其中一種API風格,允許開發者透過定義一個選項物件來撰寫元件的邏輯。在選項物件中,元件的邏輯會被組織在不同的選項群組中,例如:
this
,可以在生命週期鉤子裡呼叫,這些函式也可以作為模板中的事件處理器綁定。舉個簡單的Options API範例
<script>
export default {
data() {
return {
count: 0
}
},
methods: {
incrementCount() {
this.count++
}
}
}
</script>
這種 API 風格寫法和 Vue 2 幾乎一樣,但初始化的方式稍有不同。像是 data
、methods
、mounted
等選項物件,依然維持「分區管理」的寫法。白話來講就像是在填寫表單——Vue 已經幫妳準備好欄位與格式,我們只需要把資料填進對應的位置就可以了。
Options API 語意清楚、邏輯結構明確,對初學者友好相對容易理解與上手。在撰寫時,元件的邏輯會圍繞著「元件實例」的概念展開,並透過 this
這個關鍵字來存取元件中定義的資料與方法。
如果本身有 OOP 基礎的開發者,或曾經使用過 Vue 2 開發,這種寫法會比較直覺,因為 Options API 提供一種「類似 OOP 的 class 使用體驗」,以選項分類的結構化 API將響應式邏輯包裝在不同的選項內,並透過明確的欄位引導開發者組織程式碼。
(參考來源 Vue.js TypeScript 與 Options API、 Vue.js Which to Choose?)
邏輯抽取更靈活的模組化寫法
Composition API 是 Vue 的另一組API風格,讓開發者能夠在 Vue 元件直接撰寫邏輯而非宣告選項的方式,這個集合包含了多種類型的 API:
ref()
和 reactive()
),可以直接用於建立響應式狀態、計算屬性和偵聽器。onBeforeMount()
和 onMounted()
),允許開發者在不同階段觸發,進行特定的操作。provide()
與 inject()
函式,讓開發者在 Composition API 中,能夠在不同組件間共享響應式狀態或方法,實現靈活的組件解耦與狀態傳遞。舉個簡單的範例(Composition API + <script setup>
)
<script setup>
import { ref } from 'vue'
const count = ref(0)
function incrementCount() {
count.value++
}
</script>
在 Composition API 的風格中,不需要再像 Options API 那樣把 data
、methods
、mounted
分開寫。它採用的是「基於函式的組合邏輯」,雖然不是函數式程式設計(Functional Programming),但它鼓勵開發者將相關邏輯集中在一起撰寫,讓程式碼的組織性更好,也更利於維護,尤其當元件變得複雜時,這種結構更能顯現優勢。
我們會在單一元件檔案(SFC)搭配 <script setup>
語法來使用,<script setup>
是一個語法糖(就是讓你少寫很多樣板的輔助寫法),它會使 Vue 編譯階段時自動轉換與優化程式碼,例如 變數、函式可以直接寫在檔案最上面,寫完就能在模板裡直接用,連 return
都不用寫,減少重複樣板(boilerplate)。像是在 <script setup>
中定義的變數或函式,能直接在模板中使用,不需要透過 return
或 this
,簡化撰寫流程。
這種風格讓功能邏輯更模組化、集中管理,進而提升元件的可讀性與可維護性,特別適合大型專案或多人協作情境。
跟剛剛介紹的選項式 API 不同,組合式 API 不再是「填寫表單」照著欄位填寫資料的方式,而比較像是「組裝樂高積木」的感覺~透過 Vue 提供的函式去組裝元件資料與邏輯。把元件依照需求一塊塊拼湊起來,靈活又具彈性。
(參考來源 Composition API 常見問答、Vue.js TypeScript 與 Composition API)
最後重點統整優缺點,資訊如下表格:
這兩種 API 風格的產生反應了 Vue 在不同階段的設計考量和對應的優先順序,下面來分別來介紹它們各自的特性:
Composition API 是一種更直接的應用,提供更靈活、可擴展的開發體驗。
總結來說,Vue 同時保留了這兩種風格,讓開發者可以依據專案規模和需求,選擇最合適的開發模式。雖然Options API設計風格較接近早期Vue版本的使用方式,但Vue官方也明確表示,並不會廢棄Options API的設計,選項式 API 依然是 Vue 不可或缺的一部份(參考來源 選項式 API 會被廢棄嗎?)。兩種API雖然風格不同,但它們實際上是基於相同的底層系統運行的,只是提供了不同的開發介面,所以兩種 API 風格都學起來也是不錯的選擇 (來個雙刀流不好嗎😏)。
從開發團隊習慣、專案需求、擴充性與維護成本等角度出發去評估,這兩種API風格是採用同一種底層系統,只是寫法與串接函式的方法不同,假設公司開發團隊的專案,是要從Vue2開始重構或升級版本,建議可以採用Options API,這種API風格寫法上跟Vue2比較像。如果團隊是習慣自由的像平常寫JavaScript一樣,直接用變數、函式、模組來組織邏輯,且一個元件裡可能會同時處理很多不同的功能區塊那Composition API 會比 Options API 更適合做使用。
所以結論是:還是要看團隊的習慣還有專案規模與需求做決定!! 理解了兩種API風格後,就可以好好地與團隊討論,選擇最適合目前專案需求的開發風格🌟!
在這篇文章中,我們一次掌握了 Vue 中兩種 API 的設計思維與寫法差異,也練習了如何從官方文件切換並閱讀不同風格的程式碼。在實務開發中,「能夠寫出功能」是第一步,更重要的是能依據專案需求,判斷「在什麼情境下,該採用哪一種做法」,不論選擇 Options API 還是 Composition API,每一種都代表著某種架構思維與溝通方式。
下一篇我們將說明如何建立「LINE Login」與「Messaging API」,一步一步往網站功能完成邁進吧✨!
⑴ Vue 官方網站
⑵ 物件導向程式設計(OOP) 延伸參考來源
⑶ Vue.js TypeScript 與 Options API
⑷ Vue.js 官方介紹 Which to Choose?
⑸ Composition API 常見問答
⑹ Vue.js TypeScript 與 Composition API
⑺ 圖片說明 Tutorial 來源:vuejs
⑻ 圖片說明示例來源:vuejs