从 @angular/material
导入各种模块时每个模块都是从不同的包路径导入的,使用格式@organization/library/<module>
,例如:
import { MatSidenavModule } from '@angular/material/sidenav';
import { MatSnackBarModule } from '@angular/material/snack-bar';
import { MatSortModule } from '@angular/material/sort';
import { MatTableModule } from '@angular/material/table';
import { MatProgressSpinnerModule } from '@angular/material/progress-spinner';
问题:
如何在图书馆中实现这一目标?
我有一个类似的文件夹结构,其中每个模块及其后续组件/服务/指令都有一个目录,以及
public-api.ts
导出每个成员,然后导出public-api.ts
在根级别,桶会导出所有内容。然后在使用应用程序中,导入每个模块:
import { FooModule, BarModule } from '@my-org/my-lib'
// instead of
import { FooModule } from '@my-org/my-lib/foo'
import { BarModule } from '@my-org/my-lib/bar'
- 这样做比仅仅从根导出所有成员有什么好处
@my-org/my-lib
路径(如果有)?
最佳答案
辅助入口点
经过一些研究,我发现这可以使用称为辅助入口点的概念来完成。这就是 Angular 团队在 @angular/core
和 @angular/material
库中使用的内容。
回答我之前的问题:
辅助入口点在库内提供多个较小的包,允许单独加载每个入口点而不是整个库。还可以为每个入口点指定唯一的依赖项,本质上充当“迷你库”,同时仍然作为更大库的一部分进行分发。
更小的包大小是通过更好地利用 Angular 的依赖树摇动来实现这一点的最大/最明显的好处。
- 例如大多数用户仅使用
@angular/material
UI 组件的一小部分,并且通过仅导入这些 UI 组件所需的模块,不需要包含其他组件的样式/逻辑在应用程序的最终 bundle 中。 - 此外,您仅包含所选入口点的依赖项。因此,其他[不需要的]依赖项不会包含在应用程序的最终 bundle 中。
来自下面的链接源:
"Subentries offer us an excellent way to deliver our library in multiple chunks. Those chunks are tree shakeable during Angular's build optimization. With this approach, even wrongly packaged third party libraries only get included in the final bundle if they are used."
来源:
This Angular In Depth Article全面解释了如何在 Angular 库中实现此功能以及这样做的好处。
关于angular - 如何构造一个 Angular 库以具有多个导入路径(如 @angular/material),这样做有什么好处?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/66356480/