前端模塊化要解決的兩個問題
前言
前端模塊化，主要是解決兩個問題——“命名空間沖突”，“文件依賴管理”。
坑___命名空間沖突
- 我自己測試好的代碼和大家合并后怎么起沖突了?
- 頁面腳本的變量或函數(shù)覆蓋了公有腳本的。
坑___文件依賴管理
- 明明項目需要引入的包都引進來了怎么還報缺少包?
- 手動管理依賴，有天要更換某個插件，要深入代碼內(nèi)部進行修改
- 如下圖，顯示的代碼加載，依賴關(guān)系復(fù)雜。在F.js中，分不清某個變量是來自C.js，還是E.js
- 兩次加載同一個模塊。比如引入了兩遍JQ
其他的坑
- 為了實現(xiàn)腳本復(fù)用，將一個很大的公用public文件引入各個頁面中，其中的某些函數(shù)，只有個別頁面用到。
- 某個功能的函數(shù)群函數(shù)，與另一個功能的函數(shù)群擺在一起，使用注釋來分隔。
目前解決的方法是:模塊化
- 命名空間：各個模塊的命名空間獨立。A模塊的變量x不會覆蓋B模塊的變量x。
- 模塊的依賴關(guān)系:通過模塊管理工具如webpack/requireJS/browserify等進行管理。
模塊化的基本原理——解決命名空間沖突
JavaScript的缺陷，首當(dāng)其沖就是全局變量。這使得每想命名一個變量的時候都要三思又三思，生怕上方無窮遠的地方有一個同事些的代碼和自己沖突。以下是一些防范方法
一、使用命名空間
代碼如下：
- //定義
- var module = {
- name: 'rouwan',
- sayName:function(){
- console.log(this.name)
- }
- }
- //使用
- var a = module.name;
- console.log(a)
總結(jié)：直接修改name不會影響module.name，一定程度保護了命名空間。有兩個缺點，一，外部還是可以修改module的屬性和方法。二，命名空間有時長起來超乎你的想象。適合一些小型的封裝，如一些配置。
二、立即執(zhí)行函數(shù) + 閉包(實現(xiàn)模塊的基本方法)
立即函數(shù)可以創(chuàng)建作用域，閉包則可以形成私有變量和函數(shù)
- //創(chuàng)建
- var module = (function(){
- var privateName = 'inner'; //私有變量
- var privateFunc = function(){ //私有函數(shù)
- console.log('私有函數(shù)')
- }
- return {
- name: 'rouwan', //公有屬性
- sayName:function(){ //公有函數(shù)
- console.log(this.name)
- }
- }
- })()
- //使用
- module.sayName(); //'rouwan'
總結(jié)：這是目前比較常用的模塊定義方式，可以區(qū)分私有成員和公有成員。公有變量和方法，和之前一樣可以直接通過module.name的方式修改。私有變量和方法，是無法訪問的，除非給你個修改私有成員的公有方法。
三、在上述基礎(chǔ)上，引入其他模塊
- //定義
- var module1 = (function(mod){
- var privateName = 'inner1';
- var privateFunc = function(){
- console.log('私有函數(shù)1')
- }
- return {
- name : 'rouwan1',
- sayName: function(){
- console.log(this.name)
- },
- anotherName:mod.name, //另一個模塊上的公有參數(shù)
- sayAnotherName:mod.sayName //另一個模塊上的公有方法
- }
- })(anotherModule) //引入了另一個模塊
- //使用
- module1.sayOtherName()
總結(jié)：在一個模塊中可以引入另一個模塊。
四、其他的方式
放大模式等是以往用來管理大型模塊，進行文件拆分的方法?，F(xiàn)在webpack等模塊化工具都很完善的情況下，已經(jīng)顯得有點落后了。就不介紹了。
告別刀耕火種的時代——模塊化構(gòu)建工具(解決依賴管理)
我了解js模塊是從立即執(zhí)行函數(shù)開始的。但是等到真正使用構(gòu)建工具的時候，卻發(fā)現(xiàn)業(yè)界采用的模塊化方案，卻并非是一個一個由立即函數(shù)+閉包形成的集群。
而是用了諸如AMD/CMD/CommonJS/ES6模塊等等模塊化實現(xiàn)。
這里面的原因可能有這幾個，一，閉包的性能問題。二，當(dāng)模塊增多的時候，需要解決模塊間的依賴管理問題。
關(guān)于依賴管理，目前項目里碰到了幾個不舒服的地方：
- HTML中引入了兩遍的jq，導(dǎo)致腳本報錯。
- 有一個公用腳本，包含了N多的公用模塊。有些頁面明明只用到了一個模塊，也必須全部加載一遍。
因此，必須使用模塊化管理工具!
幾個概念
包管理工具: 安裝、卸載、更新、查看、搜索、發(fā)布包。比如你需要安裝個jq等，通過npm來安裝。npm里有依賴管理，假如jq或者說express升級了，原來代碼不能用了。幫助你解決這個問題的就是npm。
模塊化構(gòu)建工具：webpack/requireJS/seaJS，等是用來組織前端模塊的構(gòu)建工具(加載器)。通過使用模塊化規(guī)范(AMD/CMD/CommonJS/es6)的語法來實現(xiàn)按需加載。舉個栗子，如果有一天你不用維護一個很長很長的公用腳本文件，這得感謝它。
模塊化規(guī)范：：AMD/CMD/CommonJS/es6模塊等等規(guī)范，規(guī)范了如何來組織你的代碼。一般這種方式寫的代碼瀏覽器不認(rèn)，需要用模塊化構(gòu)建工具來打包編譯成瀏覽器可以識別的文件。
從我的表格里，可以看出我的推薦搭配———— npm +webpack + es6模塊。
理由如下：
npm與bower比較：
- 原來bower的使用優(yōu)勢就是適合前端模塊管理，而npm被視為只適合后端的管理。但是隨著webpack的流行，這個已經(jīng)毫無疑問是npm勝出了。npm+webpack，可以實現(xiàn)良好的前端模塊管理。
webpack和requireJS比較：
幾種模塊化規(guī)范比較：
所以就決定是你了! npm + webpack + es6模塊。
