自從 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.";
}
}
}
代碼來源：Jarkarta EE 官方示例
不過這種方式嚴格限定了編程語言，例如要用 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();
如果有視圖樣式需要復用，那么可以直接把這部分再抽離成一個新的組件，
小結
這篇文章從組件的代碼、樣式、屬性、狀態、組合和復用的這幾個場景上，總結了一些我在前端開發中的一些經驗和個人看法，可能并不適用所有專案，如果你有更好的最佳實踐和經驗，歡迎分享！如果覺得本文有幫助，請分享給其它人，感謝！
原文地址：https://zxuqian.cn/7-ways-to-organize-frontend-components，歡迎訪問查看更多前端開發教程！
Bilibili：峰華前端工程師
公眾號：峰華前端工程師
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/312167.html
標籤：其他