angular - 如何跨 Angular 模块正确导入/导出类？

Question

本题来自企业应用的语境。

从我读过的所有书籍和我看到的关于 Angular 应用程序的在线示例中，每次我们创建一个类(组件、服务、实体等)时，我们都会在类型定义上导出它们，然后直接导入它们在我们需要引用的任何地方(类似于在 C# 上使用命名空间)，无论两个类属于相同还是不同的 Angular 模块。

例如:

// In 'Commons/logger.service.ts'
export class LoggerService { ... }

// In 'Core/common.service.ts'
export class CommonService { ... }

// In 'Products/' module
import { LoggerService } from '../Commons/logger.service'
import { CommonService } from '../Core/common.service'

export class ProductComponent { ... }

我开始从事一个(大型)企业应用程序项目并注意到一种我以前从未见过的方法，他们创建文件来收集每种类型的类(服务、实体、方法参数、组件)并导出它们中的每一个，导出这些文件中的每一个都在其对应的 Angular 模块文件中，然后不是直接从类型的文件中导入类型，而是从给定的模块中执行导入。

前面的例子会变成这样:

// In 'Commons/logger.service.ts'
export class LoggerService { ... }

// In 'Commons/services.ts'
export * from './logger.service.ts'
export * from './other.service.ts'
export * from './another.service.ts'

// In 'Commons/commons.module.ts'
export * from 'services.ts'
export * from 'entities.ts'
/* ... */


// In 'Products/' module
import { LoggerService, OtherService } from '../Commons/commons.module'

export class ProductComponent { ... }

考虑到这种方法比以前的方法冗长得多，并且在某些情况下会导致尴尬的结果(如果在同一模块中导入类，则出现循环引用警告)

我的问题是:

1. 从良好设计或最佳实践的 Angular 推荐哪种方法？
2. 与前者相比，是否推荐这种方法？为什么？适用于哪些情况？
3. 为什么没有在主要文档来源( Angular 在线文档、 Angular 书籍等)中引入这种方法？
4. 这种方法的优缺点是什么。

Answer 1

这是一个称为桶文件的概念。这些文件使导入类更加方便。这不仅仅是 Angular 的概念。使用它们似乎是 TypeScript 中的最佳实践。

当您有一个较小的项目时，您可能看不到创建这些文件的很多好处，但是当与多个团队成员一起处理较大的项目时，它们会非常有用。以下是我知道的一些优点/缺点。

优点:模块内部所需的知识较少

当一个组件需要引用某些东西时，它不应该知道类等文件在哪个文件中。模块将需要确切地知道哪个文件(包括子路径)包含该项目。如果您将项目放入单个模块桶中，您只需要知道它来自哪个模块。这也给您带来了重构模块的好处，不需要您确保在文件移动时更新路径(您的工具可能会或可能不会帮助解决这个问题)。

// without barrel files
import { Class1 } from 'app/shared/module1/subpath1/subpath2/class1.service';

// using barrel files
import { Class1 } from 'app/shared/module1';

优点:显式导出外部模块

另一个好处是，一个模块可能包含一堆类、接口(interface)等，它们实际上只打算在该模块内使用。通过为模块创建桶文件，您可以让其他开发人员知道在模块外部使用什么。此外，您让他们确切知道要使用哪些项目，因此他们无需四处寻找所需的界面(同样，您的工具可能有助于也可能不会帮助)。

// export these items from module as others need to have references to these
export { ExampleModule } from './example.module';
export { ExampleService } from './example.service';
export { ExampleInterface } from './example.model';

// these also exist in module but others don't need to know about them
// export { ExampleComponent } from './example.component';
// export { Example2Service } from './example2.service';
// export { ExampleInterface2 } from './example.model';

优点:清洁进口

我要提到的最后一个好处是它有助于清理您的导入。它不仅使哪些项目来自哪些模块更加清晰，还有助于使导入的 from 部分更短，因为您不需要向下遍历子目录等。请注意，最好的做法似乎是将桶文件 index.ts 放在文件夹中，因为 TypeScript 编译器在给定要从中导入的文件夹时会默认查找该文件。

// without barrel files (hopefully they would be not randomly ordered to make it even harder...)
import { Class1 } from 'app/shared/module1/subpath1/subpath2/class1.service';
import { Class2 } from 'app/shared/module1/subpath1/class2.component';
import { Interface1 } from 'app/shared/module1/module1.model';
import { Class3} from 'app/shared/module2/subpath3/class3.service';
import { Interface2 } from 'app/shared/module2/module2.model';

// using barrel files
import { Class1, Class2, Interface1 } from 'app/shared/module1';
import { Class3, Interface2 } from 'app/shared/module2';

缺点:附加文件

在尝试确定缺点时，我唯一能想到的是您正在为每个模块创建另一个文件(或者可能是子文件夹，具体取决于您的操作方式)。据我所知，它没有运行时或编译时效果。