我目前从Angular开始，之前曾与React合作。
到目前为止，在其他堆栈上，我写了一个新文件handle-error.js，并有选择地将其导入到几页上，例如endpoint1.js和endpoint2.js。假定将这些“端点”中的每一个定义为webpack上的条目文件，则webpack通常将就如何有选择地导入此公共模块handle-error.js或是否将其包含在commons包中进行研究。
另一方面，对于角度，我已经看到了@ngModule类中包装的几个常见库。因此，我不禁要问，如果仅在组件中导入handle-error.js而不是将其包装在@ngModule中，那会丢失什么？
编辑：
假设我有一个像这样的应用程序结构：
|__ base app module
|__ page 1 module
|__ page 2 module
|__ imports handleError() (*)
文档明确指出模块的主要目的之一是延迟加载。由于handleError仅在第2页中需要，会不会仅在请求第2页时才被懒加载？
另一个问题是：我也应该将其包装在服务中吗？尽管我可能已经知道答案了，但是它可以帮助进行模拟测试。
答案 0 :(得分：1)
webpack通常已经就如何有选择地导入此公共模块handle-error.js或是否将其包含在公共包中进行了研究
是的，没错，并且在Angular中也是如此。尽量不要认为NgModules与webpack捆绑包有关。确实，路由器定义的惰性模块将显示为单独的Webpack捆绑包。这纯粹是Angular编译器使用的打包策略。
所以我不禁要问，如果仅在组件中导入handle-error.js而不是将其包装在@ngModule中，那我会失去什么？
大约有25％的我的Angular项目源代码是这样完成的。
除非您需要使用Angular依赖项注入器，否则库，额外的类，接口，函数编程，实用程序以及其他类似的东西都不需要放在NgModule中。
文档明确指出模块的主要目的之一是延迟加载。由于handleError仅在第2页中需要，会不会仅在请求第2页时才被懒加载？
Angular和Webpack都不能基于动态用法来摇动代码。虽然webpack可以根据导入的用法摇摇欲坠。无法确定是否已在程序上引用了类型的全局定义。
由于依赖注入器的工作原理，这在Angular中尤其困难。
因此，可以考虑将NgModule作为向Angular声明项目中正在使用的 stuff （组件，服务，提供者等）的一种前期方式。
如果另一个模块未引用任何模块，则可以从构建中删除整个模块。 Angular必须以这种方式解决问题，因为它使用了运行时依赖注入器。
例如；
const thing = injector.get(SOME_UNKNOWN_TOKEN);
在上面的示例中，名为SOME_UNKNOWN_TOKEN的依赖项令牌要求注入程序提供thing的值。
Angular无法知道向谁，什么或如何提供SOME_UNKNOWN_TOKEN。它来自什么模块，负责提供它的人员等等。
因此它不能纯粹基于导入来摇摇欲坠。提供与thing定义的SOME_UNKNOWN_TOKEN的源代码可能尚未由与Angular源代码直接相关的任何内容（例如第三方库）导入。
我知道这不能直接回答您的问题，但这就是为什么我们使用模块而不是直接导入东西。可以肯定的是，如果没有依赖注入器，Angular在代码的连接方式上将与React非常相似。
另一个问题是：我也应该将其包装在服务中吗？尽管我可能已经知道答案了-它有助于进行模拟测试
这纯粹是基于Angular中的依赖项注入器的决定。
DI允许您执行许多值得学习的特殊操作，因为这是可以进行许多组件间连接的方式。组件也可以提供自己的服务等等。
我不将DI用于复杂的数据结构。就像一棵对象实例树或需要在其中创建事物的许多实例的树一样。 DI是依赖于其他服务的单一服务的理想选择。