前端模塊commonjs,前端模塊化開發

本文目錄一覽：

1、react怎麼使用commonjs
2、如何理解前端模塊化
3、CommonJS與ES6模塊化的具體使用方式
4、react+webpack 模塊化應該採用CommonJS規範還是ES6規範，為什麼
5、commonjs為什麼不適合前端

react怎麼使用commonjs

Common JS 即 node.js 的模塊組織形式，前端可以用 webpack 或者 browserify 來打包

如何理解前端模塊化

前端模塊化

在JavaScript發展初期就是為了實現簡單的頁面交互邏輯，寥寥數語即可；如今CPU、瀏覽器性能得到了極大的提升，很多頁面邏輯遷移到了客戶端（表單驗證等），隨着web2.0時代的到來，Ajax技術得到廣泛應用，jQuery等前端庫層出不窮，前端代碼日益膨脹

這時候JavaScript作為嵌入式的腳本語言的定位動搖了，JavaScript卻沒有為組織代碼提供任何明顯幫助，甚至沒有類的概念，更不用說模塊（module）了，JavaScript極其簡單的代碼組織規範不足以駕馭如此龐大規模的代碼

模塊

既然JavaScript不能handle如此大規模的代碼，我們可以借鑒一下其它語言是怎麼處理大規模程序設計的，在Java中有一個重要帶概念——package，邏輯上相關的代碼組織到同一個包內，包內是一個相對獨立的王國，不用擔心命名衝突什麼的，那麼外部如果使用呢？直接import對應的package即可

import java.util.ArrayList;

遺憾的是JavaScript在設計時定位原因，沒有提供類似的功能，開發者需要模擬出類似的功能，來隔離、組織複雜的JavaScript代碼，我們稱為模塊化。

一個模塊就是實現特定功能的文件，有了模塊，我們就可以更方便地使用別人的代碼，想要什麼功能，就加載什麼模塊。模塊開發需要遵循一定的規範，各行其是就都亂套了

規範形成的過程是痛苦的，前端的先驅在刀耕火種、茹毛飲血的階段開始，發展到現在初具規模，簡單了解一下這段不凡的歷程

函數封裝

我們在講函數的時候提到，函數一個功能就是實現特定邏輯的一組語句打包，而且JavaScript的作用域就是基於函數的，所以把函數作為模塊化的第一步是很自然的事情，在一個文件裡面編寫幾個相關函數就是最開始的模塊了

function fn1(){

statement

}

function fn2(){

statement

}

這樣在需要的以後夾在函數所在文件，調用函數就可以了

這種做法的缺點很明顯：污染了全局變量，無法保證不與其他模塊發生變量名衝突，而且模塊成員之間沒什麼關係。

對象

為了解決上面問題，對象的寫法應運而生，可以把所有的模塊成員封裝在一個對象中

var myModule = {

var1: 1,

var2: 2,

fn1: function(){

fn2: function(){

}

這樣我們在希望調用模塊的時候引用對應文件，然後

myModule.fn2();

這樣避免了變量污染，只要保證模塊名唯一即可，同時同一模塊內的成員也有了關係

看似不錯的解決方案，但是也有缺陷，外部可以隨意修改內部成員

myModel.var1 = 100;

這樣就會產生意外的安全問題

立即執行函數

可以通過立即執行函數，來達到隱藏細節的目的

var myModule = (function(){

var var1 = 1;

var var2 = 2;

function fn1(){

}

function fn2(){

}

return {

fn1: fn1,

fn2: fn2

};

})();

這樣在模塊外部無法修改我們沒有暴露出來的變量、函數

上述做法就是我們模塊化的基礎，目前，通行的JavaScript模塊規範主要有兩種：CommonJS和AMD

CommonJS

我們先從CommonJS談起，因為在網頁端沒有模塊化編程只是頁面JavaScript邏輯複雜，但也可以工作下去，在服務器端卻一定要有模塊，所以雖然JavaScript在web端發展這麼多年，第一個流行的模塊化規範卻由服務器端的JavaScript應用帶來，CommonJS規範是由NodeJS發揚光大，這標誌着JavaScript模塊化編程正式登上舞台。

定義模塊

根據CommonJS規範，一個單獨的文件就是一個模塊。每一個模塊都是一個單獨的作用域，也就是說，在該模塊內部定義的變量，無法被其他模塊讀取，除非定義為global對象的屬性

模塊輸出：

模塊只有一個出口，module.exports對象，我們需要把模塊希望輸出的內容放入該對象

加載模塊：

加載模塊使用require方法，該方法讀取一個文件並執行，返迴文件內部的module.exports對象

CommonJS與ES6模塊化的具體使用方式

所以：只需要將需要暴露給外部的變量或者方法設置為exports的屬性就行，

可以把exports看做一個全局對象，把所有暴露出來的函數和變量都存放在裡面

1.先寫個6.js文件

CommonJS規範規定，每個模塊內部，module變量代表當前模板，這個變量是一個對象，他的 exports 屬性（相當於 module.exports ）是對外的接口。這裡詳情請看我的另一篇文章： module、exports 和 require的關係

加載某個模塊，其實是加載該模塊的module.exports屬性。require方法用於加載模塊

ES6模塊化的使用方法：（注！因為CommonJS類庫眾多，以及 CommonJS 和 ES6 之間的差異，所以無法直接兼容es6。）

直接/按需導出：可使用多個用變量/常量的方式

導入：需要用按需導入 {解構} 的方式獲取

默認導出：只能使用一個（default屬性只有es6才有）可以用引入對象定義多個屬性，但這樣在引入後調用的時候，更麻煩。

導入：優點：可以直接使用文件做接收參數且不用結構。

重命名export和import

如果導入的多個文件中，變量名字相同，即會產生命名衝突的問題，為了解決該問題，ES6為提供了重命名的方法，當你在導入名稱時可以這樣做：

如果想看CommonJS與ES6模塊化的原理可以去看我另一篇文章

[秦圓圓]大佬寫的 require和import的區別

[大孩子氣]大佬寫的 require/exports、import/export 的區別

[七分sunshine!]大佬寫的# 前端模塊化工具 requireJs的使用;

react+webpack 模塊化應該採用CommonJS規範還是ES6規範，為什麼

研究react的時候也考慮過這個問題，首先可以先了解下這兩種模塊的機制。參考這裡

要考慮的點：

目前Commonjs是nodejs(瀏覽器環境需要模塊加載器)原生支持的，而es6需要藉助babeljs來實現。意味着如果要實現自動編譯上線(我司沒有在線上安裝node_modules做法)可能需要將babel之類的node_modules提交代碼倉庫，大概45M。

還有要考慮下你選擇的react的組件庫是基於es6還是Commonjs。如果你業務使用Commonjs規範，組件使用es6，這個就沒法統一了。

考慮下團隊對es6的熟悉程度，關係到代碼質量和維護成本。

暫時就想到這些。

commonjs為什麼不適合前端

JavaScript是一個強大面向對象語言，它有很多快速高效的解釋器。官方JavaScript標準定義的API是為了構建基於瀏覽器的應用程序。然而，並沒有定於一個用於更廣泛的應用程序的標準庫。

CommonJS API定義很多普通應用程序（主要指非瀏覽器的應用）使用的API，從而填補了這個空白。它的終極目標是提供一個類似Python，Ruby和Java標準庫。這樣的話，開發者可以使用CommonJS API編寫應用程序，然後這些應用可以運行在不同的JavaScript解釋器和不同的主機環境中。在兼容CommonJS的系統中。

原創文章，作者：小藍，如若轉載，請註明出處：https://www.506064.com/zh-hant/n/256924.html