什麼叫組件化開發?
我很好奇為什麼越來越重視組件化開發，ext.js卻被邊緣化
我來答一下這個吧
從第一代碼農寫下第一行代碼開始到上個世紀的80年代的軟體危機，碼農一直在考慮一個問題，怎麼讓寫代碼容易。拋開找大牛，大神程序員這條路(你以為大牛，大神那麼容易找啊)，最後自然而然形成的一套思路就是大團隊的協同合作(如同cpu發展史一樣，從飆主頻到飆核數)。 協同合作？----- 這個可就麻煩了。。。。團隊。。。。還合作。。。。 幾乎所有的碼農開始代碼的時候(我強調了幾乎，不是全部，我強調了開始，不是所有時候)寫代碼的都是以自我為中心的。怎麼解釋這種情況呢，就是cow code---牛仔代碼，代碼風格隨意看心情。這就導致了寫代碼協作起來極為麻煩，為什麼呢？我寫代碼的時候 ，我和上帝知道什麼我寫的什麼，過了一個月就只有上帝知道寫的什麼了。這個問題在前端領域尤其嚴重，原因有如下幾點：- 因為這個領域沒多少年
- html/js/css發明出來的時候就只玩玩而已的工具，技術棧非常不成熟。
- 這個領域人員水平參差不齊。
- 這個最坑爹了：JS是單線程的，CSS是全局的。。。尼瑪。。。。幾個人一起搞，一個bug全家玩完。。。
你這讓人怎麼幹活。。。。活那麼多。。。。人那麼多。。。。相互坑不出活，老闆會fire掉大家的。
很早就有人來想辦法解決這個問題，在軟代時代就已經有解決這個問題的法寶－－組件化。當然那時候不是那麼叫的，是通過兩個原則來規範這個問題的，這兩個原則就是：內聚性和耦合性。
意思就是：哥，我想按時回家哄妹子！！！你怎麼寫代碼我不管，你的功能全在這你這兒實現（內聚性），不要讓我還幫寫你那塊功能。另外，哥，求你了，你代碼不要block(影響)我的代碼（低耦合性）。既然解決問題的思路在這兒，前端大牛一代代前赴後繼的在這條路上狂奔下去。
第一代：YUI 200X年的時候，這個框架火啊。把JS的坑都填了以後，比較low的事情就差不多解決完了。就直撲組件化，當時一派盛世，彷彿從此以後，前端界一馬平川，大家再也不用一行行代碼去寫了。 YUI已經已經給了大家全部。。
YUI解決了組件化的問題，但是太過於學院派。要求每個用這個程序員如同學校里的好學生一樣要熟悉整套UI規範和使用規範。就是你還是要熟悉YUI的CSS，HTML，JS，這樣才能用非常爽。這就如同你如果你是個學渣，學霸把卷子給你抄了，如果你沒好好聽過課，給你抄你都會把抄成8，會把
抄成Eba。
第二代 ExtJS
ExtJS是踩著YUI的屍體走過來的，第一版的extjs完全是拿yui改的。我第一次寫ExtJS寫東西的時候，我哭了。。。我感覺我要失業了。太特么，太特么，太特么好用了。這完全是給後端程序員的大大的禮物，看著一個個Java碼農寫著自己的業務邏輯，順帶著把前端全搞定，而且還比你們一個個前端碼農還搞得好得多的時候，完完全全的失落感啊，好像世界已經完全不需要前端了，整個世界都變黑了。。。。。。 extjs比YUI進步在那兒呢，首先它表面上有一套漂亮的UI。這個實質上就是你不用寫CSS了，它幫你寫好了。另外你HTML也不用寫了，它也幫你寫好了。這不對啊，前端頁面怎麼可以沒有HTML和CSS呢----------------extjs都幫你封裝到js里了。。。
這就如同你是個學渣，學霸把卷子給你抄了，而且這回的卷子還都是選擇題....
可是PM、老闆不是吃素的。。。大家都有一身好手藝啊，難分高下啊，那來個附加題吧-----這一塊不太好看啊，加個閃閃的效果，那一塊左右動動吧。。。。。。。。
第三代：web component
w3c，google什麼的都突然有一天發現。iphone一出，我們的數錢數得手抽筋的好日子是快完了吧。以後感覺沒web什麼事了額。。。。。砸帥哥，霉女一見面都問裝啥app，都不用電腦，筆記本，更談不上看網頁了呢。。。。 gg一想，"不行啊"，然後google買了android，"還是不行啊，我現在這麼容易掙這麼多錢，我就是把android養大了也不見得掙現在這麼多錢額。我還是得把web這塊保住啊」，w3c趕緊附和道：「對，對，對」。然後大家都知道了chrome 拚命刷版本從1~47沒用幾年吧。。。。web的規範是一波波的出啊， es4,5,6,7全出來了。然後就有了web component橫空出世，帶著四個小弟shadow dom/custom element/template/import。
這回組件化的卷子又有什麼不同呢？
學校太差要被撤，學霸學渣站一條線上了，即然大家都要完，我們一起拼一把吧。 「好」：學霸，學渣異口同聲 然後學霸幫學渣把卷子都做好了，然後對學渣說：「哥，你寫上你名字吧！「 這次的組件化完完全全不一樣了，custom element的出來的組件，可以是以前任意的東西，然後註冊成任意一個名字的組件，可以就&
&
&
&
&
&
&
&
&
這是前端代碼么，怎麼這麼少。。。。。
這可是妥妥一個完整的界面啊，有banner，電話輸入框，和電話列表啊。這是要鬧那樣，代碼往那裡寫，代碼往那裡寫啊。。。。
這正是奧妙之所在，可以三個同學同時寫&
但是。。。
但是。。。但是一般都是是故事的。。。。
這規範到不成熟，到處是坑啊，我會跟你說么 T_T
- Angular Directives
- Ember Components
- React Components
- KnockoutJS Components
- Vue.js Components
- Backbone Components
- CanJS Components
- Famous Components
- Anything.JS Components?
最近聽到「組件化」這詞的時候，總是覺得很不爽，就像當年聽到「Web2.0」一樣。我認為，正如同Web2.0至今沒有一個官方的、公認的、明確可判斷的定義（Wiki那個沒有明確性）一樣，「組件化」在前端領域直到它退出大眾視野為止，也不會有一個官方的、公認的、明確可判斷的定義
而題主的問題，其實是兩部分：- 什麼叫組件化開發
- 為什麼ExtJS被邊緣化
在這一點上我堅決不同意「ExtJS不是組件框架」這一說法
先挑簡單的說，為什麼ExtJS會邊緣化作為一個曾經現象級的框架，ExtJS是一個優秀的框架，這一點都不需要質疑，但它確實在當今被邊緣化了，這與ExtJS出生的時代、定位有很大的關係ExtJS出生在一個前端被邊緣化的時代（今天輪到你自個兒被邊緣化了哈哈哈），在那個年代，大家更關注於怎麼去實現邏輯，而非怎麼去實現用戶可交互的部分，在這樣的技術結構下，前端成了很多工程師的一個難點，其原因不是JavaScript，而是因為前端有兩門非「Java化」的語言：CSS和HTML而ExtJS的目的之一就是解決這兩門語言，所以ExtJS在整個設計上以「只使用JavaScript可以完成應用構建」為目標，也就是我們看到的一堆JavaScript聲明頁面結構和交互
這在那個時代無疑是成功的，但卻埋下了兩個隱患：- 從整個架構層面上損失了定製性，主要指CSS的定製性。這在整個框架生成的DOM結構上可見一斑，人就沒指望你去定製CSS，乖乖用官方皮膚吧
- 由於需要從JavaScript再解析到DOM，有一定的性能損失，雖然使用各種方案挽回了一些，但是流暢性從一開始就難以做到極致
這兩點在一開始並不成問題，反正那個以IE6為主的年代啥頁面都這麼慢，而且ExtJS那套皮膚在當年可是眼前一亮驚嘆不已，都漂亮成那樣了哪管得著定製性
但是到了如今的年代，前端不斷地追求差異化、定製化，同時由用戶體驗的需求而引申出的流暢、性能等都被提到桌面上，那麼ExtJS的兩個隱患就被放大，慢慢不再被人容忍。現在說到ExtJS，很多朋友第一反應就是「慢」，第二反應就是「丑」，也正是如此但其實ExtJS從一個框架（現在已然是解決方案）的層面上來說是很不錯的，包括其MVVMC的模型也是很解決複雜應用的問題的然後再回來說組件化是什麼，但實在沒啥好說的，因為我已經給了個「這東西沒啥明確定義」的結論……但是 張克軍 提出的「組件化就是函數式界面開發」這一說法我是難以接受的，函數式界面開發就讓它好好地叫「函數式組件化」吧，不然我們會在所謂的「傳統UI框架」和「函數式界面開發」之間出現一個Gap，豈不是又要造個詞給填上，多累……我前面說會有一個Gap，這個Gap很可能就是我們現在想用「組件化」這個定義去表達的一些點，我想在此做一些個人的見解我將之理解為以下幾要素：- 組件是對邏輯的封裝，不限於圖形元素。即我們可以把if做成組件、把一個倒計時做成組件、把一段動畫做成組件、把路由做成組件、把數據架構做成組件，而這些並不能稱為控制項
- 組件具備單個可移植性，即「隨載入隨用」，不需要為其準備複雜的基礎條件（如引入樣式、引入框架等）。然而這一點現有那些所謂組件庫做得並不好，技術上也不大現實
- 組件是聲明式定義的，而非命令式。這個不想多說，很大程度上是自己主觀的一個想法
而上面最重要的就是第一點，所以要問我什麼是「組件化開發」，我的說法是：
把圖形、非圖形的各種邏輯均抽象為一個統一的概念（組件）來實現開發的模式
這與傳統開發框架的最大區別就是統一了圖形元素與非圖形元素，除此之外我再想不出其它真正體現區別的點了
在這個概念下，包括router、ajax、module loader、timer、animation、interval等，都是組件，共享統一的生命周期管理和對外介面，且都是聲明式地進行組合我的一位同事告訴我去年的深JS上，有位淘寶的朋友的話題叫做「前端組件服務化」，這裡面提的那些個概念，是很符合我對「組件化」的認識的，他要是不給再強安個「服務化」的噱頭就好了- -不過話說回來，在這個要求之下，組件其實不是那麼好進行抽象設計的，隨便說幾個例子，有難的也有簡單的：- 非圖形元素的各種需求如何統一介面，如timer和ajax
- 組件可以橫向組件，但是縱向復用如何解決，如希望任何圖形元素都可以實現被滑鼠拖拽的效果，則滑鼠拖拽應該也是個組件，這個組件與其它組件的關係是什麼
- 有些組件對其可被組合的組件是有要求的，比如HTML里就不大好意思把一個&
放進一個&里，這一點如何在組件上表達（實現不難，表達比較難）
- 一些我們原本想當然認為純的小函數的東西，是不是也能當組件玩，比如underscore.pick要不要也是個組件
想想挺好玩的……
雖然沒有阿當這麼極端，但我真心希望，前端能少一些概念名詞，踏踏實實地提出我們面對的問題，探討解決的方案，合作技術的實現，共享最後的成效……瀉藥，針對你的問題，挨個說下自己的看法。
1，組件化不是越來越重視，而是一直都很受重視。
2，extjs並沒有邊緣化，很多企業內部系統都是依靠這一套東西做的二次開發，我認識幾個比較老的前端extjs玩的很6。不同的框架，在一出現的時候就確定了他要解決的問題，所以如果你不是他的目標用戶，你肯定感覺他很『邊緣化』。3，什麼叫組件化開發。我正好也做過幾個自己理解的組件庫，我看有同學截圖了yui2的組件列表，看著真的好懷念，當初我還用我的小諾基亞天天車上看這些文檔呢。
我很同意他的這個舉例，就是你去看yui2里的那些組件list吧，他們是實際的解決了web開發中需要遇到的一系列特別問題，比如截圖，比如搜索提示，比如懶載入，比如表單驗證，比如跨域的圖片上傳，比如一個表情控制項，日期日曆控制項等。
到底什麼是組件化呢。
我舉個最最簡單的例子：
再看一個：
當瀏覽器未提供，但是我們日常開發又頻繁要遇到的一些特定功能組合，我理解為一個組件，如：
對應的日曆控制項，調色板，web也提供了，只不過沒那麼好用而已，但是其實他們都是組件，只不過我們平時不常用而已。
所以，因為我們的需求不斷變化，我們需要的功能越來越多，所以組件開發是一個持續積累的過程，當然瀏覽器開發商也會意識到，但是等他們開發出來提供給我們，黃花菜都涼了，so，自己造咯。
這就是我理解的組件化。可能和很多人的理解不一樣，但是其實說白了我們只是為瀏覽器填了它應該填的坑而已。你好，組件化其實並不是一個很難理解的詞語，但可能每個人的理解都有所偏頗。以下我用簡單的語言描述類比一下：
組件化就好像我們的 PC 組裝機一樣，整個機器（應用）由不同的部件組成，例如顯示器、主板、內存、顯卡、硬碟等等。自己組裝的 PC 有這麼幾個好處：- 在保持硬體的兼容性前提下，隨意更換每一個部件，都不會影響整個機器的運行
- 當機器出現了問題的時候，我們可以通過插拔法快速定位硬體錯誤
- 假如 PC 跑不起四路泰坦的仙劍6，我們可以單獨更換顯卡或者升級內存
假如把以上特點對應到前端領域中，組件化開發有如下的好處：
- 降低整個系統的耦合度，在保持介面不變的情況下，我們可以替換不同的組件快速完成需求，例如輸入框，可以替換為日曆、時間、範圍等組件作具體的實現。
- 調試方便，由於整個系統是通過組件組合起來的，在出現問題的時候，可以用排除法直接移除組件，或者根據報錯的組件快速定位問題，之所以能夠快速定位，是因為每個組件之間低耦合，職責單一，所以邏輯會比分析整個系統要簡單。
- 提高可維護性，由於每個組件的職責單一，並且組件在系統中是被複用的，所以對代碼進行優化可獲得系統的整體升級。例如某個組件負責處理非同步請求，與業務無關，我們添加緩存機制，序列化兼容，編碼修正等功能，一來整個系統中的每個使用到這個組件的模塊都會受惠；二來可以使這個組件更具健壯性。
在團隊開發中，組件化帶來的優勢是便於協同開發，由於代碼中的耦合度降低了，每個模塊都可以分拆為一個組件，例如非同步請求組件，路由組件，各個視圖組件。團隊中每個人發揮所長維護各自組件，對整個應用來說是精細的打磨。
在Javascript 的開發中，組件化其實和模塊化的意義相當，大概是根據功能、業務進行代碼劃分，使到這部分的代碼可以被複用，例如 $、_ 這些工具庫就是將功能進行模塊化。在近一兩年中，ng、react 等在我們開發的 view 層中引入一些自定義標籤就可以渲染出整個組件，大家會覺得組件化這東西比較新穎，其實本質上和我們以往的模塊化並無差別。
希望可以對你有點幫助
利益相關：寫過兩個組件化框架，對組件化有一定的見解...
EXT就如克軍所說的，它是一個UI庫，並不是一個組件化開發框架。
當下的組件化開發，所指應是類 Web Components 的開發方式（例如：React）。
在組件化方面，它主要有以下兩個特點：1. "組": 組合的方式
當下的組件化是聲明式的使用方式，用在HTML上就如下雨天與巧克力一樣融洽。 如果使用命令式的組合方式，那得在HTML上挖坑。2. "件": 原子性質
物理結構上，組件所依賴的資源(template／js／css)放在一起，這也是雲龍工程化概念中關於組件的觀點。 運行時，組件所對應的 DOM 與組件實例綁定在一起。DOM 是 UI組件最重要的構成元素，就如 React 做後端渲染，萬水千山也要在前端運行時找（反射）回來。最後，當下的組件化框架都會帶上 data-binding 這是一個提高開發效率／代碼可讀性／代碼可維護性的終極利器。組件化一定程度上可以約等於模塊化，調用者只需關注輸入和輸出，相互之間沒有影響
用張雲龍大大的解釋，組件化開發是指
頁面上的每個 獨立的 可視/可交互區域視為一個組件;
每個組件對應一個工程目錄，組件所需的各種資源都在這個目錄下就近維護;每個組件相對獨立，頁面只不過是組件的容器，組件自由組合形成功能完整的界面;當不需要某個組件，或者想要替換組件時，可以整個目錄刪除/替換。
組件化開發是前端工程化的一環
除此之外，前端工程化還包括模塊化開發，模塊化開發又由CSS模塊化、HTML模塊化、JS模塊化組成。在我看來，Ext / Bootstrap 作為UI庫，將樣式和JS整合在一起，作為第三方文件，本質上和組件化是背道而馳的。應該是以組件化的形式開發，開發過程中，經由前端構建工具生成一個和 Ext/Bootstrap 類似的樣式庫。在前端領域就是函數式用戶界面開發
Ext / Bootstrap 之類的是可定製的UI庫，並非當下所云的「組件化開發」什麼叫組件化？ 本質就一點：封裝。
這難道不是理所當然的嗎？
Web前端之所以「強調」組件化，是因為結合其核心問題（GUI開發）和技術體系（Web規範），暫時沒有很好的組件化方案，這其中涉及相當多的問題，有空細寫。
重要，但是又沒有，才要追求。如果說html+css+javascript就相當於 名詞+形容詞+動詞 構成web前端的所有表現的話，比如隨便說一句「漂亮的你走過來」。那麼把這三樣東西合併為一個詞 比如『你來』，甚至一個暗號『a』。。就是表達「漂亮的你走過來」。那麼a就是一個組件。並且a還具備繼承、封裝等。比如ab表示 醜陋的你走過去。。。。不知道講的是否清楚extjs本身能表達出的東西有限，界面可擴展性較弱，不過我們已經在源碼的基礎上繼承或者覆蓋開發適應公司內部程序需要的新封裝。不過感覺這也只適合程序員用，喜愛美觀界面的美工也愛莫能助
如果說html+css+javascript就相當於 名詞+形容詞+動詞 構成web前端的所有表現的話，比如隨便說一句「漂亮的你走過來」。那麼把這三樣東西合併為一個詞 比如『你來』，甚至一個暗號『a』。。就是表達「漂亮的你走過來」。那麼a就是一個組件。並且a還具備繼承、封裝等。比如ab表示 醜陋的你走過去。。。。不知道講的是否清楚extjs本身能表達出的東西有限，界面可擴展性較弱，不過我們已經在源碼的基礎上繼承或者覆蓋開發適應公司內部程序需要的新封裝。不過感覺這也只適合程序員用，喜愛美觀界面的美工也愛莫能助
組件有大有小。粒度，就看你怎麼分了。web app，page，component，element……
對於頁面需要高度自定義的時候，bootstrap根本沒法用然而我是個全棧工程師，這些封裝庫都是扯蛋
一、說題外話，程序的可持續，不外乎代碼的：分類，管理，可讀性，粒度，是否冗餘。二、前端是非常講求高效率的，ext.js被邊緣化，可能是入門和基於需求的相應變化不夠（二次開發難）。component 一個概念罷了。 import/require 在後端語言不是一開始就有了么？
吐槽一下：最煩 組件(Component) 和 模塊(Module) 這兩個詞了，高度抽象，沒有上下文毫無意義。
--------------
回答題主的疑問 ext.js為什麼被邊緣化
先來回顧一下有哪些 Web前端組件化框架或庫
1. 瀏覽器上加運行時的
- Applet / JavaFX
- Activex
- Flex
- Silverlight
2. 後端封裝
- JSF
- http://ASP.net
- Google Web Toolkit
- tapestry / wicket
3. 重量級框架
- extjs
4. 輕量級庫
- react
- vue.js
- Polymer
先說一下 1和2 為什麼被邊緣化
1. modern browser市場份額越來越大, html5越來越流行，瀏覽器上加運行時的有點多餘了，廠商基本都放棄了
2. 前後端分離，後端封裝框架幾乎沒有了生存空間
再談 extjs
@張立理 提到的埋下了兩個隱患，說的很好，我在補充幾點我的看法
1. 這幾年，瀏覽器飛速發展，同時compile和polyfills 也在想辦法填平各瀏覽器和標準之前的坑。但是extjs 還是一個人在戰鬥，發展太慢，最新的extjs 6.x 使用的還是自己定義的 Class 和 module, 6.0 才加入 Promises支持，構建工具也是自己的 Sencha Cmd 。
2. 當年 前後端 未分離的時候，大量Java程序員，只用js就可以寫前端是一個優勢；但是前後端分離後，給前端的同學增加了很大的學習成本，CSS和HTML沒有多少用武之地。
3. extjs 太重，減少了使用範圍，以前寫網站後台管理用extjs，前台網站還得用 jquery；現在 react 和 vue.js 都支持服務端渲染，核心庫都非常小，寫前台網站完全沒有問題。知乎問題也用的是 react，掘金 - juejin.im 用的是 vue.js .........
------------------
看了一下 sencha 的最新動態，sencha好像意識到了這些問題
1. SenchaCon 2016
用 ES6 寫extjs，感覺很不一樣，不過要等到 2017 下半年
2. sencha github
sencha/extjs-reactor （on 3 Nov 2016 v0.1.0）
這個項目更NB了 Use Ext JS components in React，看一下代碼
import React from "react";
import ReactDOM from "react-dom";
import { install, reactify } from "@extjs/reactor";
// Install the Ext JS custom renderer
install();
// Create a React component to wrap Ext.Panel
const Panel = reactify("panel");
// When Ext JS loads, initialize our React app
Ext.onReady(() =&> {
ReactDOM.render(
(
&
Hello World!
&
),
document.getElementById("root")
);
});
組件化只是所有GUI開發的一種思路，總思想就是分而治之、重複利用。
不管是.net還是android，抑或是web。另外，在android等客戶端GUI里，可能還有『插件化』的說法，其實意思差不多，只是環境不同，解決的問題不同。
另外，組件化與oo的聯繫：『組件化』可能需要利用『oo』的繼承、封裝、多態等方法去實現。每次提到組件，很多人第一時間就想到「復用」，好像組件帶來的唯一好處就是復用，不需要復用的地方就沒必要寫成組件一樣。
組件歸根結底就是一種視圖+交互邏輯的抽象數據類型，抽象數據類型帶來明顯好處：
- 提高代碼內聚性，降低耦合度
- 使用介面（props、events和methods）使少量的耦合明顯且可控
- 拆分複雜度，減少你需要同時關注的代碼量和狀態，減輕程序員的思維負擔
- 隔離複雜度，把高複雜度的代碼隔離起來，易於維護和重構
- 隔離易變部分，把頻繁變化的部分（一般是因為需求瞎JB提）隔離起來，每次改這部分就好
- 想不起來了，，，
最常見的抽象數據類型就是類，Vue組件是不是繼承自Vue類的子類？React組件是不是繼承自React.Component類的子類？（你非要說純函數組件，那也可以理解成只有render方法+props屬性的類）
因此使用視圖+交互邏輯的抽象數據類型+裝飾者模式來組織和編寫GUI代碼就叫「組件化開發」。
什麼叫組件化開發?回答這個問題之前,我們先來科普何為組件化? 這個問題伴隨著HTML5技術的發展，一直都沒有一個官方的定義。那麼我認為的組件化就是: 組件化就是跟你的業務邏輯封裝一段可重用可復用的代碼。這些代碼包含HTML代碼，更重要的是包含高度復用的邏輯。記住，組件化的本質就是封裝。
縱觀當前前端比較流行的幾大框架，他們的核心思想都離不開組件化，因為我們前端程序必須實現組件化，只有這樣，才能大大的提高我們的項目開發速度，才能讓我們的項目變得可輕鬆的維護，可任選的迭代。Vue 框架也是實現組件化，通過Vue.component來實現組件化開發，一個組件就是一個微型的vm實例對象，react更不用說，就是高度組件復用和組件內聚，同樣，現在用typescript編寫的angular4.0框架，也是如此，angular4.0可謂是組件化開發的核心代表。這些趨勢，都表面組件化開發是未來前端開發的發展趨勢，我們前端程序員必定都在實現組件 高耦合低內聚的 的路上奮鬥著。
組件化開發，我們都已經明白了，就是開發包含template(模板),style,script等組合起來的代碼塊。我們可以通過一張圖來完美解釋一下:
這張圖就可以清楚的給大家解釋，基本的組件的構成。我們在進行前端app 的開發時候，可以把任何的一個html 代碼封裝成一個組件，當然，你這麼做的前提是你要實現組件的可復用性，比如說，你可以封裝 具有特殊酷炫動畫的 button 組件，那麼你在任何頁面需要有實現這樣的動畫的時候，你 就通過你自己定義的方式去引入你的這個button組件。
同樣的，我們來分析一款app,就比如分析外賣App餓了么。餓了嗎是實現組件化開發的代表，它使用的是自己開發mint-ui的組件框架。我們可以餓了么看做是 很多組件組合起來的大的app，它的首頁包含很多 item 組件，當然包含下拉和上滑組件，而且肯定包含很多button組件，也有對應的訂單組件。下面這張圖已經包含了餓了么app組件化開發的大致思想吧。
那我們現在來仔細聊聊，什麼是組件化開發呢？相比大家已經有自己心中的見解了吧。當你想實現封裝的邏輯的時候，想提高你的工作效率的時候，這個時候你就有必要想想通過封裝組件，把對應的業務邏輯綁定到視圖元素裡面去，來實現高度復用和低內聚的代碼邏輯。
組件化的實現就是 分而治之。頁面邏輯過於複雜，便將頁面分為很多個業務組件模塊分而治之，這樣的話維護人員每次只需要改動對應的模塊即可，以達到最大程度的降低開發難度與維護成本的效果，所以現在比較好的框架都會對組件化作一定程度的實現。所以組件化開發更多的著眼於長遠發展而使用的一種架構思想，組件一般是與展示相關，視覺變更與交互優化是一個產品最容易產生的迭代，所以多數組件相關的框架核心都是View層的實現，比如Vue與React的就認為自己僅僅是「View」，雖然展示與交互不斷的在改變，但是底層展示的數據卻不常變化，而View是表象，數據是根本，所以如何能更好的將數據展示到View也是各個組件需要考慮的，從而衍生出了單向數據綁定與雙向數據綁定等概念，組件與組件之間的通信往往也是數據為橋樑。這裡很多大型架構都有自己的管理數據的架構，比如說vuex,redux等等。
最後我們如果想在我們的項目中來實現組件化開發，我建議各位可以先去學習一些關於模塊化思想的框架，比如seajs和requireJs,這2個插件是幫助我們實現javascript邏輯模塊化的插件。而且我們可以去接觸學習組件化開發的核心代碼，vue和react,去學習人家的對應的UI組件庫，如mint-ui,element-ui,ant-design等等，學習人家是如何封裝和實現組件邏輯的復用的，到時候大家也會很輕易的編寫組件化開發的代碼的。
模塊化開發
終於理解了一些了，謝謝各位通俗易懂的解釋
推薦閱讀：
※怎麼為大中型的vue.js項目編寫e2e測試？
※想學習angular，害怕找不到工作怎麼辦？
※如何看待《寫在 Element 一周年之際》中 element-ui 指責 iview 抄襲這件事？
TAG:前端開發 | JavaScript |