許多入門前端的朋友都知道組件的概念蓄拣，也在日常工作中用到組件拗小，寫組件重罪，也和別人討論組件。但是前端為什么是建立在組件上的呢哀九？昔日輝煌一時(shí)的 jQuery 為什么會(huì)沒落剿配，到底要怎樣組織組件才能提高平時(shí)的工作效率，減輕邏輯復(fù)雜度引起的脫發(fā)失眠和扯皮翻臉呢阅束？
本文會(huì)從以下幾點(diǎn)回答上面的問題：
- 首先呼胚，講一點(diǎn)點(diǎn)組件概念的來源，跨多個(gè)平臺(tái)語言
- 然后息裸，掰開組件背后隱藏的線蝇更，講一下這種思維模型的大一統(tǒng)
- 再然后沪编，從軟件工程的全局視野聊組件的分類管理
- 最后算是彩蛋，聊一聊為什么“道理全都懂”就是寫不好組件
一簿寂、組件的概念源于已有的 UI 解決方案
所謂組件漾抬，其實(shí)是一種對(duì) UI 界面做組織的解決方案。復(fù)雜點(diǎn)的網(wǎng)站常遂，UI 模塊千千萬纳令，管理不好真難看。
UI 的管理克胳，從最早的桌面應(yīng)用開始平绩，就是一個(gè)頭疼的問題。
早期 Java 或是 C++ 使用代碼一行一行寫界面漠另，一個(gè)界面幾百行捏雌，順帶參入數(shù)據(jù)邏輯控制，方法接口調(diào)用笆搓，基本就是一鍋大雜燴性湿，啥都有了。
這就導(dǎo)致代碼很難維護(hù)满败，修任何小問題肤频、小改動(dòng)都要看200+行代碼，腦袋里容下30多個(gè)變量算墨，真是干過的都頭大宵荒。
怎么管理這種復(fù)雜度呢？
同許多軟件行業(yè)中復(fù)雜問題的解決方案類似：
樹净嘀。
于是 XML 站了出來报咳。把復(fù)雜的 UI 結(jié)構(gòu)分層次、分模塊地寫成一棵樹挖藏，根部是入口暑刃，入口拆三五大模塊，每個(gè)模塊再分叉成子模塊膜眠，子模塊再分叉成子子模塊稍走，子子孫孫無窮盡。
想象一下柴底，100w 個(gè)節(jié)點(diǎn)掛在一棵二叉樹（每個(gè)節(jié)點(diǎn)最多分兩叉所以叫二叉）上婿脸，也就只有20層，這樣一個(gè) XML 的解決辦法柄驻，一下就 hold 住了大量的 UI 模塊狐树。
做過 Android 開發(fā)或 iOS 開發(fā)的朋友應(yīng)該對(duì) XML 定義 UI 都不會(huì)陌生。如下是 Android 入門中的一個(gè) UI 定義鸿脓，簡(jiǎn)單來看抑钟，主界面是 ConstraintLayout涯曲，一種布局，里面包含一個(gè) 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>
彼時(shí)（上古時(shí)代在塔，也就是十來年前）的前端也是用這樣的方式來定義 UI 的幻件，稱之為 HTML。
前端那時(shí)候的工作內(nèi)容蛔溃，就是把內(nèi)容搬到 HTML 里绰沥，簡(jiǎn)單到被同行瞧不起（就是個(gè)玩具??）。不過也沒辦法贺待，設(shè)備太慢跑不起來邏輯徽曲。急？那就在后端稍微渲染一下數(shù)據(jù)麸塞。
所以有那么一段時(shí)間秃臣，前端代碼不是純正的 HTML，而是各種改動(dòng)過的版本哪工，里面標(biāo)記了許多小腳本在服務(wù)器上運(yùn)行奥此，這樣用戶下載的網(wǎng)頁可以在下載前被事先放上去一些數(shù)據(jù)，勉為其難稱之為邏輯雁比。得院。吧。那個(gè)模板引擎滿天飛的舊時(shí)光章贞。
然后，時(shí)代變了非洲，設(shè)備變快了鸭限。
jQuery 就像一行一行寫就的 UI，跟不上 XML 的強(qiáng)交互性两踏，新的時(shí)代需要一位新的霸主败京。React.js 應(yīng)運(yùn)而生。
借著 XML （咳咳梦染，HTML）的 UI 標(biāo)記思維赡麦，設(shè)備提速的東風(fēng)，React.js 用組件（a.k.a. Component）更新了前端的設(shè)計(jì)思維帕识。
一套完整的 UI 解決方案泛粹，更新了一個(gè)領(lǐng)域，形成了這個(gè)領(lǐng)域的新職業(yè)肮疗，才有了我們這些前端攻城獅的飯碗晶姊。
二、組件伪货，思維模型的大一統(tǒng)
教過家里老人用手機(jī)的人们衙，一定都體會(huì)過讓他們理解什么是按鈕的痛苦钾怔。為什么呢？因?yàn)槟阄疑暇W(wǎng)多年蒙挑，也被電腦程序教育了多年宗侦。我們習(xí)慣于每個(gè)界面都是個(gè)方框，方框里有文字有圖片忆蚀，內(nèi)容多了可以上下滾動(dòng)矾利，按鈕總是整齊地?cái)[在一邊。
這些潛移默化中形成的共識(shí)蜓谋，是多年互聯(lián)網(wǎng)融入生活的過程梦皮，也是 XML 解決 UI 問題的過程。
你品這個(gè)過程：
- 產(chǎn)品經(jīng)理從產(chǎn)品構(gòu)思初期就在畫大框框
- 他們忙完了交付設(shè)計(jì)師桃焕，設(shè)計(jì)師在大框框里設(shè)計(jì)美觀的小框框和交互體驗(yàn)
- 前端工程師把這些大大小小的框框畫進(jìn)界面標(biāo)記（即組件的 JSX）里剑肯，接好數(shù)據(jù)生米煮成熟飯
- 用戶拿到產(chǎn)品，直觀接受產(chǎn)品的大框架观堂，歡心地體驗(yàn)小框細(xì)節(jié)（也偶爾對(duì)著某些不靠譜的 bug 破口大罵）
整個(gè)過程從生產(chǎn)到用戶让网，同一個(gè)心理模型，減少多少不必要的轉(zhuǎn)換师痕？要知道溃睹，軟件工程的宏觀視角里，就沒有轉(zhuǎn)換引不進(jìn)來的坑胰坟。
（所以最高的效率就是不要轉(zhuǎn)換因篇！不要轉(zhuǎn)換！不要轉(zhuǎn)換笔横！不產(chǎn)生過多的心理模型竞滓，不引入思維負(fù)擔(dān)，人類還值得被拯救吹缔。）
心理模型的統(tǒng)一帶來了高效的溝通商佑，便捷的改動(dòng)，順應(yīng)時(shí)代潮流厢塘，順應(yīng)民心茶没，自然開發(fā)也快了，bug 也少了晚碾，大家都睡得著覺了抓半，雙雙雙贏。
組件思維也因此格嘁，從 React 走向 Vue琅关，走向 Angular，Ionic，Svelte涣易，Web Component 和其他画机。
三、鳥瞰組件規(guī)劃
講到組件之于 UI 復(fù)雜度的功效新症，就不得不講軟件開發(fā)的另外一個(gè)大冤種：數(shù)據(jù)管理步氏。
不同的界面可能要用到同樣的數(shù)據(jù)，同一個(gè)界面可能又要加載不同的數(shù)據(jù)徒爹。這些稀松平常的場(chǎng)景荚醒，其實(shí)隱藏了一個(gè)非常大的問題：
UI 樹上掛不下數(shù)據(jù)管理的果。
左手 UI 樹隆嗅，右手?jǐn)?shù)據(jù)池界阁，中間是數(shù)據(jù)牽線，這是近幾年前端工程師最平淡的日常胖喳，數(shù)據(jù)關(guān)聯(lián)密密麻麻泡躯，頭皮發(fā)麻。
用 MVC 的話說丽焊，V（View 就是 UI）和 M（Model 就是數(shù)據(jù)）站兩邊较剃，中間 Controller 能寫多滿寫多滿。
明白這個(gè)道理技健，就明白了合理的組件獲取數(shù)據(jù)写穴，是不受 UI 組件在組件樹中位置限制的。
Redux（某著名 React 全家桶數(shù)據(jù)管理庫(kù)）就提出雌贱，應(yīng)當(dāng)專門把組件分成兩類：
- Presentational Components：負(fù)責(zé)組件的形啊送，類似于櫥窗里的人臺(tái)（那個(gè)假人）
- Container Components：負(fù)責(zé)對(duì)接數(shù)據(jù)，類似于人臺(tái)身上的衣服
你再品一品前面說的大一統(tǒng)的思維模型欣孤，組件的拆分馬上就清晰了：
- 先按照產(chǎn)品的思路馋没，大塊大塊地拆組件
- 然后按照設(shè)計(jì)師的思路，局部拆小組件
- 拆好的組件全是展示層导街，沒有數(shù)據(jù)（此時(shí)你就可以滿地寫
const FAKE_DATA趕緊調(diào)試了，趕在后端想好之前跟他對(duì)纤子，兵貴神速） - 數(shù)據(jù)接進(jìn)來搬瑰，給 Presentational Components 套上 Container （給人臺(tái)穿上衣服）
組件越趨近于產(chǎn)品與設(shè)計(jì)師的思維模型，改動(dòng)成本就越小控硼，所以我建議你同時(shí)也多了解一下這些上游同事（專指多請(qǐng)客吃飯）泽论，好在下次概念大改的時(shí)候可以爭(zhēng)取一下。
末卡乾、彩蛋：什么道理都懂翼悴，為什么代碼還是屎山 ?
最重要的話先刷三遍：
代碼寫不好其實(shí)不怪你。
代碼寫不好其實(shí)不怪你。
代碼寫不好其實(shí)不怪你鹦赎。
這是一個(gè) Deadline 思維引起的不可持續(xù)發(fā)展的形態(tài)問題谍椅。
軟件公司一開始只有一個(gè)思維模型形態(tài)，于是做成做好很容易古话。
然而無論是市場(chǎng)還是老板雏吭，都期望這個(gè)模型有所變化，以更好地適應(yīng)用戶的需求陪踩。
于是出現(xiàn)了 v2.0杖们。
你，無辜弱小可憐的從業(yè)者肩狂，和 HR 聊福利的時(shí)候開心得花枝亂顫摘完，很不幸，拿到的是 v10.0 版本傻谁。前面有9個(gè)版本已經(jīng)廢棄孝治，轉(zhuǎn)型，而且當(dāng)時(shí)的人沒有留下來栅螟，想法沒有記錄下來（大概率記錄下來了颊艳，但是寫得不明不白谆棺，還有記錯(cuò)的）。
給你10天時(shí)間，改 v10.0 為 v11.0拳话。你做得了嗎？做完馬上開始 v12.0 你開得了嗎烙如？
你必須回答做得了爹袁。
于是你折騰，深夜里痛哭赘那，晨曦中 debug刑桑，反正懂不懂的都看到效果了，上線募舟，然后倒頭睡覺祠斧。
Deadline 殺死了員工的懶惰心理，也葬送了對(duì)復(fù)雜度的合理管控拱礁。
這些都不重要琢锋，因?yàn)槟阋膊豢赡茉谶@家公司干一輩子不是？（事實(shí)是有限的 Deadline 面前呢灶，挑戰(zhàn)屎山大概率都是自尋死路）
所以進(jìn)了下一家公司吴超，你閉著眼睛也會(huì)說：這個(gè)項(xiàng)目沒法維護(hù)了，需要重寫（我才不當(dāng)大冤種）鸯乃。
結(jié)
軟件行業(yè)一直是一個(gè)需要快速學(xué)習(xí)的行業(yè)鲸阻，今天 React 明天 Vue，學(xué)完 Java 又要學(xué) Golang。
工具更新千千萬鸟悴，其實(shí)背后的原理卻不多陈辱，而且大多數(shù)對(duì)復(fù)雜度的管理早就在軟件工程專業(yè)發(fā)展的過程中被定位并解決掉了。網(wǎng)頁渲染在重前端和重后端的選擇之間反復(fù)橫跳遣臼，根本目的不過是壓榨設(shè)備的利用效率和提高開發(fā)工作的效率和質(zhì)量性置。
相較于技術(shù)的飛速迭代，原理本身才是陳年的老酒揍堰，在這個(gè)換湯不換藥的洪流里鹏浅，始終散發(fā)著智慧的光芒。
我是雪牙屏歹，一名新手友好的程序員隐砸，帶你品酒的攻城獅。希望我的分享可以幫你清醒蝙眶，思辨季希，成長(zhǎng)。
感謝你的點(diǎn)贊幽纷、收藏和關(guān)注式塌，祝好。
