Angular

Appearance

Structurer et organiser son application ​

Imaginez que nous construisons une application e-commerce. Voici une structure possible pour cette application en utilisant des modules :

plaintext
e-commerce-app/
│
├── src/
│   ├── app/
│   │   ├── app.module.ts          # Module racine
│   │   ├── app.component.ts       # Composant racine
│   │   ├── app-routing.module.ts  # Configuration du routage principale
│   │   │
│   │   ├── core/                  # Module core pour les services singleton, les composants shell, etc.
│   │   │   ├── core.module.ts
│   │   │   ├── header/
│   │   │   ├── footer/
│   │   │   ├── services/
│   │   │   │   ├── auth.service.ts
│   │   │   │   ├── user.service.ts
│   │   │   └── ...
│   │   │
│   │   ├── shared/                # Module partagé pour les composants, directives, et pipes réutilisables
│   │   │   ├── shared.module.ts
│   │   │   ├── buttons/
│   │   │   ├── utilities/
│   │   │   └── ...
│   │   │
│   │   ├── products/             # Module de produits
│   │   │   ├── products.module.ts
│   │   │   ├── product-list/
│   │   │   ├── product-detail/
│   │   │   ├── product.service.ts
│   │   │   └── ...
│   │   │
│   │   ├── users/                # Module des utilisateurs
│   │   │   ├── users.module.ts
│   │   │   ├── profile/
│   │   │   ├── settings/
│   │   │   ├── users.service.ts
│   │   │   └── ...
│   │   │
│   │   ├── cart/                 # Module du panier
│   │   │   ├── cart.module.ts
│   │   │   ├── cart-page/
│   │   │   ├── cart-summary/
│   │   │   ├── cart.service.ts
│   │   │   └── ...
│   │   │
│   │   └── orders/               # Module des commandes
│   │       ├── orders.module.ts
│   │       ├── order-list/
│   │       ├── order-detail/
│   │       ├── orders.service.ts
│   │       └── ...
│   │
│   ├── assets/
│   ├── environments/
│   └── ...
│
├── node_modules/
├── angular.json
├── package.json
└── ...
e-commerce-app/
│
├── src/
│   ├── app/
│   │   ├── app.module.ts          # Module racine
│   │   ├── app.component.ts       # Composant racine
│   │   ├── app-routing.module.ts  # Configuration du routage principale
│   │   │
│   │   ├── core/                  # Module core pour les services singleton, les composants shell, etc.
│   │   │   ├── core.module.ts
│   │   │   ├── header/
│   │   │   ├── footer/
│   │   │   ├── services/
│   │   │   │   ├── auth.service.ts
│   │   │   │   ├── user.service.ts
│   │   │   └── ...
│   │   │
│   │   ├── shared/                # Module partagé pour les composants, directives, et pipes réutilisables
│   │   │   ├── shared.module.ts
│   │   │   ├── buttons/
│   │   │   ├── utilities/
│   │   │   └── ...
│   │   │
│   │   ├── products/             # Module de produits
│   │   │   ├── products.module.ts
│   │   │   ├── product-list/
│   │   │   ├── product-detail/
│   │   │   ├── product.service.ts
│   │   │   └── ...
│   │   │
│   │   ├── users/                # Module des utilisateurs
│   │   │   ├── users.module.ts
│   │   │   ├── profile/
│   │   │   ├── settings/
│   │   │   ├── users.service.ts
│   │   │   └── ...
│   │   │
│   │   ├── cart/                 # Module du panier
│   │   │   ├── cart.module.ts
│   │   │   ├── cart-page/
│   │   │   ├── cart-summary/
│   │   │   ├── cart.service.ts
│   │   │   └── ...
│   │   │
│   │   └── orders/               # Module des commandes
│   │       ├── orders.module.ts
│   │       ├── order-list/
│   │       ├── order-detail/
│   │       ├── orders.service.ts
│   │       └── ...
│   │
│   ├── assets/
│   ├── environments/
│   └── ...
│
├── node_modules/
├── angular.json
├── package.json
└── ...

Explications :

  • app.module.ts: C'est le module racine qui initialise l'application.

  • core/: Le module "core" contient des éléments qui sont créés une seule fois et ne sont jamais réimportés (comme les services qui doivent être des singletons).

  • shared/: Le module "shared" contient des composants, des directives et des pipes qui sont souvent réutilisés dans toute l'application.

  • products/, users/, cart/, orders/: Ces sont des modules fonctionnels. Chacun de ces modules représente une fonctionnalité ou une partie distincte de l'application.

Cette structure suit les meilleures pratiques d'Angular pour organiser les modules et les composants en fonction de leur responsabilité et de leur réutilisabilité.

Bonnes pratiques ​

  1. Ajoutez le suffixe Module au nom du symbole. Donner au nom du fichiez l'extension .module.ts. Nommez le module d'après la fonctionnalité et le dossier dans lequel il se trouve.

Exemple:

ts
@NgModule({ … }) 
export class AppModule { }
@NgModule({ … }) 
export class AppModule { }
  1. Structurez l'application de manière à pouvoir localiser rapidement le code, à l'identifier d'un coup d'œil, à conserver la structure la plus plate possible. Suivez la méthode LIFT.

Méthode LIFT (tirée du site officiel)

La méthode LIFT est une approche pour structurer et nommer les fichiers de code de manière à améliorer l'efficacité et la lisibilité du code. Elle est composée de quatre étapes principales :

  1. Localiser (Locate)

    • Style 04-02 : Il est recommandé de rendre le repérage du code intuitif et rapide.
    • Pourquoi ? Pour travailler efficacement, il est essentiel de pouvoir trouver rapidement les fichiers, surtout lorsque l'on ne connaît pas (ou ne se souvient pas) de leur nom. Le fait de garder des fichiers liés à proximité les uns des autres dans un emplacement intuitif permet de gagner du temps. Une structure de dossiers descriptive fait toute la différence pour vous et ceux qui vous succéderont.

  2. Identifier (Identify)

    • Style 04-03 : Nommez le fichier de manière à savoir immédiatement ce qu'il contient et ce qu'il représente. Soyez descriptif avec les noms de fichiers et limitez le contenu du fichier à un seul composant. Évitez les fichiers avec plusieurs composants, services ou mélanges.
    • Pourquoi ? Cela réduit le temps de recherche et rend le processus plus efficace. Les noms de fichiers plus longs sont nettement préférables aux noms abrégés mais obscurs. Il peut être avantageux de s'écarter de la règle "un élément par fichier" dans certaines situations, mais faites attention à cette exception.

  3. Aplatir (Flat)

    • Style 04-04 : Gardez une structure de dossiers plate aussi longtemps que possible. Pensez à créer des sous-dossiers lorsqu'un dossier contient sept fichiers ou plus. Envisagez de configurer votre IDE pour masquer les fichiers non pertinents ou générés.
    • Pourquoi ? Personne ne souhaite chercher un fichier à travers de multiples niveaux de dossiers. Une structure plate est plus facile à parcourir. Lorsqu'un dossier contient dix fichiers ou plus, il peut être temps de créer des sous-dossiers. Basez votre décision sur votre niveau de confort.

  4. T-DRY (Essayez d'être DRY)

    • Style 04-05 : Il est recommandé de suivre le principe DRY (Ne Vous Répétez Pas). Cependant, évitez d'être trop DRY au détriment de la lisibilité.
    • Pourquoi ? Être DRY est important, mais cela ne doit pas sacrifier les autres éléments de LIFT. C'est pour cela que cela s'appelle T-DRY. Par exemple, il serait redondant de nommer un modèle "hero-view.component.html" car avec l'extension ".html", il est évident qu'il s'agit d'une vue. Cependant, si quelque chose n'est pas évident ou s'écarte d'une convention, explicitez-le.

  1. Commencez modestement, mais gardez à l'esprit l'orientation future de l'application. Ayez une vision à court terme de la mise en œuvre et une vision à long terme. Placer tout le code de l'application dans un dossier nommé src. Envisager la création d'un dossier pour un composant lorsqu'il comporte plusieurs fichiers d'accompagnement (.ts, .html, .css et .spec).

  2. Créez des dossiers portant le nom de la fonctionnalité qu'ils représentent. Lorsqu'il y a beaucoup de fichiers, par exemple plus de 10, il est plus facile de les localiser avec une structure de dossiers cohérente et plus difficile avec une structure plate.

  3. Créer un module de fonctionnalité nommé SharedModule dans un dossier partagé ; par exemple, app/shared/shared.module.ts définit SharedModule. Déclarez des composants, des directives et des pipes dans un module partagé lorsque ces éléments seront réutilisés et référencés par les composants déclarés dans d'autres modules fonctionnels. Envisagez de ne pas fournir de services dans les modules partagés. Les services sont généralement des singletons qui sont fournis une seule fois pour l'ensemble de l'application ou dans un module particulier. (sauf si le service est propre au SharedModule, comme un simple filtre) Voir SharedModule.