編輯嚴選【React 學習】為何要用前端框架？
2023/12/17 初版
最近的學習進度要推到 React 了。React 是 Facebook 發布、支持的前端框架，其實原先似乎只是 UI 函式庫 (library)，但後來生態系不斷擴充，最終成長為一個龐大的框架 (framework)。雖說學習前端框架不外乎是當前職缺幾乎都有所要求，但我在學習一項新技術前，喜歡先了解該技術出現的背景、它解決的問題，以及它提供的功用，於是產出了這篇學習筆記。
本篇學習筆記內容多參考 Introduction to client-side frameworks - MDN 而來。
前端框架從何而來？
JavaScript 讓原先止於靜態檔案的網頁，多了使用者互動體驗，而這些互動體驗，往往是透過畫面 UI 來追蹤、更新資料。以每位程式學習者最熟悉的 to-do list 為例，會有以下使用功能，全都和上述的追蹤與更新資料有關：
- 畫面渲染出代辦清單
- 查看代辦事項的詳細資訊
- 新增代辦事項
- 刪除代辦事項
- 更新代辦事項
而在軟體開發的世界中，這些使用者介面底下的資料也被稱作狀態 (state)。
以上當然都不是難懂的概念，但實際遇到的問題，是每當我們改變應用程式的 state，畫面上的 UI 就必須相對應更新。若使用純 JavaScript，由於大多網頁應用程式都在瀏覽器執行，因此我們直覺會使用 DOM 來更新 UI。
不過 DOM 光是要操作一個 UI，就得寫下不少程式碼，我們單從「畫面渲染出代辦清單」這個功能看起就好。
💡冷知識：泰文的 ต้ม (dom) 意思為煮沸，而 ต้มยํา (dom yam) 則是酸辣湯。
DOM 與失控的 UI 宇宙
啊，DOM，曾幾何時，我以為與你好好相處就能找到第一份前端工程師的工作，想想我們曾在貪吃蛇專案度過的美好時光，一切都是我意亂情迷，把事情想得太簡單......咳咳，要把代辦清單渲染到畫面上，我們先建立資料，每個代辦清單都是物件，外層用陣列儲存，取名為 state。
const state = [
{
id: "1",
name: "找工作",
},
];
接著寫一個 function，透過 document.createElement() 來建立需要的 HTML 元素，然後把 id、name 等資料透過參數帶入到元素裡面。
function buildTodoItemEl(id, name) {
const item = document.createElement("li");
const span = document.createElement("span");
span.textContent = name;
item.id = id;
item.appendChild(span);
item.appendChild(buildDeleteButtonEl(id));
return item;
}
上面的程式碼還呼叫了另一個 function 建立刪除按鈕，而那個 function 的結構其實大同小異。
function buildDeleteButtonEl(id) {
const button = document.createElement("button");
button.setAttribute("type", "button");
button.textContent "Delete";
return button;
}
好啦，元素都建立完並 return 了，接下來就是要渲染到畫面上。由於 state 陣列裡面可能有數筆資料，因此我們透過 array.forEach 來帶入 id、name 參數：
function renderTodoList() {
const frag = document.createDocumentFragment();
state.tasks.forEach((task) => {
const item = buildTodoItemEl(task.id, task.name);
frag.appendChild(item);
});
todoListEl.appendChild(frag);
}
截止目前為止，我們寫了幾十行程式碼，只為了渲染出某個 UI 而已，還不包含貼上 class name 以便進行 CSS 美化 🥹
想像一下，後續再增加新增代辦事項、刪除代辦事項等互動功能，隨著資料更動，UI 都需要配合更新，直接操作 DOM 顯然不是長久之計，尤其當應用程式規模更大、UI 結構更複雜時，更加重了維護的負擔。
而這正是前端框架呼之欲出的地方，它帶來更方便的開發體驗。我們直接和框架說 UI 要怎麼呈現，框架就會在背後處理 DOM 的部分，達成我們的需求。MDN 提供了 Vue.js 的程式碼，展示框架如何處理上述的代辦清單渲染。雖然我們之後的學習方向以 React 為主，但還是能大致看懂以下的 Vue.js 程式碼，因為和 JavaScript 原生的 template literal 很像啊：
<ul>
<li v-for="task in tasks" v-bind:key="task.id">
<span>{{task.name}}</span>
<button type="button">Delete</button>
</li>
</ul>
框架提供的其他好處
豐富的生態系、好用的套件
以前在 Google 經銷商上班，時常聽到所謂的 Googler 在會議中強調夥伴生態系的重要性，久而久之對生態系這個詞就沒什麼好感 (誤)。
由於現在瓜分市面的前端框架都坐擁龐大且活躍的社群，自然就誕生出了許多相關套件、擴充工具，像是測試、畫圖表、除錯等等。有什麼想在某前端框架完成的事情，基本上都能找到對應的套件。當然好不好用又是另外一回事了。
導入元件的概念
React 和其他前端框架基本上都鼓勵開發者將使用者介面切割成不同的元素 (component)，以利後續管理和重複利用。每個元件都可以獨立拆分成不同的檔案，然後元件再組合成使用者介面。這也提供團隊協作的共識。不然菜雞誠如我，都把所有東西塞到同一個 JavaScript 檔案，連 import、export 都沒有好好實踐。我會好好反省的。
路由 Routing
這個是我目前聽起來覺得最酷的功能。以往要在網頁應用程式實現不同頁面的瀏覽時，我們都是在 Node.js 環境中撰寫路由邏輯，這種方式要委託瀏覽器 (client) 去和伺服器 (server) 索取資料，等資料回傳後再進行渲染，稱為 server-side routing。
相較之下，SPA (single-page app) 則是載入一次 HTML 殼，然後持續去更新它的 DOM，避免一直向伺服器發送請求要資料。這也是現代網頁應用程式滿常使用的方式。
當然 SPA 變複雜之後， 勢必還是要引入 routing 功能，好在前端框架大多提供了相關功能，能用更直覺的方式實現 routing，可能就是不用在後端環境寫路由邏輯(？)，我承認目前還不是很理解這部分，期待之後實作上接觸到，這邊先簡單紀錄一下就好。
⛑️ 使用框架前請三思 ⛑️
前面說了那麼多前端框架的好處，身為一個混亂邪惡的人，自然也要了解一下使用前端框架的風險和隱憂。就和其他技術一樣，前端框架終究是個工具，而我們需要視問題、需求、情境去挑選最適當的工具。共......共勉之。
熟習程度
新框架不斷推陳出新，在接觸新技術時，我們要好好評估學習曲線的問題。如果今天手上的專案急迫性較高，用光速學習的方式企圖掌握一個新工具，似乎不是明智之舉，有可能專案進行到一半，你就先自己搞死自己了。除此之外，我們找工作基本上都是加入團隊協作，所以配合團隊習慣、達成共識也是非常重要的。
將問題複雜化
也許今天你手上的專案壓根不需要用到前端框架。當然，在撰寫這篇學習筆記時，我的目標是找到前端工程師的工作，拿到進入業界的第一章門票，所以後續的個人專案八成會引入前端框架當作練習，畢竟市場上的職缺要求前端框架使用經驗就寫在那邊。但誠如上述，前端框架終究也只是工具，如果問題不適合用這個工具解決還硬幹下去，問題可能會被搞到越來越複雜。
失控的虛擬化 (abstraction)
前面提過，前端框架等於將 DOM 操作這件事情經過虛擬化了，就像我們開車也不用了解引擎怎麼運作一樣。用起來方便沒有錯，但似乎有越來越多人把 JavaScript 擺在第一優先，而忽略了最重要的使用者體驗、效能等等，有種為了用框架而用的窘態。如果框架犧牲了最重要的價值，那或許不用也罷。
以上注意事項看起來的確滿嚇人的，而我平時收看的 Youtube 頻道 ThePrimeTime 也時常提到大家一窩蜂學習、使用 React 的擔憂。但我秉持著光聽別人說，自己卻沒做過總是不太好的想法，還是會花時間來學習前端框架，畢竟有了使用經驗之後，也才能和別人吵架加入討論行列，況且要找工作就是得學啊 🥹
希望未來的我能繼續將這些要點謹記在心，不要變成工具的奴隸。手上握著鐵鎚的人，看什麼都會變成釘子，我想這就是學習、使用框架時，絕對要特別留意的事情吧 (？)
