构造 Angular 接口文件和用户定义类型保护的约定答案

【问题标题】：Convention for Structuring Angular Interface Files and User Defined Type Guards构造 Angular 接口文件和用户定义类型保护的约定
【发布时间】：2017-05-22 12:56:14
【问题描述】：

我在我的 Angular 2 项目中使用接口，并且还创建了用户定义类型保护：

grid-metadata.ts

export interface GridMetadata {
  activity: string;
  createdAt: object;
  totalReps: number;
  updatedAt: object;
}

grid.service.ts

...
    function isGridMetadata(obj: any): obj is GridMetadata {
      [ 'activity', 'createdAt', 'totalReps', 'updatedAt' ].every((prop) => {
        if (obj.hasOwnProperty(prop) === false) return false;
      });

      return typeof obj.activity === 'string' &&
        obj.createdAt.hasOwnProperty('.sv') &&
        obj.createdAt['.sv'] === 'timestamp' &&
        typeof obj.totalReps === 'number' &&
        obj.updatedAt.hasOwnProperty('.sv') &&
        obj.updatedAt['.sv'] === 'timestamp' ?
          true :
          false;
    }
...

存储（即在文件结构中）接口的约定是什么；例如，它们应该在自己的文件中还是在interface 或util 目录或文件中？

存储共享的用户定义类型保护的约定是什么？将接口和 UDTG 放在同一个文件中（因为它们是相关的）或将所有 UDTG 放在一个共享模块中是否有意义？

在构建我的项目时，我找不到任何关于最佳实践或普遍接受的约定的可靠示例。

【问题讨论】：

我认为我们的目标是让每个东西都放在单独的容器/文件/块/文件夹中。所以，在你的界面上有一个文件。实现该接口的类的文件。扩展该类的文件（例如），等等。
我认为这是相当主观的。我经常看到人们说一致性比你如何命名或放置它（在合理范围内）更重要。

标签： angular typescript conventions convention file-structure

【解决方案1】：

如果我理解得很好，Angular 就是把每件事都放在正确的位置。

这就是为什么我们有这样的结构：

+用户
- user.ts
- user-profile.ts
- user-dashboard.component.ts
- user-dashboard.component.html
- users.service.ts
- users.module.ts

+users 将是用户的文件夹。

user.ts 可以是 UserInterface，每个人说。
user-profile.ts 可能是 Class 实现 UserInterface。
user-dashboard.component.ts 可能是用户的仪表板组件。 Class 可能会扩展 UserProfile 类。

等等……

这就是我看到一些 OOP 项目的结构，以及我如何解释 Angular 的开发人员想要的。

【讨论】：