前一段時間咱們前端的項目組有一個分興趣小組的計劃.由於那時候整個小組只有9我的,因此就分了三個小組,分別是 `性能優化`, `模塊化`, `新技術` 三個小組.
而我那進了"模塊化研究"小組.因此嘞.研究模塊化以及如何讓項目的模塊化更加合理和高效是咱們小組的主要目的.
首先,在實行模塊化以前,得先鞏固模塊化開發的理論基礎,由於理論是實踐的基礎。
只有這樣,在過程當中理論與實踐相結合,纔有可能達到最滿意的效果.javascript
- 模塊化就是爲了減小系統耦合度,提升高內聚,減小資源循環依賴,加強系統框架設計。
- 讓開發者便於維護,同時也讓邏輯相同的部分可複用
- 模塊化開發:針對js、css,以功能或業務爲單元組織代碼。js方面解決獨立做用域、依賴管理、
api暴露、按需加載與執行、安全合併等問題,css方面解決依賴管理、組件內部樣式管理等問題。
任何事物都有一個過程,那麼模塊化的過程通俗點講就是:php
- 一、拆分
將整個系統按功能
,格式
,加載順序
,繼承關係
分割爲一個一個單獨的部分.
注意:拆分的粒度問題,可複用問題,效率問題.如何這些問題處理的很差,就有可能出現不想要的後果。- 二、概括
將功能或特徵類似的部分組合在一塊兒,組成一個資源塊.- 三、總結
將每一個資源塊按找需求,功能場景以及目錄約束放到固定的地方以供調用.
模塊化的發展也是從草根一步一步走過來的。從最開始到如今成熟方案:css
在亙古年代,機智的人們爲了處理javascript的命名衝突,功能塊管理等等,在js中使用了namespace
。咱們能夠說這是最原始的模塊化管理模式。
以下:html
// 使用namespace以前 var name={}; var name2={}; // 使用namespace以後 var nameSpace={}; nameSpace.branchOne={ name:{} }; nameSpace.branchTwo={ name:{} };
添加命名空間,達到拆分js邏輯的目的。
到了現代,處理css
的模塊化的有sass
,less
等工具。根據其提供的語法,即可以有效將css拆分爲不一樣的塊。
還有隨着AMD
和CMD
的出現,javascrip中namespace機制便已經被淘汰殆盡。不過目前咱們的項目組中那部分尚未遷移過來的老代碼還在默默的使用着這種「古老」的方式。根據模塊加載的工具類庫,實現js邏輯的模塊化加載的方式愈來愈稱爲主流。其中的好處你們能夠查一查,不在這裏就不贅述咯。
可是,最重要的一點必需要提比namespace更加利於維護和複用
。
在html中也存在着各類前端和後端的模版。就像php中的smarty(咱們如今就在用)。前端中的juicer,underscore等等。它們一樣的也能夠將html按功能特色拆分抽離爲單獨的html塊。
不過,上面的只是將js
,css
,html
單獨的進行進行模塊化處理,並無一個統一的完整的實現功能模塊劃分,而spm
,webpack
這些工具偏偏作了這些事。它們能夠將js,html,css以及其餘靜態資源按照開發者的意願拆分爲單獨的模塊,抽離的也更加完整。
上面的工具雖然能夠幫助開發者們完成模塊化,可是它們也僅僅只是一個單獨的模塊化工具,並無造成一個十分紅熟的前端模塊化方案。而fis
,yui
,kissy
這些框架提供了囊括上述所有的功能。能夠幫助開發者實現從頭至尾的模塊化。前端
此外,須要注意的是,前端的模塊化並不該該只專一於某一項(js,css,html)的模塊化,而應該是對項目總體進行解耦,抽離,組裝。從而達到項目總體模塊化的目的。java
由於模塊是按功能進行分類的,因此能夠先將模塊分爲兩類:webpack
- 公共模塊(用於促進代碼複用)
- 業務模塊(用於提高可維護性)
目前,咱們產品的V3版本的模塊是經過:web
這3個規則來區分和調用的。json
什麼是主流的模塊化哪?我接下來就用咱們項目組用依賴fis的fisp來粗略的說一下fis的模塊化。gulp
將偶合度比較高的頁面片斷進行單獨拆分,模塊佈局做爲公開的接口,進行html片斷的繼承 複用與拼裝.
每一個單獨的html片斷使用單獨而且對應的css片斷,html中的圖片能夠按照相關性放到模塊文件下的一個單獨的圖片文件夾裏.
舉個例子:
當咱們在打開外鏈頁的時候,右側圈住的那部分就是一個模塊。那麼在html中,它的結構是什麼哪?
咱們有一個base.tpl
是一個最外頭的模版,結構以下:
還有一個html的主要框架lqyout.tpl
,
一個功能模塊share.tpl
最後哪,就到了咱們廣告的模塊 personal.tpl
,
細心的同窗可能會發現,這些結構是一層一層的嵌套的。有大到小的分割。由最外頭(base.tpl)->主結構(layout.tpl)->功能結構(share.tpl)->具體廣告模塊(personal.tpl)
這樣哪,就會有效的組織頁面。
html模塊化能夠實現多人協同開發頁面.各司其職.有效提升頁面的開發效率,和維護成本. 能夠有效減小文件衝突,文件錯誤.
其中,頁面模塊代碼做用域的控制經過css文件來控制。某類具備高度耦合的頁面使用自身的css文件。
根據視覺佈局,定義通用的css 以及單個html片斷css
鑑於目前主流的模塊加載器,fis也提供了一個模塊加載器叫mod.js
。用法和requirejs
,seajs
差很少。咱們會按照功能將js分割並放到對應的位置。針對於模塊化加載fis有一點作的比較好
爲了協調異步環境下模塊開發與性能間的矛盾,咱們必須在工程階段就具有依賴分析的能力,把具有依賴關係的資源進行打包。就算不打包,也但願像 F.I.S 那樣有個記錄依賴關係的map.json,能夠照單抓藥,一次性地把須要的依賴項加載下來。
所以,在開發期解析模塊依賴、合併代碼、甚至重寫資源路徑都得在工程化的層面完成。工程化和模塊化變成了容易耦合且不得不耦合的兩個話題。
- 首先,瞭解你的項目,經過畫網站樹狀圖瞭解你網站的整體結構和頁面模塊。
- 其次,理清結構邏輯和視覺邏輯,結構邏輯就是看你的頁面由那些模塊組成,視覺邏輯瞭解可繼承模塊,佈局邏輯(網格佈局或者非網格佈局)
按照類似性 能夠將css html js 以及其餘的靜態資源放到一個一個文件夾中.固然,由於標準的確實,至於模塊化的文件如何組織就見仁見智了.
咱們的目錄是這樣的:
一個單獨的模塊放到一個單獨的文件夾裏,這個模塊的css,html,js以及其餘靜態資源也都放到一塊兒,便於管理。
結構差很少能夠像這樣:
組件化開發 :在模塊化基礎上,以頁面小部件(component)爲單位將頁面小部件的js、css、html代碼片斷放在一塊兒進行開發、維護,組件單元是資源獨立的,
組件在系統內可複用。好比頭部(header)、尾部(footer)、搜索框(searchbar)、導航(menu)、對話框(dialog)等,甚至一些複雜的組件好比下載(download)等。
一般業務會針對組件化的js部分進行必要的封裝,解決一些常見的組件渲染、交互問題。實現高內聚,低耦合.
就拿咱們的會員中心來講,總體是一個大的組件。目錄結構以下:
上述的模塊化特色,目前咱們百度網盤使用的FIS已經將這些概念所有實現.並且作的還至關不錯.
好了,正經的模塊化介紹就到此結束。接下來,我爲你們闡述一種另類的模塊化
.
就拿上面的百度網盤外鏈的單文件分享來講:
每次有用戶請求,上述的每一個html塊都要通過php的smarty引擎在服務器端組合成一個完整的html在返回給瀏覽器端,不只如此,js、css以及其餘靜態資源都是.server端一天要作幾十萬次這種重複的操做。它好累!!!
不過,針對於前端開發者來講,fisp作的已經足夠了。它確實已經實現了完整的模塊化。可是僅僅只是針對開發者而已
。
有沒有想過,對於瀏覽器來講,這麼一個一樣的功能,每次都是從新加載一個內容和結構都差很少的html,若是能在這塊作點什麼東西,就像把模塊化的思想用到瀏覽器上。那麼,這個缺口是否是大有可爲
。
因此,實現針對於瀏覽器的模塊化能夠說是有必要的.從針對於開發者的模塊化轉換到針對瀏覽器的模塊化.這是一個嘗試的革命路線.
至於如何作。請聽下回分解。。。