隨著技術的發展，開發的複雜度也越來越高，傳統開發模式總是存在著開發效率低，維護成本高等的弊端。（介面開發太多，風格樣式隨時都可能調整，如果要調整，可能所有的專案都需要調整，牽一髮而動全身）
專案越來越多,針對專案進度以及時間要求每個人對專案樣式的支援度不是很高，需要乙個統一的模式進行管理，提公升開發人員的工作效率以及減少bug的產生，讓開發人員能夠更好地投入到業務開發中,發現元件化開發非常必要
前端的元件化開發，可以很大程度上降低系統各個功能的耦合性，資料相互獨立，並且提高了功能內部的聚合性。這對前端工程化及降低**的維護來說，是有很大的好處的，內部結構密封，不與全域性或其他元件產生影響，特別是針對邏輯複雜的功能能夠進行拆分，更好排查問題。（就像電腦零件一樣，針對各個零件的問題進行調整）
耦合性的降低，提高了系統的伸展性，降低了開發的複雜度，提公升開發效率，降低開發成本。
因為功能已經完善，專案中使用的元件能夠讓人員更少的接觸元件內部通用的邏輯，更加投入到業務的開發，提公升大家的開發效率，減少bug的生成，還能讓新人員更好、更快的接入公司的開發任務。
目前很多公共元件和專案依賴很多相同的node_modules，如果對元件開發經驗不足，中間配合起來，版本不一致可能會導致node_modules出現未知的問題，各個版本針對不同環境也要做區分。
1.標準性
2.專一性
3.拆分性（需要開發人員來把控）
4.可維護性
5.可配置性1.介面
2.互動
3.檢視
4.邏輯
5.樣式
6.狀態/屬性
分為三個版本
~允許小版本迭代
eg.:
^允許大版本迭代
鎖定（控制）版本
package-lock.json或是yarn.lock。
在npm的版本》=5.1的時候，package-lock.json檔案是自動開啟的，意味著會自動生成，
package-lock.json（官方文件）可以理解為/node_modules資料夾內容的json對映，並能夠感知npm的安裝/公升級/解除安裝的操作。可以保證在不同的環境下安裝的包版本保持一致。聽上去很不錯哈，實際使用中，大部分它的表現確實不錯，可是如上述問題：我手動修改了package.json檔案內依賴的版本，package-lock.json就沒那麼聰明（至少目前是，未來會不會變聰明就不可知了），且不會變化。
如果你真的想保證你的包版本在各個環境都是一樣的話，請修改下package.json中的依賴，去掉預設前面的^，當然這樣的話，你就沒法自動享受依賴包小版本的修復了，問題來了，在什麼情況下選擇哪一種呢？
實現如圖：
1.劃分元件
根據元件具體職能不同，可以劃分為如下結構：2.提取專案公共頁模版
由公共函式類、公共模組類、當前頁面組成，所有頁面引用公共元件，公共元件繼承公共類，開發者不需要寫過多公用的**，開發類由被基類、繼承類的公共元件，使用公共元件的的頁面三塊組成。
頁面劃分3.提取公共函式
很多函式在我們專案中都會頻繁使用，所以需要提取公共出來，方便使用4.初期能達到的情況
一鍵配置開發
通過拖拉拽直接進行開發
腳手架持續優化
各個流程的優化
元件化 方案
一 圖形 1 快取抗量，es兜底 對呀，為了面向c，抗住大流量才用的redis才對的 2 畫圖加強下，太醜了 1 這事我說了你做了，就是80分。因為起點就是60分。這事我沒說，你做了，起點就是80分。積極主動性要起來 明白麼 三 庫存review param 代表外面的入參 上面這個元件構造號，判空...
Android元件化方案
1為什麼要專案元件化 2如何元件化 3元件化實施流程 1元件模式和整合模式的轉換 2元件之間androidmanifest合併問題 3全域性context的獲取及元件資料初始化 4library依賴問題 5元件之間呼叫和通訊 6元件之間資源名衝突 4元件化專案的工程型別 2功能元件和common元件...
Flex元件開發
sunday,may 11th,2008 原文在這裡 tutorial the flash and flex marriage 這也是乙個在flashide中建立flex元件的好教程，值得好好研究！tags component posted in flex元件開發 friday,may 9th,20...