iT邦幫忙

2025 iThome 鐵人賽

DAY 13
0
Modern Web

設計 x 開發:從 Figma 到 Vue,打造 LINE 互動形象網站!系列 第 13

13 Vue 3 兩種 API 寫法一次搞懂:Options vs Composition 怎麼選?

  • 分享至 

  • xImage
  •  

前言

在這篇文章中,我們將介紹 Vue 提供的兩種 API 風格:選項式(Options API)與組合式(Composition API),這兩種寫法會影響開發時處理邏輯的方式,也會左右整體程式架構與後續維護策略。

在實務開發中,團隊往往會根據需求、過往專案的開發習慣或 Vue 版本的不同,選擇其中一種作為主要開發風格。因此,若能清楚了解兩種 API 的語法差異與設計理念,不僅能更快理解專案程式碼,也能在查閱官方文件📚或學習延伸套件教學時,對應到正確的使用方式 💡。

這篇文章會分享兩種 API 的官方學習資源與核心概念,未來在面對不同類型的專案或閱讀他人程式碼時,能快速理解架構與技術選擇背後的考量。

最實用的步驟1. 要怎麼閱讀官方文件

先來看看要怎麼在官方文件中切換兩種不同的 API 風格。請先前往官方網站,接著在畫面左側找到 API 風格偏好(API Preference)選項,這裡就可以切換不同API風格。
切換後右側的主要內容(例如 程式碼範例、內文說明 等)也會自動更新,對應目前所選擇的風格。
13 Vue 3 兩種 API 寫法一次搞懂:Options vs Composition 怎麼選? - 圖示1
(前往官方文件囉! 圖片來源

看完官方文件的基本介紹後,如果想練習看看,可以到導覽列找到 Docs 前往 Tutorial ,有 15 項練習範例教學,能帶我們快速認識 Vue 常見且核心的用法。
13 Vue 3 兩種 API 寫法一次搞懂:Options vs Composition 怎麼選?- 圖示2
(下方編號介紹對應圖片中編號 圖片來源

1. API Preference 功能介紹

  • Options/Composition:可以切換兩種API風格。
  • HTML/SFC:單一元件檔案切換為原始的HTML會呈現什麼樣子 (呈現位置 3. )。

2. 題目說明

介紹並說明如何完成這項練習範例,如果在過程中卡關,也可以按左下角「看答案!(Show me!)」按鈕來查看解答。
右上角的「文A」圖示可以切換語言,根據個人需求切換成方便閱讀的語言。

3. 程式碼內容

撰寫程式解答練習範例。

  • Show Error:編輯器會即時檢查語法錯誤並跳出提示,不過在撰寫未完成時可能會出現預期中的錯誤訊息,如果覺得干擾,也可以先關閉這個功能。
  • Auto Save:切換是否要自動儲存變更。若關閉自動儲存,仍可使用「CTRL + S」手動儲存,就像平常在編輯器中開發時一樣。

4. 即時預覽結果

可以透過預覽畫面立即檢查成果,看看最後有沒有寫對囉!如果寫錯也會跳提示。

完成 互動教程(Tutorial) 練習的差不多了,可以繼續前往「示例」複習更多用法💪。同樣可以透過API 風格偏好(API Preference)切換不同的 API 風格來閱讀程式碼。
13 Vue 3 兩種 API 寫法一次搞懂:Options vs Composition 怎麼選? - 圖示3
(示例畫面 圖片來源

初次認識 Vue 的兩種 API 風格

1. 選項式 API(Options API)

從區塊分明的開發方式開始。

Vue 的其中一種API風格,允許開發者透過定義一個選項物件來撰寫元件的邏輯。在選項物件中,元件的邏輯會被組織在不同的選項群組中,例如:

  • data():用來定義響應式和回傳物件的函式,物件中的屬性會被 Vue 代理到元件實例的 this 上。
  • methods:用來宣告要掛在元件實例上的函式,會自動綁定到元件的 this,可以在生命週期鉤子裡呼叫,這些函式也可以作為模板中的事件處理器綁定。
  • mounted():Options API掛載階段的其中一種生命週期鉤子,會在元件掛載完成後被呼叫,其他關於生命週期鉤子更詳細的介紹可參考第十二篇
  • 其他選項還包括 props、emits、computed 等,用來定義元件外部可傳入的屬性、觸發的事件和計算屬性。

舉個簡單的Options API範例

<script>
	export default {
	    data() {
	        return {
	            count: 0
	        }
	    },
	    methods: {
	        incrementCount() {
	            this.count++
	        }
	    }
	}
</script>

這種 API 風格寫法和 Vue 2 幾乎一樣,但初始化的方式稍有不同。像是 datamethodsmounted 等選項物件,依然維持「分區管理」的寫法。白話來講就像是在填寫表單——Vue 已經幫妳準備好欄位與格式,我們只需要把資料填進對應的位置就可以了。
Options API 語意清楚、邏輯結構明確,對初學者友好相對容易理解與上手。在撰寫時,元件的邏輯會圍繞著「元件實例」的概念展開,並透過 this 這個關鍵字來存取元件中定義的資料與方法。
如果本身有 OOP 基礎的開發者,或曾經使用過 Vue 2 開發,這種寫法會比較直覺,因為 Options API 提供一種「類似 OOP 的 class 使用體驗」,以選項分類的結構化 API將響應式邏輯包裝在不同的選項內,並透過明確的欄位引導開發者組織程式碼。

(參考來源 Vue.js TypeScript 與 Options APIVue.js Which to Choose?)

2. 組合式 API(Composition API)

邏輯抽取更靈活的模組化寫法

Composition API 是 Vue 的另一組API風格,讓開發者能夠在 Vue 元件直接撰寫邏輯而非宣告選項的方式,這個集合包含了多種類型的 API:

  • 響應式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 那樣把 datamethodsmounted 分開寫。它採用的是「基於函式的組合邏輯」,雖然不是函數式程式設計(Functional Programming),但它鼓勵開發者將相關邏輯集中在一起撰寫,讓程式碼的組織性更好,也更利於維護,尤其當元件變得複雜時,這種結構更能顯現優勢。

我們會在單一元件檔案(SFC)搭配 <script setup> 語法來使用,<script setup> 是一個語法糖(就是讓你少寫很多樣板的輔助寫法),它會使 Vue 編譯階段時自動轉換與優化程式碼,例如 變數、函式可以直接寫在檔案最上面,寫完就能在模板裡直接用,連 return 都不用寫,減少重複樣板(boilerplate)。像是在 <script setup> 中定義的變數或函式,能直接在模板中使用,不需要透過 returnthis,簡化撰寫流程。
這種風格讓功能邏輯更模組化、集中管理,進而提升元件的可讀性與可維護性,特別適合大型專案或多人協作情境。

跟剛剛介紹的選項式 API 不同,組合式 API 不再是「填寫表單」照著欄位填寫資料的方式,而比較像是「組裝樂高積木」的感覺~透過 Vue 提供的函式去組裝元件資料與邏輯。把元件依照需求一塊塊拼湊起來,靈活又具彈性。

(參考來源 Composition API 常見問答Vue.js TypeScript 與 Composition API)

Options API 與 Composition API 的優缺點整理

最後重點統整優缺點,資訊如下表格:
表格彙整

為什麼會有這兩種寫法,它們背後的特性是什麼?

這兩種 API 風格的產生反應了 Vue 在不同階段的設計考量和對應的優先順序,下面來分別來介紹它們各自的特性:

Options API的特性

  • Options API是Vue早期設計的核心,主旨在提供一個容易理解與學習的程式設計模式。
  • 用預先定義的選項將組件的邏輯、資料、方法等分開,強調了程式碼的組織性 (參考來源 與選項式 API 的關係),對於小型至中型專案來說,這樣的結構已能提供良好的開發流程與架構
  • 對於那些習慣物體導向程式設計(OOP)類別概念的開發者來說,選項式 API 相對更容易上手。

Composition API的特性

  • Composition API 的引入是為了解決 Options API 在處理大型、複雜專案時所面臨的限制,特別是在邏輯復用、程式碼組織和 TypeScript 支援方面,它的目的是提供允許強大的邏輯組織能力,開發者將相關的邏輯關注點聚集在一起,即使組件變得非常龐大,也能更保持程序碼的區別性和可維護性 (參考來源 更靈活的程式組織)。
  • Composition API 採用以函式為主的寫法,讓 TypeScript 更容易判斷型別,不需要開發者自己手動標註太多型別。這樣可以寫出更穩定、更不容易出錯的程式碼,同時也能享受到 IDE(例如 VSCode 等)更完整的自動補全與錯誤提示功能 (參考來源 更好的類型推導)。
  • 也讓「把程式裡相似的邏輯拿出來重複使用」這件事變得更簡單(例如 登入檢查不同元件都會用到 等)。Vue 的響應式系統也因為這樣變得更有彈性,能夠更容易跟第三方狀態管理庫(例如 Pinia 等)一起搭配使用上更順暢。 (參考來源 邏輯複用)。

Composition API 是一種更直接的應用,提供更靈活、可擴展的開發體驗。

總結來說,Vue 同時保留了這兩種風格,讓開發者可以依據專案規模和需求,選擇最合適的開發模式。雖然Options API設計風格較接近早期Vue版本的使用方式,但Vue官方也明確表示,並不會廢棄Options API的設計,選項式 API 依然是 Vue 不可或缺的一部份(參考來源 選項式 API 會被廢棄嗎?)。兩種API雖然風格不同,但它們實際上是基於相同的底層系統運行的,只是提供了不同的開發介面,所以兩種 API 風格都學起來也是不錯的選擇 (來個雙刀流不好嗎😏)。

實務2選1,該用哪一種寫法才好?🧐

從開發團隊習慣、專案需求、擴充性與維護成本等角度出發去評估,這兩種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


上一篇
12 介紹 Vue 3 基本語法
下一篇
14 申請 LINE 官方帳號超簡單!手把手帶你搞定 LINE Login 與 Messaging API
系列文
設計 x 開發:從 Figma 到 Vue,打造 LINE 互動形象網站!26
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言