结构化约定 Angular 接口文件和用户定义的类型保护

Convention for Structuring Angular Interface Files and User Defined Type Guards

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

网格-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;
    }
...

存储(即在文件结构中)接口的约定是什么?例如,它们应该在自己的文件中还是在 interfaceutil 目录或文件中?

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

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

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

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

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

其中 +users 是用户的文件夹。

  • user.ts 可以说是 UserInterface
  • user-profile.ts 可能是 Class 工具 UserInterface.
  • user-dashboard.component.ts 可能是用户的仪表板组件。 Class 可能扩展 UserProfile class.

等等...

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