前端模組化方案總結

js設計之初，是用來進行表單驗證等工作的，所以那個年代的js**量相當少，邏輯也是比較簡單的。但是隨著cpu、瀏覽器效能的大幅度提公升，js從乙個簡單的驗證器一躍成為當前最為流行的程式語言之一。隨之而來的是前端**量的迅速膨脹，**邏輯也是變的相當複雜。如果我們還是像當初一樣，把變數和方法寫在根作用於window下面的話，那麼很容易造成命名衝突、業務邏輯混雜在一起等問題。

單圖的命名空間

為了解決這個問題，我們需要找到一種方式來有效的隔離、組織、管理複雜的js**，模組的概念便應運而生了。期初我們的解決方案是利用不同的命名空間來解決命名衝突問題：

var banner = 
}

優點：只需要保證命名空間的唯一性就可以解決命名衝突的問題了，然後把某一塊的業務功能寫在乙個命名空間內，這樣就實現了乙個完整的功能模組。

缺點：外部可以隨意修改該模組的成員變數，帶來安全性問題。

立即執行函式

var banner = （function(),
getdata: function(){}
}}）()

這樣就隱藏了模組的實現細節，只是對外暴露了關鍵的api。當前主流的模組化方案走的就是這種思路。

主流方案

很多介紹會說amd是非同步載入方案，cmd是同步載入方案，其實這是不太準確的。我的理解是amd是非同步載入、非同步執行，cmd是非同步載入、同步執行。所依賴的模組的載入都是非同步的，沒有順序之分，這個階段，兩種方案是沒有差別的。差別在於執行階段，amd是載入後立即執行的，所以模組間的執行沒有先後順序。而cmd載入後並不執行，而是等到require進來的時候再執行，所以在cmd中模組的載入與書寫的順序是有關係的。

amd：

define(['./a','./b'], function (a, b) );

cmd：

define(function (requie, exports, module) );

如果按照載入階段區分同步、非同步的話，那麼amd和cmd的載入階段是非同步的，而commonjs的載入是同步的。這樣設計的原因是，commonjs用再服務端，require進來的模組都是本地的，使用同步的方式對效能也不會有太大的影響。

commonjs：

var event = require("event");  
var add = function() ); 
}  exprots.add = add;

commonjs的發展壯大，node功不可沒，node使用的模組標準就是借鑑了commonjs。node與commonjs的不同之處請檢視commonjs模組規範與nodejs的模組系統底層原理。

esm：

import react from 'react';
class a extends react.component 
export default a;

前端模組化方案總結

前端模組化

前端模組化

前端模組化

相關推薦