Search code examples
angulartypescriptconventionsconventionfile-structure

Convention for Structuring Angular Interface Files and User Defined Type Guards


I am using Interfaces in my Angular 2 project, and also have created User Defined Type Guards:

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

What is the convention for storing (i.e. in a file structure) Interfaces; should they be in their own files or in an interface or util directory or file, for example?

What is the convention for storing shared User Defined Type Guards? Would it make sense to have the Interface and UDTG in the same file (as they are related) or have all UDTGs in a shared module?

I can't find any solid examples as to the best practice or commonly accepted conventions when structuring my project.


Solution

  • If I understood well Angular is all about havign each thing in its right place.

    That's why we have a structure like:

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

    Where +users would be the User's folder.

    • user.ts could be the UserInterface, per say.
    • user-profile.ts could be the Class implements UserInterface.
    • user-dashboard.component.ts could be the User's Dashboard component. The Class that maybe extends UserProfile class.

    And so on...

    That's how I saw some OOP project's were structured, and how I interpreted that Angular's devs wanted it to be.