Composant angulaire vs classes de typescript de modèle

Imaginez que vous ayez un composant de registre où vous faites référence au modèle utilisateur, vous pouvez avoir un composant de connexion où vous faites également référence à ce modèle. Donc, créer une classe de modèle séparée est une bonne pratique pour la réutilisation du code;)

Vous utiliserez généralement des modèles pour transmettre des données vers / depuis le serveur et ceux-ci peuvent être partagés entre différents composants via un service.

À titre d'exemple simple, vous pouvez avoir deux vues (composants) pour les données dans la base de données. L'un est une liste de tous les éléments de la base de données (par exemple, les utilisateurs) et l'autre est une vue d'ajout / modification. Vous auriez quelque chose comme un service UserService avec des fonctions telles que GetUser, UpdateUser, CreateUser qui retournent toutes ou agissent sur un ou plusieurs modèles utilisateur.

Pour des ensembles de données plus complexes, vous pouvez choisir d'avoir une «liste» allégée modèle par exemple UserListModel et un UserModel standard afin que vous ne retiriez pas des montagnes de données pour une liste résumée. Mais pour des données plus simples, la réutilisation est essentielle. Et la création de modèles vous simplifie la vie, surtout si vous utilisez quelque chose comme TypeWriter (dans Visual Studio) pour créer automatiquement des versions dactylographiées de vos DTO côté serveur, entités, etc., ce qui vous fait gagner beaucoup de temps et garantit que votre serveur et le code côté client reste synchronisé et réduit également la surcharge de développement.

MODIFIER Selon votre commentaire - ce n'est pas un ModelComponent, c'est juste un modèle / classe et devrait ressembler à quelque chose comme:

export class UserListComponent implements NgOnit{

  public users: UserModel[];

  constructor(
    private userService: UserService
  ) { 
  }

  ngOnInit(): void {
    this.userService.getUsers().subscribe(users => {
         this.users = users;
    });
  };
}



export class UserComponent implements NgOnit{

  public user: UserModel;

  constructor(
    private userService: UserService
  ) { 
  }

  ngOnInit(): void {
    this.userService.getUser(/*some userId probably from route*/).subscribe(user => {
         this.user = user;
    });
  };
} 

Vous utiliseriez alors un UserService user.service.ts pour accéder aux instances du UserModel dans les deux composants, par exemple:

export class UserService {

  constructor(
         private http: HttpClient, 
         @Inject('BASE_URL') private baseUrl: string) {}

 getUser(userId:number): Observable<UserModel> {
    return this.http.get<UserModel>(this.baseUrl + 'api/users/get/' + userId);
  }

 getUsers(): Observable<UserModel[]> {
    return this.http.get<UserModel[]>(this.baseUrl + 'api/users/list');
  }
} 

Ensuite, vous injecteriez votre UserService dans les deux composants, par exemple:

export class UserModel  { 
    public  userName: string;
    public  email: string;
    public  firstName: string;
    public  lastName: string;
} 

L'idée est d'utiliser le même modèle de données dans de nombreux endroits dont nous avons besoin. Avec Typescript, nous pouvons vérifier le type de toute propriété définie à l'intérieur d'un service ou d'un composant ou de gardes ou même de directives. Ainsi, le même type de données [ou type de données] est utilisé à plusieurs endroits, ce qui garantira que nous ne commettons aucune erreur de codage avec les propriétés.

Si vous définissez un objet complexe dans votre composant comme de type any, vous perdez IntelliSense et la sécurité de type. Si vous définissez le type complexe comme une interface ou une classe à l'intérieur du composant, sa portée est limitée à ce composant. Il peut y avoir des scénarios comme celui-là, mais si vous définissez des modèles dans un emplacement central distinct, vous pouvez les importer dans d'autres classes, en vous assurant que le code est de type sécurisé.

Même si la logique est destinée à être utilisée uniquement à l'intérieur d'un seul composant, il est conseillé de séparer une logique "métier" de la logique de vue, il suffit de simplifier le code du composant par cela. Si vous déplacez toute la logique qui n'est pas liée à la vue vers un service, vous pouvez facilement tester cette logique, et c'est un énorme avantage. Consultez également la section Déléguer une logique de composant complexe aux services de le guide de style angulaire.