在Typescript/JavaScript中名稱空間有一些客觀的負面現象

Question

我在互聯網的不同文章中看到很多，並且聽到很多名稱空間都是古老而邪惡的東西。我聽說很多你應該使用帶有模塊加載器而不是命名空間的模塊，但我不明白使用它們有什麼客觀的好處。我已經閱讀了關於命名空間的不同論點，但他們似乎對我並不那麼有說服力。我將列出一些參數，你們請嘗試用一些真實世界的例子來解釋爲什麼它們是有效的：

• 命名空間創建至少1個全局變量。但那有什麼問題？我不在乎是否有一個叫做angular的全局變量。它會造成什麼危害？

• 對於模塊，消費者決定要爲導入的變量命名。命名導入的能力真的給了我什麼？有多大可能會有2個變量命名爲angular？而在這些少數情況下會出現重複的變量名我們不能僅僅做到這一點（我沒有測試過這一點，但它應該在理論工作）：

  var someOtherName = angular; 
  
  var angular = function() { 
  }; 
  

• 模塊與模塊裝載機使捆綁更容易因爲他們把腳本按正確的順序排列。但爲什麼他們不這樣做，當你明確地告訴他們的順序，通過在每個文件的頂部添加導入？同樣，當你在tsconfig.json中使用「outFile」選項將三斜槓引用放在文件的頂部時，Typescript會按照正確的順序構建JavaScript。這與進口有什麼不同？

• 模塊裝載機提高了性能。這個讓我很困惑。假設我使用Typescript或.NET框架的捆綁工具生成了一個巨大的JavaScript文件，性能會不會相同，因爲在這兩種情況下我們都有1個文件？ SystemJS會根據需要動態加載這些腳本。這個更有意義，但如果我最終得到一個25kb的JavaScript文件，如果按需加載每個kb，我會獲得多少性能提升？畢竟，它只有25kb。

• 即使假設模塊和模塊加載器比綁定到一個文件中並引用它在html中更好，如果我使用模塊加載器來構建庫，是否意味着使用我的庫的任何人都需要安裝加載器依賴項太？

在此先感謝您。

Answer 1

現在使用命名空間在JavaScript中被認爲是一個壞主意有很多原因。 所有這些原因適用於TypeScript，因爲它只是JavaScript的超集。

你自己回答了其中的一些，但可能看不到它們的意義。 我會盡力解決他們的問題。

隱依賴順序

當您的代碼使用通過命名一些庫， 隱含地創建你的代碼，您使用的庫之間的依賴關係。

這意味着您必須自己管理依賴關係，以便正確加載它們， 或者您需要指示編譯器/打包程序，以便它們可以正確安排加載順序。

這意味着您有一個帶外位置來管理此信息，並且容易出錯。 如果明天你停止使用這個庫，該怎麼辦？你會記得排除它嗎？ 讓你的工具去完成工作要好得多。

命名空間衝突

這是一個常見的原因使用全局命名空間的人反對。 您可能認爲這種情況很少發生，但一個例子是lodash vs underscore。

命名空間版本

這是命名空間衝突的另一種形式。 如果您的代碼和其中一個庫使用相同的庫x，但版本不同（x公開在全局名稱空間x中），那麼應在全局命名空間x中使用哪個版本？

模塊解決了這個問題。 （免責聲明：目前TypeScript類型系統不能正確處理多個版本，所以你可能會看到一些問題並需要解決它）。

禁止樹搖動

隨着ESM，捆綁諸如rollup和webpack可以執行樹形晃動。 通過命名空間使用庫不會給捆綁器分析您的代碼和樹形結構 - 擺脫不需要的位的信息。

剛性

當您通過命名空間暴露你的圖書館，圖書館的內部結構暴露，這意味着你不能沒有營造出破改變你的消費重構你的代碼。

是的，你可以通過小心地創建適配器或別名來避免這種情況，但這會讓你的代碼更難以維護，並且很可能最終陷入混亂。

安全

這是值得商榷的，但讓你的代碼在全局命名空間訪問意味着你的代碼和潛在的一些國家可以通過其他代碼容易訪問和修改。

我確信還有很多其他原因，但這些是我現在可以想到的。