自從 2010 年第一份工作接觸了前后端半分離的開發方式之后，在后面的這些年里，對前端的組件化開發有了更全面一點的認識，組件化在我們的前端開發中，對提高開發效率、代碼的可維護性和可復用性有很大幫助，甚至對跟設計師溝通的效率和企業的品牌形象都有着深刻的影響。這篇文章就把我在開發中總結的一些組件化開發經驗分享一下。示例中的所有代碼都是偽代碼，你可以按照實際情況應用到 React 或 Vue 的項目中。
前端組件化發展歷史
在討論組件化開發之前，我們先看看前端組件化開發的發展歷史。網頁開發剛起步時，並沒有『前端』這個概念，更不用提組件化了。當時，網頁只是作為可以在瀏覽器中瀏覽的富文本文件，開發網頁就是使用一些標簽讓瀏覽器解析並顯示。受制於 HTML 只是描述式的語言，網頁中的代碼沒有辦法復用，即使是類似的頁面，都需要復制粘貼大量的重復代碼：
<!-- index.html -->
<nav>
<!-- 導航 -->
</nav>
<main>
<!-- 內容 -->
</main>
<footer>
<!-- 頁腳 -->
</footer>
<!-- blogPost.html -->
<nav>
<!-- 相同的導航 -->
</nav>
<main>
<!-- 不同的內容 -->
</main>
<footer>
<!-- 相同的頁腳 -->
</footer>
后來隨着模板引擎的出現，可以把網頁的代碼分割成片段（Fragments）或模板（Templates），例如導航，內容，頁腳等等，之后在需要的地方，使用引入（Include）語法，把這些片段引入進來，從而避免重復代碼，這樣形成了組件化的雛形，常見的動態腳本語言都有自己的模板引擎，例如 PHP、ASP 和 JSP：
<!-- nav.jsp -->
<nav>
<!-- 導航 -->
</nav>
<!-- index.jsp -->
<jsp:include page="nav.jsp" />
只是這些片段在數據管理方面仍然會比較麻煩，還是需要使用客戶端 JavaScript 腳本，手動控制數據和 HTML 視圖的同步。而對於樣式，也還是存在全局污染的問題。
再后來，有些高級的開發語言，例如 Java， 推出了基於服務器的組件化開發技術，例如 JSF （JSP 的后繼），基於 MVC 設計模式，通過 Java Class (POJO) 定義數據模型（Model），為 JSF 頁面模板提供數據。JSF 的數據模型中有事件和生命周期相關的方法，而模板和數據模型通信的方式是 Ajax，通過使用 JSF facelets 組件的方式，可以直接發送 Ajax 請求，調用模型中的方法：
<!-- index.xhtml -->
<html
xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://xmlns.jcp.org/jsf/html"
xmlns:f="http://xmlns.jcp.org/jsf/core"
>
<h:commandButton id="submit" value="Submit">
<f:ajax event="click" />
</h:commandButton>
<h:outputText id="result" value="#{userNumberBean.response}" />
</html>
// UserNumberBean.java
@Named
@RequestScoped
public class UserNumberBean implements Serializable {
/* 其它代碼省略 */
public String getResponse() {
if ((userNumber != null)
&& (userNumber.compareTo(dukesNumberBean.getRandomInt()) == 0)) {
return "Yay! You got it!";
}
if (userNumber == null) {
return null;
} else {
return "Sorry, " + userNumber + " is incorrect.";
}
}
}
不過這種方式嚴格限定了編程語言，例如要用 JSF 技術就必須要使用 Java，並且樣式污染的問題和客戶端數據管理的問題仍然沒有解決。
隨着 Node.js 的普及，JavaScript 可以脫離瀏覽器運行了，並且帶來了 npm 包管理器，基於 npm 龐大的工具鏈，可以 Node.js 的代碼打包成瀏覽器中能夠運行的代碼。而這期間，產生了像 React、Vue 和 Angular 這樣的、適合大型前端項目開發的庫和框架。
React 和 Vue 目前的流行程度比較高一些，它們都是純客戶端的、組件化的 JS 庫，不依賴任何后端編程語言，讓程序員都能夠快速上手。不過，隨着項目規模的擴大，如何利用好這些庫進行組件化開發，成了前端工程師必須要掌握的課題。
什么是組件
那么到底什么是組件呢？你想一下日常生活中，電腦上的硬件，例如顯卡、內存、CPU，或者汽車的零部件：輪胎、發動機、方向盤等，這些都屬於組件，它們組合起來能形成一個完整可用的產品，對於遵循了設計規范的組件，只要型號匹配，無論品牌、樣式，都可以互相兼容。
我們前端工程師其實就當於是一個工廠，我們需要按照一定的規范，產生出合格的網頁組件，利用它們組裝成完整的頁面。組件一般包含 HTML 模板、CSS 樣式和 JavaScript 數據邏輯，自成一體，可以直接在其它組件中使用，組件本身的模板、樣式和數據不會影響到其它組件。組件還包含一系列可配置的屬性，動態的產生內容。
常見的基礎組件有按鈕、導航、提示框、表單輸入控件、對話框、表格、列表等，我們在它們的基礎上又能組合出更復雜的組件，那么對於前端中的組件的定義就非常廣泛了，小到一個按鈕，大到一個頁面都可以形成一個組件，例如兩個相似的頁面，可以復用一個頁面組件，只需要通過修改組件的屬性，來形成一個新的頁面。
為什么要組件化開發
你可能也知道，React 和 Vue 其實也可以完全按照傳統的網頁開發方式進行開發，最多是把網頁大體分成幾個部分，放到單獨的幾個文件里就好了，對於簡單的網站來說沒什么問題，但是如果開發的是大型的應用，例如網頁版的 QQ 音樂、微信、郵箱等，它們有大量的、細小的組件，並且重復出現，這時如果針對每個頁面編寫 HTML 和樣式，那么就會造成太多冗余代碼了。
<!-- playlist.html -->
<div class="card">
<div class="card__title"></div>
<div class="card_content"></div>
</div>
<!-- homepage.html -->
<div class="card">
<div class="card__title"></div>
<div class="card_content"></div>
</div>
<!-- user.html -->
<div class="card">
<div class="card__title"></div>
<div class="card_content"></div>
</div>
如果使用組件化的方式，我們可以把重復出現的頁面內容定義成組件，這樣就不用復制粘貼同樣的代碼了，減少代碼的體積：
<!-- 偽組件 -->
<!-- Card.comp -->
<div class="card">
<div class="card__title"></div>
<div class="card_content"></div>
</div>
<!-- playlist.html -->
<Card />
<!-- homepage.html -->
<Card />
<!-- user.html -->
<Card />
當某個頁面內容是復合組件時，那么可以直接把基礎組件直接拿過來應用：
<Card>
<Title></Title>
<Button></Button>
</Card>
利用這種方式，甚至可以達到 1 分鍾產生一個新頁面的恐怖速度，這對於你來說，節省時間去摸魚，豈不美哉？
<Page title="頁面1" data="{...}" /> <Page title="頁面2" data="{...}" />
對於大型的公司來說，公司的網站、APP、桌面應用、Web 端應用等的設計風格都是一樣的，同樣的組件會在不同平台中使用，這個時候團隊之間可以共享一套組件庫，復用到各端平台上，減少重復開發的成本。React 和 Vue 都支持創建跨平台的應用，這時組件化開發就顯得更重要了：
使用組件化開發之后，代碼也容易維護了，如果頁面某個部分出了問題，那么我們可以針對出現問題的組件進行修復，多次用到這個組件的地方也都會一起修復了。
最后，設計師在設計產品界面的時候，會把重復出現的 UI 也做成『組件』，這個組件的概念幾乎和前端中的組件一模一樣，這時可以跟設計師交流想法，看看他/她是怎么規划組件的，這樣也減少了在開發時，設計規划組件的時間。
接下來分享一下我在組件化開發中總結的經驗：
一、組件的規划
在正式進行前端應用開發之前，需要有充分的時間來分析，看看頁面上的哪些內容需要做成組件。這一步只需要大致規划一下：
如果公司設計師提供了詳細的設計規范，那么直接按照規范中的組件來開發就可以了。
- 如果只有設計稿，那么就看看哪些內容有 2 次或更多次在其它頁面中用到了，這些大概率需要設計為組件。
- 如果連設計稿都沒有，那么可以用市面上現成的組件庫，例如 ant design。
- 如果沒有設計稿，還要自己從零開發，那么可以根據通用的套路，把基礎組件，例如按鈕、菜單等，規划出來，並把可能會多次用到的頁面內容，也規划出來，例如導航，底部信息、聯系方式區域，這樣可以只改動需要變化的部分，不影響其它部分。
這一步不用太過詳細，浪費太多時間，后續開發的時候如果遇到不確定是否要寫成組件的部分，可以直接把這部分代碼寫到大的組件里，如果其它組件又用到了，再把它抽離成組件。
二、組件代碼管理
組件的代碼應該遵循就近原則，也就是說：
- 和組件有關的 HTML、CSS 、JS 代碼和圖片等靜態資源應該放在同一個目錄下，方便引用。
- 組件里的代碼應該只包括跟本組件相關的 HTML 模板、CSS 樣式和 JS 數據邏輯。
- 所有的組件應放到一個統一的『組件文件夾中』。
如果組件之間有可以復用的 HTML 和 CSS，那么這個復用的部分可以直接定義成一個新的組件。
如果組件之間有可以復用的 JS 數據邏輯，那么可以把公用的數據邏輯抽離出來，放到公共的業務邏輯目錄下，使用到該邏輯的組件，統一從這個目錄中導入。
如果項目中使用到了全局狀態管理，那么狀態管理的數據應放在獨立的目錄里，這個目錄還會存放分割好的狀態片段 reducer，之后統一在 store 中合並。
對於項目中的** API 處理**，可以把它們單獨放到一個文件夾里，對於同一個數據類型的操作，可以放到同一個 js 文件里，例如對 user 用戶數據的增刪改查，這樣能盡最大可能進行復用，之后在組件里可以直接引入相關 api 進行調用。如果直接寫在組件里，那么使用相同 API 的組件就會造成代碼重復。
例如下面是一個組件化開發的目錄結構示例（框架無關）：
project
|-- components # 所有組件
|-- Card # Card 組件
|-- index.js # Card 組件 js 代碼
|-- Card.html # Card 組件 html 模板
|-- Card.css # Card 組件 css 樣式
|-- icon.svg # Card 組件用到的 icon
|-- logics # 公共業務邏輯
|-- getUserInfo.js # 例如獲取用戶信息
|-- data # 全局狀態
|-- store.js # 全局狀態管理 store
|-- user.reducer.js # user reducer
|-- blogPost.reducer.js # blogPost reducer
|-- apis # 遠程請求 API 業務邏輯
|-- user.js # user API
|-- blogPost.js # blogPost API
三、組件樣式管理
在編寫組件樣式的時候，應只設置組件 CSS 盒子內部的樣式，影響外部布局的樣式要盡可能的避免，而應該由使用該組件的父組件去設置。例如，如果有一個組件設置了外邊距，但是這個組件經常會用於 grid 或 flex 布局中，那么這個額外的邊距會對布局造成影響，只能通過重置外邊距的方式取消邊距，這就不如組件不設置外邊距，由父組件的布局決定它的位置，或者外邊距。
類似的還有定位相關的樣式，絕對定位、固定定位等對文檔流有影響，應交由父組件決定，除非這個組件只有絕對定位這一種情況，例如對話框。
組件中的 CSS 要局部化，以避免影響全局樣式。傳統的 CSS 樣式是全局的，如果有兩個不同的組件，使用了相同的 class 名字，那么后定義的樣式會覆蓋之前定義的。一般前端庫中都有定義局部樣式的功能，例如通過 CSS Modules。
<!-- Vue -->
<style scoped></style>
<!-- React，通過文件名 -->
Button.module.css
修改子組件的樣式時，優先使用選擇器特異性（CSS Specificity）策略選定特定元素，而行內樣式（inline-style）在設置簡單樣式的時候使用，盡一切可能避免 !important，因為如果再有上一層組件（爺爺組件）需要修改這個組件的樣式時，就會很困難了。
四、組件屬性管理
組件屬性的命名要與它實際展示的內容相符。例如一個博客文章組件，title 屬性表示標題，content 代表內容，showFullArticle 表示是否顯示全文。
<!-- 不推薦，full 表示什么？ -->
<BlogPost title="" content="" full="" />
<!-- 推薦 -->
<BlogPost title="" content="" showFullArticle="" />
組件的屬性應有必要的類型檢查，避免在使用屬性時出現異常，例如在需要數組的地方傳遞了布爾類型，那么如果代碼有遍歷數組的邏輯，就會出錯。
props: {
title: String,
content: String,
showFullArticle: Boolean
}
代表事件的屬性，應該和現有的 HTML 事件名稱規范保持一致，以 on 開頭，后面用英文表示會觸發的事件，例如 onEdit 表示會觸發編輯事件。
<BlogPost onEdit="" />
組件的屬性不能直接和狀態進行捆綁，而是應該只作為狀態的初始值。如果把屬性值作為狀態值，那么就破壞了單一數據流向機制，此時該組件可以通過自身修改狀態，也能通過父組件的屬性變化修改狀態，很容易造成數據的不一致。推薦的做法是，設置一個初始值屬性，可以通過父組件傳遞進來，當作狀態的初始值，然后丟棄，后續只通過該組件修改狀態值。
const { initialTitle } = props;
const title = state(initialTitle);
// 修改
updateTitle() {
title = "...";
}
五、組件狀態管理
組件的狀態分為全局狀態和局部狀態兩種。
局部狀態是定義在組件本身的狀態，應由組件本身內部管理，當子組件需要該組件的狀態值時，通過屬性傳遞給子組件，此時狀態變化時，子組件也會自動刷新。
// 父組件
const someState = state("");
<ChildComponent prop1="someState"></ChildComponent>;
當子組件需要給父組件傳遞狀態的值時，要通過事件的方式傳遞給父組件，盡最大可能避免使用 ref。
// 父組件
function getStateVal(val) {
console.log(val);
}
<ChildComponent onChange="getStateVal" />
// 子組件
<input onChange="e => getStateVal(e.target.value)" />
狀態的變化還應只通過事件或生命周期來進行，不能在其它同步執行的代碼中進行，這樣不會引起組件的刷新。
const someState = state();
// 錯誤
const state = "newState";
// 正確
handleButtonClick() {
someState = "newState";
}
全局狀態是多個組件共享的，如果有多個組件共享某個狀態，那么應該把狀態定義在這些組件統一的、最接近的父組件中，或者使用全局狀態管理庫。
全局狀態的修改，應該由類似於 actions 的行為觸發，然后使用 reducer 修改狀態，這樣能追溯狀態的變化路徑，方便調試和打印日志。
// 組件
function updateState() {
emitAction("changeState");
}
// reducer
function someState(state, action) {
switch(action) {
"changeState": someState => {
log(someState);
return newState
}
}
}
全局狀態推薦按領域（Domain）來拆分 reducer，而不是按頁面。例如按 user 用戶、文章 posts、評論 comments 來拆分，而不是以 HomePage 主頁、BlogPostListPage 博客列表頁，BlogPostPage 博客詳情頁這樣來拆分。這樣做的好處是，能夠最大限度的復用 reducer 中的邏輯。
// userReducer
{
"updateUser": ...
"deleteUser": ...
/* ... */
}
六、組件的組合
前端開發就是組合不同的組件。
在組合組件的時候，盡量使用『插槽』的形式（例如 React 的 children/render props，Vue 的 slot），這樣可以減少組件的嵌套，避免多層傳遞屬性或事件監聽。
使用 slot：
// Layout 組件
<div>
<!-- nav slot -->
<!-- content slot -->
<!-- footer slot -->
</div>
// 首頁 function handleNavChange() {}
<Layout>
<nav onChange="handleNavChange"></nav>
<main></main>
<footer></footer>
</Layout>
不使用 slot：
// Layout props: { onNavChange: function }
<Layout>
<!-- 還需再傳遞一層 -->
<nav onChange="onNavChange"></nav>
<main></main>
<footer></footer>
</Layout>
// 首頁 function handleNavChange() {}
<Layout onNavChange="handleNavChange" />
如果有循環展示列表的地方，需要對循環中最外層的組件設置 key，這樣在列表發生變化時，能幫助前端庫判斷是否可以通過排序的方式，重復利用現有的組件，來更新視圖，而不是銷毀重建。
let todos = [{id: 1, content: "todo1"}, {id:2, content: "todo2"}, {id:3,
content: "todo3"}];
<List>
for todo in todos:
<item content="todo.content" key="todo.id" />
</List>
// todos 順序變化，列表也只是根據 id 調整順序，不會銷毀重建 todos = [{id: 3,
content: "todo3"}, {id:2, content: "todo2"}, {id:1, content: "todo1"}];
如果有按條件展示組件的地方，且切換頻率高，或有動畫需求，要使用設置 css display 的方式，例如 vue 中的 v-show，如果切換頻率低，可以使用加載、銷毀的方式，例如 vue 中的 v-if，React 中使用 && 邏輯判斷。
七、組件的復用
在復用組件的時候，可以通過改變組件的屬性來修改一些簡單的組件內容。
<Card title="" content="<ContentComp />" />
如果組件結構類似，但是有些內部的組件不一樣，可以考慮通過『插槽』來復用。
<!-- Comp -->
<div>
<h1></h1>
<!-- slot -->
</div>
<!-- 其它組件 -->
<Comp>
<p>替換 slot</p>
</Comp>
如果有業務邏輯需要復用，尤其是涉及到狀態變化的，那么可以把它抽離為公共的業務邏輯，利用 Hooks（React）或 Composables （Vue）來復用。
// 公共邏輯 (/logic/useSomeLogic.js)
function useSomeLogic() {
const someState = state();
const updateState = (v) => (someState = v);
return {
someState,
updateState,
};
}
// 組件1復用
import userSomeLoginc from "/logic/useSomeLogic.js";
const { someState, updateState } = useSomeLogic();
// 組件2復用
import userSomeLoginc from "/logic/useSomeLogic.js";
const { someState, updateState } = useSomeLogic();
如果有視圖樣式需要復用，那么可以直接把這部分再抽離成一個新的組件。
小結
這篇文章從組件的代碼、樣式、屬性、狀態、組合和復用的這幾個場景上，總結了一些我在前端開發中的一些經驗和個人看法，可能並不適用所有項目，如果你有更好的最佳實踐和經驗，歡迎分享！如果覺得本文有幫助，請分享給其它人，感謝！