ES2015模块化体系结构的标准方法是什么？

Question

我想我现在主要了解(至少在理论上) ES2015 Modules是如何工作的。

我不明白的是(这并不是无关紧要的)是如何启用模块脚本来通知我的主脚本。

通常，在HTML文档的底部，我有如下内容：

<script src="/global-script-is-a-classic-script.js"></script>

就这样。没有defer，没有async，没有type="module"。

我可能希望编写一些可选模块，它们声明函数、计算变量和对象，然后将所有声明的和计算的值都提供给global-scripts.js。

<script src="/module-script-1.mjs" type="module"></script>
<script src="/module-script-2.mjs" type="module"></script>
<script src="/module-script-3.mjs" type="module"></script>

当然，这些模块脚本中的每一个都将包含一个exports语句。

但是..。然后如何将这些模块脚本计算到我的import中？

我不能使用import --因为这只适用于模块脚本--而且(除非我弄错了)，将global-scripts.js作为一个经典脚本似乎是个坏主意。

那么，我现在需要两个全局脚本吗？

<script src="/global-script-is-a-classic-script.js"></script>
<script src="/module-mothership-is-a-module-script.js" type="module"></script>

还是有一种我们都应该使用的替代标准架构？

Answer 1

似乎您并不真正理解模块架构在设计理念上的变化。你不能让事情变得全球化。模块导入它所需要的其他模块，并从导入中获取其功能，而不是从某些全局函数集中获取功能。在模块化体系结构中，不存在全局脚本。这就是你的想法不太适合模块化架构的原因。

exports是一种使任何导入模块的人都可以公开访问某些入口点或数据的方法，同时将所有其他内容保持在模块的本地。必须导入模块才能访问这些入口点。

那么，导出是为了子模块和模块之间的通信，而不是用于模块和全局脚本之间的通信吗？也就是说，模块从来不导出，只有子模块做吗？

多半是。但是，即使是顶级模块也可以进行导出。在该项目中，如果它是顶级模块，则不会使用它们，但它可能会用于另一个项目，因为它不是顶级模块，而是由其他模块导入的。模块架构可以让您考虑代码重用和代码共享，而不必做大量额外的工作。通常编写项目的方式应该是自动创建一堆可重用的代码。

可能是我所需要的拼图的最后一部分。那么，导出只是子模块(和兄弟模块)吗？独立的、自成一体的顶级模块不需要导出，因为模块中的任何功能都发生在模块中--数据永远不需要转移到其他地方。(对吗？)

是。除非您可能希望能够在导入该模块的另一个项目中重用该模块，并且确实希望导入一些入口点或数据。

I可能希望编写一些可选模块，它们声明函数、计算变量和对象，并在计算之后，将所有声明的和计算的值都提供给global-scripts.js。但是..。然后如何将这些模块脚本计算的内容导入全局脚本my？

您将在模块设计中完全摆脱您的全局脚本。您将拥有一个导入其他模块的顶级模块。

那么，我现在需要两个全局脚本吗？

不，你摆脱了全局脚本，就不再让事情变得全球化了。

还是我们都应该使用的另一种标准体系结构？

模块架构：

Top Level Module
    import module1
       import moduleA
          import moduleZ
       import moduleB
    import module2
       import moduleB
       import moduleC
    import module3
       import moduleA
       import moduleD

这可以根据需要进入任意深度。模块被缓存，并且只初始化一次，因此从多个地方导入相同的模块是非常好和完全有效的。