前言

延續 Day 3 的思維，我們從使用者需求出發，連續五天打造了一個可以動起來的前端飲料點單系統。
在 AI 可以協助撰寫並優化程式碼的今天，更重要的其實是 工程思維：如何用技術實現滿足使用者需求的完整 Application。
至於過程中採用的工具與框架，往往取決於團隊的習慣與規範，而不只是語法本身。

今天我們要加固 chapter 1：
整理這五天的知識點與功能，反思它們的關聯與差異，並思考下一步如何走向後端 API 串接與 Vue 專案的組件化管理。

一、魔法書累積知識

本學習書籍魔法書使用napkin協助製作

五天的練習讓我們完成了一個可以運作的前端專案：

• Day 1：流程判斷 → v-if、:disabled
• Day 2：事件驅動 → @click
• Day 3：資料雙向流 → v-model
• Day 4：狀態轉樣式 → :class
• Day 5：清單管理與統計 → reactive 陣列、刪除、統計

這些都是進入 Vue 世界的基礎「魔法咒語」。
但我們的應用仍然侷限在 前端，資料全存在 client side。
未來若要進一步：

• 與 後端 API 溝通，需要學會 axios / fetch。
• 建立更大專案，需要 組件化拆分 與 狀態集中管理 (Pinia、Vuex)。
• 進行 部署與測試，確保在實際環境中穩定執行。

🗂 Day 1 ~ Day 5 功能 × Vue 技術 × User Story

✅ 這張表讓我們一目瞭然地看見功能如何與 Vue 技術對應，也能快速想像未來的擴充點。

二、Vue 魔法的相似功能比較

在實作過程中，我們已經接觸到 v-model / @input :value 與 ref / reactive 這兩組「兄弟功能」。

它們在概念上有一些重疊，但使用場景略有不同。

我們身為魔法師，技藝專精不斷的追求更強

探究魔法的深淵才是最後的答案!!

否則被取代的舊是固化的思維書籍

1. v-model vs. @input + :value

範例：

<!-- v-model 寫法 -->
<input v-model="name" />

<!-- 等價於 -->
<input :value="name" @input="name = $event.target.value" />

我們先來拆解一下如果先把資料state bind(v-bind)上input框框的value

<template>
  <div>
    <!-- 單向綁定 -->
    <input type="text" :value="text" />
    <p>輸入的值：{{ text }}</p>
  </div>
</template>

<script>
export default {
  data() {
    return {
      text: 'Hello Vue'
    }
  }
}
</script>

這種寫法會造成什麼樣的後果呢!?

答案就是

1. 一開始 input 內有 Hello Vue。

2. 但你在輸入框輸入新文字時，text 不會改變。

3. 所以 仍然顯示 Hello Vue。

那如果反過來我是做@input 或是做@change的動作呢?

這邊必須提一下因為我們要呈現

如果是資料改變state然後更新再UI以及 的html tag會發生什麼事情

所以這邊多一個按鈕來模擬state因為事件發生改變的

<template>
  <div>
    <!-- 沒有 v-model，也沒有 :value -->
    <input type="text" @change="handleChange" />

    <!-- 顯示資料 -->
    <p>text 資料：{{ text }}</p>

    <!-- 用按鈕修改 text -->
    <button @click="changeText">點我把 text 改成 ABC</button>
  </div>
</template>

<script>
export default {
  data() {
    return {
      text: ''
    }
  },
  methods: {
    handleChange(event) {
      // 只有離開輸入框或 Enter 才會更新
      this.text = event.target.value
    },
    changeText() {
      // 用程式強制修改 text
      this.text = 'ABC'
    }
  }
}
</script>

我們觀察到的結果就是

1.初始狀態 : input 是空白。 顯示 text 資料：。

2. 輸入中 : 你在輸入框輸入「hello」，text 不會馬上更新。

3. 直到輸入框失焦或按 Enter，@change 才觸發 → 顯示 hello。

4. 點擊按鈕 : 當你點「點我把 text 改成 ABC text的state 變成 ABC。

5. input 仍然顯示你之前輸入的值（例如 hello），因為沒有 :value 綁定。

總結:

1.@change：只會在輸入框完成輸入後更新一次資料。

2.沒有 :value：當程式改變資料（例如按鈕點擊改變），輸入框不會同步顯示新的值。

3.這個範例清楚呈現了資料和畫面分離的效果。

我們可能會想到為什麼會需要資料也要更新的input的情境呢?

你可以試想，今天如果有些三層的下拉選單會透過api傳回來更新state

那我們沒有更新的選單會不會造成選單使用上的問題!!?

問題可大了呢!!! 這種情形就是可能會遇到問題的小細節

也是工程師必須注意的地方

2. ref / reactive

2.1差異對照

2.2 使用情境建議

2.3 什麼是「需要頻繁整個替換物件」 ?

指的是在應用中，某段狀態常常一次性用新物件取代舊物件，
而不是逐一修改其中幾個屬性。

2.4 常見使用情境

2.5 為什麼 ref 更適合

• reactive：直接指派新物件會失去響應

  state = newObj // ❌ 不會再是 reactive
  Object.assign(state, newObj) // ✅ 必須用這種方式
  
  
  

其實大多的情況工程師都會用ref，但有些特定的物件結構就可以使用reactive喔!!

總結與後記

Day1~Day5 奠定了「互動前端」的基礎。

下一步的魔法修煉 建議循序：

1. 資料與後端溝通：確保資料可長期保存並維護。

2. 組件化與架構：讓程式碼易於維護與擴充。

3. 集中狀態管理：處理大型應用的複雜資料流。

其實要先學哪一個階段我認為都沒有固定的順序

不過通常我會覺得跟大概會這樣想，或是三種一起學也可以!!

1.如果你前端可以不用存data在資料庫資料庫的簡單api 或是一次性app (計算機、統計小工具)，可以先pass
2.如果你不喜歡重工跟團隊合作的工程師，那我會建議一定先學這條路
3.如果在大型的app應用裡面，你不希望重工部分資料，這時候就會使用這個方式

就像你在學習魔法的時候我可以依照自己想要攻擊就先學攻擊力強的魔法，如果是輔助/治療可以轉成僧侶!?