小编Use*_*555的帖子

Typescript/JavaScript 中的命名空间有哪些客观的负面影响

我在互联网上的不同文章中看过很多,也听说过很多名称空间是古老而邪恶的东西。我听说过很多人应该使用带有模块加载器而不是命名空间的模块,但我只是不明白使用它们的客观好处是什么。我读过关于命名空间的不同论点,但它们对我来说似乎并不那么令人信服。我将列出一些论点,你们请尝试用一些真实世界的例子来解释我为什么这些论点是有效的:

  • 命名空间至少创建 1 个全局变量。但这有什么问题呢?我不在乎是否有一个名为 angular 的全局变量。它会造成什么危害?
  • 使用模块,消费者决定导入变量的名称。命名导入的能力真正给了我什么?有 2 个名为 angular 的变量的可能性有多大?在那些罕见的变量名重复的情况下,我们不能这样做(我没有测试过这个,但理论上应该可以):

    var someOtherName = angular;
    
    var angular = function() {
    };
    
    Run Code Online (Sandbox Code Playgroud)
  • 带有模块加载器的模块使打包更容易,因为它们将脚本按正确的顺序排列。但是,当您通过在每个文件的顶部添加导入来明确告诉他们顺序时,他们为什么不这样做呢?类似地,当您使用 tsconfig.json 中的“outFile”选项将三重斜杠引用放在文件顶部时,Typescript 会以正确的顺序构建您的 JavaScript。这和进口有什么区别?

  • 模块加载器提高了性能。这个真的让我很困惑。假设我使用 Typescript 或 .NET 框架的捆绑工具生成一个巨大的 JavaScript 文件,性能会不会相同,因为在任何一种情况下我们都会有 1 个文件?SystemJS 根据需要动态加载这些脚本。这个更有意义,但如果我最终有一个 25kb 的 JavaScript 文件,如果它按需加载每个 kb,我真的会有多少性能提升?毕竟,它只有 25kb。

  • 即使假设模块和模块加载器比捆绑成一个文件并在 html 中引用它更好,如果我使用模块加载器来构建库,这是否意味着使用我的库的任何人也需要安装加载器依赖项?

先感谢您。

javascript namespaces module bundling-and-minification typescript

0
推荐指数
1
解决办法
729
查看次数