許多入門前端的朋友都知道組件的概念，也在日常工作中用到組件，寫組件，也和別人討論組件。但是前端為什么是建立在組件上的呢？昔日輝煌一時的 jQuery 為什么會沒落，到底要怎樣組織組件才能提高平時的工作效率，減輕邏輯復(fù)雜度引起的脫發(fā)失眠和扯皮翻臉呢？
本文會從以下幾點回答上面的問題：
- 首先，講一點點組件概念的來源，跨多個平臺語言
- 然后，掰開組件背后隱藏的線，講一下這種思維模型的大一統(tǒng)
- 再然后，從軟件工程的全局視野聊組件的分類管理
- 最后算是彩蛋，聊一聊為什么“道理全都懂”就是寫不好組件
一、組件的概念源于已有的 UI 解決方案
所謂組件，其實是一種對 UI 界面做組織的解決方案。復(fù)雜點的網(wǎng)站，UI 模塊千千萬，管理不好真難看。
UI 的管理，從最早的桌面應(yīng)用開始，就是一個頭疼的問題。
早期 Java 或是 C++ 使用代碼一行一行寫界面，一個界面幾百行，順帶參入數(shù)據(jù)邏輯控制，方法接口調(diào)用，基本就是一鍋大雜燴，啥都有了。
這就導(dǎo)致代碼很難維護，修任何小問題、小改動都要看200+行代碼，腦袋里容下30多個變量，真是干過的都頭大。
怎么管理這種復(fù)雜度呢？
同許多軟件行業(yè)中復(fù)雜問題的解決方案類似：
樹。
于是 XML 站了出來。把復(fù)雜的 UI 結(jié)構(gòu)分層次、分模塊地寫成一棵樹，根部是入口，入口拆三五大模塊，每個模塊再分叉成子模塊，子模塊再分叉成子子模塊，子子孫孫無窮盡。
想象一下，100w 個節(jié)點掛在一棵二叉樹（每個節(jié)點最多分兩叉所以叫二叉）上，也就只有20層，這樣一個 XML 的解決辦法，一下就 hold 住了大量的 UI 模塊。
做過 Android 開發(fā)或 iOS 開發(fā)的朋友應(yīng)該對 XML 定義 UI 都不會陌生。如下是 Android 入門中的一個 UI 定義，簡單來看，主界面是 ConstraintLayout，一種布局，里面包含一個 TextView 文本展示 “Hello World!”.
<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".MainActivity">
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="Hello World!"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintRight_toRightOf="parent"
app:layout_constraintTop_toTopOf="parent" />
</androidx.constraintlayout.widget.ConstraintLayout>
彼時（上古時代，也就是十來年前）的前端也是用這樣的方式來定義 UI 的，稱之為 HTML。
前端那時候的工作內(nèi)容，就是把內(nèi)容搬到 HTML 里，簡單到被同行瞧不起（就是個玩具??）。不過也沒辦法，設(shè)備太慢跑不起來邏輯。急？那就在后端稍微渲染一下數(shù)據(jù)。
所以有那么一段時間，前端代碼不是純正的 HTML，而是各種改動過的版本，里面標記了許多小腳本在服務(wù)器上運行，這樣用戶下載的網(wǎng)頁可以在下載前被事先放上去一些數(shù)據(jù)，勉為其難稱之為邏輯。。吧。那個模板引擎滿天飛的舊時光。
然后，時代變了，設(shè)備變快了。
jQuery 就像一行一行寫就的 UI，跟不上 XML 的強交互性，新的時代需要一位新的霸主。React.js 應(yīng)運而生。
借著 XML （咳咳，HTML）的 UI 標記思維，設(shè)備提速的東風(fēng)，React.js 用組件（a.k.a. Component）更新了前端的設(shè)計思維。
一套完整的 UI 解決方案，更新了一個領(lǐng)域，形成了這個領(lǐng)域的新職業(yè)，才有了我們這些前端攻城獅的飯碗。
二、組件，思維模型的大一統(tǒng)
教過家里老人用手機的人，一定都體會過讓他們理解什么是按鈕的痛苦。為什么呢？因為你我上網(wǎng)多年，也被電腦程序教育了多年。我們習(xí)慣于每個界面都是個方框，方框里有文字有圖片，內(nèi)容多了可以上下滾動，按鈕總是整齊地擺在一邊。
這些潛移默化中形成的共識，是多年互聯(lián)網(wǎng)融入生活的過程，也是 XML 解決 UI 問題的過程。
你品這個過程：
- 產(chǎn)品經(jīng)理從產(chǎn)品構(gòu)思初期就在畫大框框
- 他們忙完了交付設(shè)計師，設(shè)計師在大框框里設(shè)計美觀的小框框和交互體驗
- 前端工程師把這些大大小小的框框畫進界面標記（即組件的 JSX）里，接好數(shù)據(jù)生米煮成熟飯
- 用戶拿到產(chǎn)品，直觀接受產(chǎn)品的大框架，歡心地體驗小框細節(jié)（也偶爾對著某些不靠譜的 bug 破口大罵）
整個過程從生產(chǎn)到用戶，同一個心理模型，減少多少不必要的轉(zhuǎn)換？要知道，軟件工程的宏觀視角里，就沒有轉(zhuǎn)換引不進來的坑。
（所以最高的效率就是不要轉(zhuǎn)換！不要轉(zhuǎn)換！不要轉(zhuǎn)換！不產(chǎn)生過多的心理模型，不引入思維負擔，人類還值得被拯救。）
心理模型的統(tǒng)一帶來了高效的溝通，便捷的改動，順應(yīng)時代潮流，順應(yīng)民心，自然開發(fā)也快了，bug 也少了，大家都睡得著覺了，雙雙雙贏。
組件思維也因此，從 React 走向 Vue，走向 Angular，Ionic，Svelte，Web Component 和其他。
三、鳥瞰組件規(guī)劃
講到組件之于 UI 復(fù)雜度的功效，就不得不講軟件開發(fā)的另外一個大冤種：數(shù)據(jù)管理。
不同的界面可能要用到同樣的數(shù)據(jù)，同一個界面可能又要加載不同的數(shù)據(jù)。這些稀松平常的場景，其實隱藏了一個非常大的問題：
UI 樹上掛不下數(shù)據(jù)管理的果。
左手 UI 樹，右手數(shù)據(jù)池，中間是數(shù)據(jù)牽線，這是近幾年前端工程師最平淡的日常，數(shù)據(jù)關(guān)聯(lián)密密麻麻，頭皮發(fā)麻。
用 MVC 的話說，V（View 就是 UI）和 M（Model 就是數(shù)據(jù)）站兩邊，中間 Controller 能寫多滿寫多滿。
明白這個道理，就明白了合理的組件獲取數(shù)據(jù)，是不受 UI 組件在組件樹中位置限制的。
Redux（某著名 React 全家桶數(shù)據(jù)管理庫）就提出，應(yīng)當專門把組件分成兩類：
- Presentational Components：負責組件的形，類似于櫥窗里的人臺（那個假人）
- Container Components：負責對接數(shù)據(jù)，類似于人臺身上的衣服
你再品一品前面說的大一統(tǒng)的思維模型，組件的拆分馬上就清晰了：
- 先按照產(chǎn)品的思路，大塊大塊地拆組件
- 然后按照設(shè)計師的思路，局部拆小組件
- 拆好的組件全是展示層，沒有數(shù)據(jù)（此時你就可以滿地寫
const FAKE_DATA趕緊調(diào)試了，趕在后端想好之前跟他對，兵貴神速） - 數(shù)據(jù)接進來，給 Presentational Components 套上 Container （給人臺穿上衣服）
組件越趨近于產(chǎn)品與設(shè)計師的思維模型，改動成本就越小，所以我建議你同時也多了解一下這些上游同事（專指多請客吃飯），好在下次概念大改的時候可以爭取一下。
末、彩蛋：什么道理都懂，為什么代碼還是屎山 ?
最重要的話先刷三遍：
代碼寫不好其實不怪你。
代碼寫不好其實不怪你。
代碼寫不好其實不怪你。
這是一個 Deadline 思維引起的不可持續(xù)發(fā)展的形態(tài)問題。
軟件公司一開始只有一個思維模型形態(tài)，于是做成做好很容易。
然而無論是市場還是老板，都期望這個模型有所變化，以更好地適應(yīng)用戶的需求。
于是出現(xiàn)了 v2.0。
你，無辜弱小可憐的從業(yè)者，和 HR 聊福利的時候開心得花枝亂顫，很不幸，拿到的是 v10.0 版本。前面有9個版本已經(jīng)廢棄，轉(zhuǎn)型，而且當時的人沒有留下來，想法沒有記錄下來（大概率記錄下來了，但是寫得不明不白，還有記錯的）。
給你10天時間，改 v10.0 為 v11.0。你做得了嗎？做完馬上開始 v12.0 你開得了嗎？
你必須回答做得了。
于是你折騰，深夜里痛哭，晨曦中 debug，反正懂不懂的都看到效果了，上線，然后倒頭睡覺。
Deadline 殺死了員工的懶惰心理，也葬送了對復(fù)雜度的合理管控。
這些都不重要，因為你也不可能在這家公司干一輩子不是？（事實是有限的 Deadline 面前，挑戰(zhàn)屎山大概率都是自尋死路）
所以進了下一家公司，你閉著眼睛也會說：這個項目沒法維護了，需要重寫（我才不當大冤種）。
結(jié)
軟件行業(yè)一直是一個需要快速學(xué)習(xí)的行業(yè)，今天 React 明天 Vue，學(xué)完 Java 又要學(xué) Golang。
工具更新千千萬，其實背后的原理卻不多，而且大多數(shù)對復(fù)雜度的管理早就在軟件工程專業(yè)發(fā)展的過程中被定位并解決掉了。網(wǎng)頁渲染在重前端和重后端的選擇之間反復(fù)橫跳，根本目的不過是壓榨設(shè)備的利用效率和提高開發(fā)工作的效率和質(zhì)量。
相較于技術(shù)的飛速迭代，原理本身才是陳年的老酒，在這個換湯不換藥的洪流里，始終散發(fā)著智慧的光芒。
我是雪牙，一名新手友好的程序員，帶你品酒的攻城獅。希望我的分享可以幫你清醒，思辨，成長。
感謝你的點贊、收藏和關(guān)注，祝好。
