這幾天把後端那條線摸過一輪——FastAPI 的概念、路由、資料模型都理清楚了。今天要切到另一條線：使用者實際會看到、會操作的畫面要怎麼做。這塊完全是新的領域，所以今天不急著選定要用哪個框架，先搞懂基本概念。

先搞懂一個最基本的問題：為什麼需要「框架」

一開始的疑問跟 Day 17 學 FastAPI 時很像：網頁不就是 HTML、CSS、JavaScript 嗎,為什麼還需要 React 或 Vue 這種額外的工具？

查了資料之後理解到,問題出在「畫面會一直變」這件事。這個專題的聊天介面，每次使用者送出一句話,畫面上就要多一則訊息、AI 回應時要有個等待動畫、對話紀錄要往下捲動——如果純粹用 JavaScript 手動操作畫面上的每一個元素,程式碼會變得又亂又難維護。

React、Vue 這類框架解決的就是這個問題：讓畫面變成「資料的呈現結果」。只要改資料（例如把新訊息加進對話紀錄這個變數），畫面會自動跟著更新，不用自己一行一行去操作「這裡要新增一個文字框、那裡要捲動」。

React 跟 Vue，今天看到的差異

跟 Day 2 比較 GPT、Gemini、Claude 時有點像,今天也簡單比較了這兩個最常聽到的前端框架：

React：由 Meta 開發，生態系龐大，很多公司在用，網路上的資源和範例也最多
Vue：學習曲線據說比較平緩,語法更接近一般 HTML，對新手相對友善

兩者要解決的問題是一樣的——都是「讓畫面跟著資料自動更新」，差別比較偏向寫法風格和社群生態。今天沒有馬上決定要用哪一個，但筆記先記下來：之後選擇時,評估標準會是「資源多不多、範例好不好找」，而不是糾結哪個「比較強」。

核心概念：元件（Component）

今天理解的最重要概念是「元件」。簡單說，就是把畫面拆成一個一個可以重複使用的小積木。

對照這個專題要做的聊天介面，可以想像拆成這幾個元件：

一則訊息的外觀（使用者說的話、AI 回的話，長相不同）
整個對話紀錄的捲動區塊
底下的輸入框和送出按鈕

每個元件各自管理自己長什麼樣子，组合起來就是完整的畫面。這個拆法讓我想到 Day 7 學的 n8n 的 Node 概念——都是把一個複雜的整體,拆成一個一個獨立、可以重複使用的小單位，只是一個是用來拆「流程」,一個是用來拆「畫面」。

另一個關鍵概念：狀態（State）

今天第二個重要概念是「狀態」。狀態指的是「會隨著使用者操作而改變的資料」，例如：

目前輸入框裡打了什麼字
整個對話紀錄目前有哪些訊息
AI 現在是不是正在「思考中」（要不要顯示等待動畫）

今天理解到的核心邏輯是：畫面不會自己變,是狀態變了,畫面才跟著重新畫一次。 跟 Day 17 學的 FastAPI 資料模型有點異曲同工——後端用資料模型描述「資料長什麼樣」，前端則是用狀態描述「畫面此刻該呈現的資料是什麼」，兩邊概念上其實滿接近的。

今天釐清的流程：畫面跟後端怎麼接起來

把這幾天學的東西兜在一起，今天想像出一個初步的流程：

使用者在輸入框打字 → 這是一個狀態在變化
按下送出 → 觸發一個函式，把輸入框的內容打包成 JSON
呼叫 Day 17 準備的後端 API（用 Day 16 學的 POST 方式）
等待回應的時候，「思考中」狀態打開，畫面顯示等待動畫
拿到後端回傳的 JSON → 更新對話紀錄的狀態 → 畫面自動多出一則新訊息

把這個流程寫下來之後，前後端兩條原本分開學的線，第一次真正在腦中接成一條完整路徑。