使用RequireJS的Javascript命名空間，爲什麼？

我目前正面臨着這個關於JavaScript上的命名空間的爭論，我需要一個社區意見。使用RequireJS的Javascript命名空間，爲什麼？

場景： 負責這個項目在某種程度上是專門RequireJS的建築師和真正想使用它。

我必須說，應用程序是一個後臺，奠定了作爲一個嚮導，讓你有種來回走6頁有一些複雜的業務邏輯，在填充的結束，在這裏我可以描述爲一個過程的東西請求。

好的，沒有單一頁面的應用程序沒有什麼奇怪的事情。平原後臺web應用程序，多頁面，具有非常複雜的用戶界面，每個頁面都被請求到服務器，所有資源（CSS，JavaScript等）必須在頁面加載時加載。

主要問題：瞭解我們正在討論的應用程序的種類，爲什麼要求RequireJS？

第二個問題：爲什麼試圖說服在javacript命名空間，最好的方法是使用RequireJS？我錯過了什麼嗎？

我的意見： 對我來說，這是毫無意義的。在這裏使用RequireJS很麻煩，因爲沒有按需加載資源，它們都是在頁面加載時加載的（僅僅因爲我們在頁面加載時都需要它們）。我們需要至少支持IE8，Chrome，Firefox和Opera，並且我們在所有這些瀏覽器中加載資源都遇到了很多麻煩。已經有很多技巧來確保通過Require來按預期加載所有內容。

對於命名空間它更糟糕。當然，它有效，但又一次，對我來說似乎很麻煩，而且這件事實際上非常有限。

所以我失去了什麼？我需要第三次（或第100次）意見。

您對此有何看法？
你使用什麼？
爲什麼？

在此先感謝

來源

2012-12-17 AlexCode

你在C＃中使用語句嗎？這是同樣的事情。 – BentOnCoding

C＃「使用」語句與AMD的JavaScript工具不一樣......完全一樣。 – AlexCode

「使用」將名稱空間中包含的類型導入到直接封裝的編譯單元或名稱空間主體中。「require」將指定模塊導入當前腳本/模塊。聽起來和我很相似，但這只是我的看法 – BentOnCoding

AMD裝載機（RequireJS就是其中之一）解決不同的問題：

適當的模塊化，關注點分離
沒有全球污染
沒有名稱衝突
按需加載或部署前優化
根據裝載機，插件adressing先進的問題，如本地化資源或加載時編譯

我這樣裝載機的大風扇，並找到他們的一切有用的，但非常小的單頁的應用程序。

來源

2012-12-17 20:42:47 Lucero

從這個列表中我只能將最後兩個鏈接到AMD加載器。 – AlexCode

因爲我一直在爲每個頁面分開文件，所以關注點分隔得很好，但沒有名稱空間。由於應用程序聲稱在客戶端網站較重，我開始在域函數中封裝我的代碼，以避免影響全球環境並防止名稱衝突。根據我的經驗，我知道RequireJS不會「只是工作」。所有瀏覽器（特別是舊版本）的兼容性和穩定性並不是直截了當的，所以爲什麼要用火箭筒殺死蒼蠅？ – AlexCode

@AlexCode全局變量的缺失完全是AMD概念的一部分：http://requirejs.org/docs/whyamd.html – Christophe

我個人認爲使用JavaScript模塊系統是幾乎從來沒有一個壞主意。 Requirejs也不是JavaScript模塊的唯一可能的加載器（但也許是最流行的）。一些替代品是LABjs或HeadJS。

這些裝載機往往容易使用（在開始時沒有太大的麻煩），但也有很大的幫助，當項目越來越大。它們避免了全局空間中的命名衝突，還可以通過最小化/優化模塊來支持您在部署步驟中。最重要的事實是，它們允許您編寫更多模塊化JavaScript代碼。

你有一些實用功能？只需創建一個實用程序模塊
你有你需要的所有網頁上的一些功能？把它們放在一個通用模塊中。
有些需要大量的具體的javascript代碼？爲這些頁面創建一個額外的模塊，以便您不必在其他頁面上加載此代碼。

來源

2012-12-17 20:44:10 micha

我在回答中評論了您的觀點。基本上我完全同意你的看法，我只是不喜歡開銷和失去控制來實現一些實際上可以非常簡單和透明的事情。 – AlexCode

沒有，如果它是一個「單頁的應用程序」與否，RequireJS有兩個東西，是不容易的，而不對自己的很多開發商紀律開發客戶端的JavaScript時有助於事情：

生產與開發環境

，這是常識現在你的JavaScript應用程序分成邏輯上類似於應用程序的不同部分的文件。調試和維護更容易。但是在生產環境中，傳送許多未壓縮的文件對性能不利。所以，您連接所有的文件到一個文件中，再壓縮它（例如，使用谷歌關閉編譯器），然後運往它作爲一個單一的gzip壓縮文件。有許多不同的方法來做到這一點使用命令行工具（例如，使用GruntJS），但沒有一個腳本管理器，例如RequireJS你無論如何都必須設置你的頁面了兩種不同的使用情況（參考所有dev的文件作爲腳本標記或單一生產.js）自己。 RequireJS有一個NodeJS構建工具，可爲您完成所有這些工作。

模塊化

現在，讓你的代碼在不同的文件都好。但由於JavaScript的本質，一切是全球性的手段，您仍然可以遇到這樣的名字衝突奇怪的事情。這是命名空間派上用場的地方。但更好的選擇是將所有東西都包裝到自己的功能中（這引入了它自己的範圍）。這就是爲什麼大多數JavaScript代碼都有自我執行的匿名函數。如果此函數現在返回一個API，它想要公開您有Web模塊。您可以從應用程序中單獨測試模塊API，並在其他地方重新使用它。

從RequireJS文檔的Why Web Modules部分又看了起來。

來源

2012-12-17 20:44:34 Daff

由於回覆我發佈了一個解答我自己的問題的答案，解釋了我強制執行命名空間的原因以及原因。實際上，您在環境相關配置方面具有非常強大的優勢。謝謝！ – AlexCode

我目前的解決方案，以防止poluting全球環境和名稱衝突是使用$.extend。

文件系統樹看起來像下面這樣：

RootFolder 
    +-> js 
    global.js 
    ... 
    +-> views 
     index.js 
     page1.js 
     page2.js 
     ... 
index.html 
page1.html 
page2.html

所以它通常是每頁另一個特定的所有應用程序共享一個代碼global.js文件。

對於命名空間，我喜歡$。延伸等各個JS文件我有類似：

var app = app || {}; 

/* only one document ready block per view if needed */ 
$(document).ready(function(){ 
    /* initialization code */ 
}); 

/* extend the app namespace with the Page1 code */ 
$.extend(app, { 
    page1: { 
     SayHi: function SayHi(name){ 
      alert('Hi ' + name); 
     } 
    } 
});

所以，你可以通過調用訪問代碼：

app.page1.SayHi("Alex");

利用這種技術你：

擁有完全控制你的碼。沒有神奇的資源加載和花哨的東西，你沒有完全控制。
沒有全球性的環境污染
沒有命名衝突
命名空間樹可以如你所願那樣深，你是你自己的複雜的所有者。
您可以擁有幾個實際上對相同名稱空間級別有貢獻的js文件。這對輔助工具特別有用。
根據您在頁面上包含的JavaScript文件，您可以擁有更大或更小的應用程序名稱空間。

結論：

的網絡環境很容易，我們不應該它複雜化。

我不打對RequireJS，不要誤解我的意思。它做它的意思（其本質是純粹的資源延遲加載）。其他一切都是隨包裝一起提供的，但也可以以更清潔和透明的方式實現。

因此，如果我不需要主要功能，那麼使用它就沒有意義。

乾杯！

來源

2012-12-18 09:07:12 AlexCode

在模塊中定義您的JavaScript是建議的最佳做法。我不相信任何1框架可以解決所有問題，但是反應是一個很好的解決方案，它向不支持模塊加載的瀏覽器提供向後兼容性。爲了避免使用一些你沒有花時間去理解的東西，你走了一條路，最終導致了一個不太理想的模式。如果你堅持不使用require，你至少可以學習立即調用的函數表達式，以及它們如何幫助你在JavaScript中安全地定義命名空間。 – BentOnCoding

你正在評論一個近3歲的職位。無論如何，我承認這不是一個好方法，但它更多的是在沮喪下發布:) 我從來沒有實現過任何這個，實際上，幾個月後，我們將所有東西都移動到了AngularJS，而不再需要RequireJS。無論如何，所有的決定並不是由於不瞭解工具，而恰恰相反。 – AlexCode

使用RequireJS的Javascript命名空間，爲什麼？

回答

相關問題