如何在角度模块中正确导入/导出类?

时间:2018-03-01 23:07:15

标签: angular typescript ecmascript-6

这个问题来自企业应用程序的背景。

从我阅读过的所有书籍和我已经看过的关于角度应用程序的在线示例,每次我们创建一个类(组件,服务,实体等)时,我们将它们导出到类型定义上然后直接导入它们我们需要引用的地方(类似于在C#上使用命名空间),无论这两个类属于相同或不同的角度模块。

例如:

// 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 { ... }

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

上一个示例将转换为以下内容:

// 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. 从良好的设计或最佳实践角度推荐采用哪种方法?
  2. 这种方法是否比前者推荐?为什么?对于哪些情况?
  3. 为什么没有在文档的主要来源(角度在线文档,有角度的书籍......)上介绍这种方法?
  4. 这种方法的优点和缺点是什么。

1 个答案:

答案 0 :(得分:9)

这是一个称为桶文件的概念。这些文件使导入类更方便。 Angular团队does bring it up in their docs,但它不仅仅是Angular的概念。在TypeScript中使用它们似乎是最佳做法。

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

Pro:模块内部需要的知识较少

当一个组件需要引用某个东西时,它不应该知道该类等所处的确切文件。当你不在一个模块中存储东西时,那么每个其他文件都在模块需要确切知道哪个文件(包括子路径)包含该项。如果将物品装入单个模块桶中,您只需要知道它是什么模块。这也为您提供了重构模块的好处,无需您确保在文件移动时路径得到更新(您的工具可能会或可能没有帮助)。

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

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

Pro:明确导出模块外

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

// 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';

Pro:Cleaner Imports

我要提到的最后一个好处是它有助于清理你的进口。它不仅可以更清楚地显示哪些项目来自哪些模块,还有助于使导入的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';

Con:附加档案

在尝试识别缺点时,我唯一能想到的是你为每个模块创建另一个文件(或者根据你想要的方式创建子文件夹)。据我所知,它没有运行时或编译时效果。