为什么不在命名空间变量中将类添加到窗口或全局？答案

【问题标题】：Why not add classes to window or global in a namespaced variable?为什么不在命名空间变量中将类添加到窗口或全局？
【发布时间】：2018-04-25 21:14:42
【问题描述】：

我正在使用 webpack 来转换/捆绑/等我的 js 文件。我使用导入/导出语法（与 CommonJS 的 require 和 export.module 方式相反）。这意味着如果我需要在特定脚本的上下文中使用它们，我需要多次导入每个类及其所有子类。

问题：

即使 js 本身不支持类，为什么我们需要一直导入它们？如果（而且我只为班级发言）它们适用于所有范围，那会不会更容易？

编辑：为避免污染全局范围，可以执行 global.myLibs 之类的操作并解决该问题。我个人在我的类前面加上了一些独特的东西，但这种方法甚至可以为那些我认为没有的方法提供服务。

例如：

window.myClasses 可以作为我所有课程的容器。我来自iOS背景，其中一个主要“捆绑”中的所有类，在java中我认为这将是一个“包”可供所有人使用。重新导入类本身似乎没有任何作用。

【问题讨论】：

【解决方案1】：

在全局范围内添加内容可能会导致命名冲突。如果您创建了一个名为 Node 的类，通过执行 window.Node = Node 将其添加到全局范围会怎样？您丢失了对浏览器的全局 Node 对象的引用。

您可以争辩说您永远不会使用已用于全局对象的名称。但是现在，如果在一年左右的时间里，规范中添加了一个与您的同名的新对象，并且您想将它与您自己的对象一起使用怎么办？您必须做出选择，或重命名您自己的对象。这不是未来的证据。

在使用它的每个模块中导入相同的模块是最佳做法。因为这样做，您永远不会污染全局范围。不要害怕它会在你的最终包中导入这个模块的代码 n 次。 Webpack 只导入一次，然后在每次导入时使用对模块的引用。

查看这些资源：

【讨论】：

当然这是有道理的，但它有一个巨大的缺点。如果我在多个地方需要它并且感觉不对，我需要一直导入每个类或子类模型或任何东西。也许不直接将其添加到全局范围，而是将其添加到 global.MyLibs 将解决该问题。感觉更像是用其他语言编程，你可以访问这些课程。这个逻辑有什么缺陷？ ://
我不懂“类或子类”。如果一个类扩展了另一个类，则不必每次都导入所有链。
如果你想使用超类的静态方法，你可以这样做。我喜欢我被否决的方式，但除了你之外没有人能全面回答这个问题。
你能通过添加一个最小的代码示例来编辑你的问题吗？我很好奇你的问题，我认为这很有趣。