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

问题描述 投票：3回答：1

这个问题来自企业应用程序的上下文。

从我读过的所有书籍和我见过的关于角度应用程序的在线样本，每次我们创建一个类（组件，服务，实体等）时，我们将它们导出到类型定义上，然后直接导入到我们需要的任何地方一个引用（类似于在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. 这种方法的优点和缺点是什么？
angular typescript ecmascript-6
1个回答
9
投票

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

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

专业：模块内部需要的知识较少

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

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

亲：清洁进口

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

骗局：附加档案

在尝试识别缺点时，我唯一能想到的是你为每个模块创建另一个文件（或者可能是子文件夹，具体取决于你想要的方式）。据我所知，它没有运行时或编译时效果。

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.