前端模塊化——技術選型

時間 2019-11-10

標籤前端模塊化技術選型简体版

原文原文鏈接

前言

前端模塊化，主要是解決兩個問題——「命名空間衝突」，「文件依賴管理」。前端

坑___命名空間衝突webpack

我本身測試好的代碼和你們合併後怎麼起衝突了？es6
頁面腳本的變量或函數覆蓋了公有腳本的。web

坑___文件依賴管理express

明明項目須要引入的包都引進來了怎麼還報缺乏包？npm
手動管理依賴，有天要更換某個插件，要深刻代碼內部進行修改segmentfault
以下圖，顯示的代碼加載，依賴關係複雜。在F.js中，分不清某個變量是來自C.js，仍是E.js後端
兩次加載同一個模塊。好比引入了兩遍JQ瀏覽器

其餘的坑閉包

爲了實現腳本複用，將一個很大的公用public文件引入各個頁面中，其中的某些函數，只有個別頁面用到。
某個功能的函數羣函數，與另外一個功能的函數羣擺在一塊兒，使用註釋來分隔。

目前解決的方法是:模塊化

命名空間：各個模塊的命名空間獨立。A模塊的變量x不會覆蓋B模塊的變量x。
模塊的依賴關係:經過模塊管理工具如webpack/requireJS/browserify等進行管理。

模塊化的基本原理——解決命名空間衝突

JavaScript的缺陷，首當其衝就是全局變量。這使得每想命名一個變量的時候都要三思又三思，生怕上方無窮遠的地方有一個同事些的代碼和本身衝突。如下是一些防範方法

1、使用命名空間
代碼以下：

//定義
var module = {
    name: 'rouwan',
    sayName:function(){
        console.log(this.name)
    }
}
//使用
var a = module.name;
console.log(a)

總結：直接修改name不會影響module.name，必定程度保護了命名空間。有兩個缺點，一，外部仍是能夠修改module的屬性和方法。二，命名空間有時長起來超乎你的想象。適合一些小型的封裝，如一些配置。

2、當即執行函數 + 閉包（實現模塊的基本方法）
當即函數能夠建立做用域，閉包則能夠造成私有變量和函數

//建立
var module = (function(){
                var privateName = 'inner';            //私有變量
                var privateFunc = function(){        //私有函數
                    console.log('私有函數')
                }

                return {                            
                    name: 'rouwan',                    //公有屬性
                    sayName:function(){                //公有函數
                        console.log(this.name)
                    }
                }
            })()
//使用
module.sayName();    //'rouwan'

總結：這是目前比較經常使用的模塊定義方式，能夠區分私有成員和公有成員。公有變量和方法，和以前同樣能夠直接經過module.name的方式修改。私有變量和方法，是沒法訪問的，除非給你個修改私有成員的公有方法。

3、在上述基礎上，引入其餘模塊

//定義
var module1 = (function(mod){
                var privateName = 'inner1';
                var privateFunc = function(){
                    console.log('私有函數1')
                }

                return {
                    name : 'rouwan1',
                    sayName: function(){
                        console.log(this.name)
                    },
                    anotherName:mod.name,            //另外一個模塊上的公有參數
                    sayAnotherName:mod.sayName       //另外一個模塊上的公有方法
                }

            })(anotherModule)                        //引入了另外一個模塊
//使用
module1.sayOtherName()

總結：在一個模塊中能夠引入另外一個模塊。

4、其餘的方式
放大模式等是以往用來管理大型模塊，進行文件拆分的方法。如今webpack等模塊化工具都很完善的狀況下，已經顯得有點落後了。就不介紹了。

告別刀耕火種的時代——模塊化構建工具（解決依賴管理）

我瞭解js模塊是從當即執行函數開始的。可是等到真正使用構建工具的時候，卻發現業界採用的模塊化方案，卻並不是是一個一個由當即函數+閉包造成的集羣。
而是用了諸如AMD/CMD/CommonJS/ES6模塊等等模塊化實現。
這裏面的緣由可能有這幾個，一，閉包的性能問題。二，當模塊增多的時候，須要解決模塊間的依賴管理問題。
關於依賴管理，目前項目裏碰到了幾個不舒服的地方：

僅此一圖，無須多言
HTML中引入了兩遍的jq，致使腳本報錯。
有一個公用腳本，包含了N多的公用模塊。有些頁面明明只用到了一個模塊，也必須所有加載一遍。

所以，必須使用模塊化管理工具!

幾個概念

包管理工具: 安裝、卸載、更新、查看、搜索、發佈包。好比你須要安裝個jq等，經過npm來安裝。npm裏有依賴管理，假如jq或者說express升級了，原來代碼不能用了。幫助你解決這個問題的就是npm。
模塊化構建工具：webpack/requireJS/seaJS，等是用來組織前端模塊的構建工具（加載器）。經過使用模塊化規範（AMD/CMD/CommonJS/es6）的語法來實現按需加載。舉個栗子，若是有一天你不用維護一個很長很長的公用腳本文件，這得感謝它。
模塊化規範：：AMD/CMD/CommonJS/es6模塊等等規範，規範瞭如何來組織你的代碼。通常這種方式寫的代碼瀏覽器不認，須要用模塊化構建工具來打包編譯成瀏覽器能夠識別的文件。

從個人表格裏，能夠看出個人推薦搭配———— npm +webpack + es6模塊。
理由以下：
npm與bower比較：