聊聊前端 UI 組件：組件特徵

本文首發於 歐雷流。因爲我會時不時對文章進行補充、修正和潤色，爲了保證所看到的是最新版本，請閱讀 原文。

本文是文章系列「聊聊前端 UI 組件」的第二篇，內容與本系列的上篇文章《聊聊前端 UI 組件：核心概念》有所關聯，若是還沒看過，建議去看下。

本文的主要內容是根據特徵對前端 UI 組件進行建模，讓咱們儘量充分地瞭解它的方方面面，併爲如何設計以及創建一個組件體系打下基礎。

組件構成

從關注點分離的角度分解 UI 組件，並分析其各部分的易變性。

構成元素

一個完整的具有功能的 UI 組件的構成，有結構（structure）、表現（presentation）和行爲（behavior）這三個方面。爲何強調是「完整的具有功能的 UI 組件」？是由於它是一個最全的特徵集合，而其餘的「UI 組件」可能會缺乏一些特徵，從而使分析不那麼完善。

看到「結構」、「表現」與「行爲」這三個詞，做爲一名有經驗的前端開發者，很天然地就會想到好久好久以前開始一直提倡的前端開發的關注點分離——HTML 負責組織頁面結構，CSS 負責網頁內容的表現樣式，JS 則負責用戶與網頁之間的交互，它們各自扮演着不一樣且相輔相成的角色。

然而在這裏，它們的含義會有所不一樣——

經 HTML 組織後的網頁內容是「結構」沒錯，但它僅僅是代碼層面的，未被 CSS 所影響的結構。最終的視覺呈現，也就是視覺層面的「結構」，應該還包括 CSS 的佈局類樣式，如定位（positioning）、浮動（float）等。

CSS 中的那些非佈局類樣式，如顏色、字體、文本、邊框、尺寸、留白等類別的樣式，以及圖標、圖片，皆爲「表現」。這些通常還被稱爲「主題風格」或者「皮膚」。

可在 JS 中運行的事件系統以及進行邏輯處理的函數和對象方法，算是「行爲」——這就是 UI 組件的交互邏輯了。固然了，與交互邏輯相融合的業務邏輯，也是「行爲」的一部分。

易變性

根據構成 UI 組件的每一個部分的性質，會影響 UI 組件相應部分的易變性——對於組件複用來講，該部分是相對穩定的仍是相對不穩定。

GUI 發展了幾十年，人機交互的圖形元素及佈局方式已經相對固定，只要不是出現像 Google Glass 之類的革命性交互設備，就不會發生重大改變。

——歐雷《我來聊聊面向模板的前端開發》

如上所述，將來到底會出現什麼樣的變革性交互方式無從得知，但我認爲，只要是須要用眼去看且用手去操做，交互方式就逃不離這幾十年來未有啥變革的形式。所以，UI 組件的視覺結構和交互邏輯是最不易變的，且不管是交互模式仍是觸發事件都是可枚舉的。

若是單純從最終的 HTML 結構上來看，它也算是不易變的，但在現代前端開發中，HTML 的結構基本是動態生成的，而且強依賴於 React、Vue 這類沒有統一標準的 JS 庫/框架。另外，還存在着像 WXML、AXML 這類平臺限定的視圖結構描述語言。因爲寫法不一致，這就使頁面內容結構變得不那麼穩定。

通常來講，離用戶越近的東西越容易發生改變。在網站、應用中離用戶最近的是 GUI，而在 GUI 中離用戶最近的則是主題風格，這是對用戶來講最直觀的東西。主題風格會隨着 GUI 設計人員（一般是設計師）的審美和想法而改變，因此它是最易變的。

由於業務邏輯是進行業務相關處理的核心所在，若是業務規則變了，相應的代碼實現也得跟着改變，因此業務邏輯也是很易變的。業務邏輯對於一個網站、應用來講是十分必要且重要的，但對 UI 組件來講，它就沒那麼必要了，更談不上重要。在前端的 GUI 層面，業務邏輯理應是交互邏輯的延伸。

爲了方便，將 UI 組件各個構成部分的易變性及其影響因素整理以下：

構成		易變性	影響因素
結構	視覺結構	不易變	內容結構、佈局類樣式
	內容結構	較易變	生成 HTML 的 JS 庫/框架的源碼、平臺限定的視圖結構描述語言
表現	主題風格	很易變	GUI 設計人員的審美和想法、非佈局類樣式、圖標與圖片
行爲	交互邏輯	不易變	交互設計人員的想法
	業務邏輯	很易變	業務規則

從表格中能夠看出，將「易變性」分紅了三個等級，按照從小到大的順序來分別解釋下：

• 「不易變」——受交互方式影響，只要沒發生什麼革命性改變時就不太會變；
• 「較易變」——受源碼語法影響，只要源碼的編寫方式肯定就不會變；
• 「很易變」——受業務和人影響，只要業務領域、業務規則還有人的想法不變就不會變。

組件分類

以較爲抽象的視角對 UI 組件進行分類——

原子性

從一個 UI 組件的內部是否還包含其餘 UI 組件這個角度來看，分爲「原子組件」和「複合組件」兩類。「原子組件」是不可再分的 UI 組件，即其內部再也不包含其餘的 UI 組件，像按鈕組件、圖標組件、分割線組件等；「複合組件」則是由一個以上的原子組件所構成的，如導航菜單組件、選項卡組件、對話框組件等。

通用性

根據 UI 組件的通用性，可分爲「通用組件」和「專用組件」。「通用組件」是可以知足大部分常規場景的 UI 組件，它們的集合一般會做爲「組件庫」總體打包發佈爲一個軟件包；「專用組件」是爲了解決某些特殊場景需求而存在的，像數據網格、各類編輯器等，這類通常都是單獨發包。

功能性

按照 UI 組件所起到的做用，大概可劃分爲如下幾類：

組件類別	示例組件
命令輸入	按鈕組件、下拉菜單組件
數據輸入	輸入框組件、單選框組件、複選框組件、下拉列表組件、日期拾取器組件
數據輸出	列表組件、表格組件、數據網格組件
信息展現	圖標組件、加載狀態組件、工具提示組件
容器	手風琴組件、面板組件、選項卡組件、字段集組件
導航	導航菜單組件、麪包屑組件、超連接組件
特殊窗口	對話框組件、警告提示組件

這種分類方式沒有一個嚴格的定義，就見仁見智了。

組件繼承

不像面向對象編程中的繼承那樣是行爲的複用，這裏所說的「繼承」是指表現的複用，而且還可以「多重繼承」。

在繼續往下以前，先引入一個「虛擬組件」的概念。正如它的名字所示，是一個虛擬的，實際不存在的，只是概念上的組件。它是幾個主題風格屬性的集合。

輸入框組件、下拉列表組件等都屬於表單控件（form control），它們都繼承自「表單控件」這個虛擬組件，若是各自沒有指定顏色、字體、邊框等主題風格屬性的話，將會按照虛擬組件中所設定的來顯示。相似地，下拉列表組件、下拉菜單組件等都有彈出層（pop-up），它們都繼承了「彈出層」這個虛擬組件。

想必你已經發現了，下拉列表組件同時繼承了「表單控件」和「彈出層」這兩個虛擬組件，這就是上面提到的「多重繼承」。

那些所謂的「虛擬組件」，它們也遵循着一樣的繼承規則——若是自身沒有指定特定的主題風格屬性，則會按照父級所設定的顯示。那麼，虛擬組件的「父級」是啥呢？——是基礎風格。

雖然這裏所描述的繼承關係看起來有點像 CSS 中的繼承，然而它們並不同。

總結

本文從前端 UI 組件的構成、分類及組件間的繼承關係等角度出發，經過分析組件的特徵來探討創建一個組件體系所須要關注的一些點。其中，UI 組件各構成元素的易變性是最應該被關注的，它會對組件體系的可複用性、可擴展性等產生很大影響。

實質上，HTML 與 WXML 和 AXML 等是同一級別的，都是平臺限定的視圖結構描述語言——WXML 是微信小程序的，AXML 是支付寶小程序的，而 HTML 則是「網頁瀏覽器」這個平臺的。

在動態網頁中，尤爲是使用了 Mustache、Handlebars 等模板引擎或 React、Vue 這類庫/框架時，最終的內容結構基本是 JS 生成的，這就強化了 JS 而弱化了 HTML 在內容結構上的控制力。

各個 JS 庫/框架的 HTML 代碼生成方式不一樣，視圖結構描述語法不一樣，沒有統一的標準，這就形成了混亂——這也是對前端 UI 組件的可複用性最大的挑戰！

---

歡迎關注微信公衆號以及時閱讀最新的技術文章：