Les modules sont les éléments les plus macroscopiques d’une application Angular. Ils servent à centraliser tous les autres éléments d’une application : les composants, les services, les pipes, etc. Je vous recommande fortement de définir à l’avance quels modules vous aurez besoin pour votre projet. Il existe plusieurs types de module dans une application Angular. Vous en connaissez peut-être déjà certains :

Le module racine : C’est le module parent de tous les autres modules dans une application. Il est nommé AppModule par convention, et Angular CLI l’a déjà généré dans le fichier app.module.ts.
Les modules natifs d’Angular : On retrouve le RouterModule pour la gestion des routes, le HttpClientModule pour la gestion des requêtes réseaux, ou encore le FormsModule pour la gestion des formulaires.
Les modules de définition des routes : Il s’agit de module dédié uniquement à la gestion des routes. Ils sont toujours rattachés à un autre module. Par exemple, Angular CLI a généré le module AppRoutingModule, qui définit les routes globales de notre application, et qui est importé dans le module racine AppModule.

Les modules de fonctionnalités : Ils sont dédiés aux fonctionnalités spécifiques de votre application. Ils vous permettent de regrouper les éléments nécessaires pour implémenter une fonctionnalité : les services, les composants, les routes, etc. Par exemple dans notre cas, nous devrons surement créer un module de fonctionnalité dédié à la gestion des tâches : les afficher, en ajouter, effectuer des opérations de modification ou de suppression. Concrètement, un module de fonctionnalité sera un dossier dans votre projet, contenant tous les éléments nécessaires pour fonctionner :

Architecture en module de fonctionnalités.

Comme indiqué sur ce schéma, les modules de fonctionnalités sont suffisants pour structurer de petite ou moyenne application. Cependant, pour des applications plus importantes, je pense que nous devons voir d’autres pratiques qui vont nous servir pour mettre en place notre architecture.

Sur ce schéma, je remarque qu’un module de fonctionnalité peut contenir d’autres modules de fonctionnalité. C’est bien ça ?

Effectivement, un module de fonctionnalité peut tout à fait contenir d’autres modules du même type. D’ailleurs, cela va nous être utile pour découper notre application en deux parties : une partie publique accessible à tout le monde, et une partie privée réservée aux utilisateurs authentifiés. Pour chaque partie de notre application, nous créerons un module dédié. Cela permettra de regrouper plusieurs modules de fonctionnalités en grandes zones dans votre application : zone publique, zone protégée, etc. On pourrait même imaginer une zone administration par exemple, accessible uniquement par les personnes en charge de l’exploitation de l’application.

D’accord, ça a l’air pas mal tout ça. Et si je dois regrouper un composant ou service que j’utilise dans plusieurs modules différents ?

Très bonne question ! Nous aurons rapidement du code commun entre plusieurs modules : les services d’accès aux données, les classes modélisant les entités de notre application, etc. C’est un problème récurrent sur lequel l’équipe Angular de chez Google a déjà réfléchi. Il est donc recommandé d’utiliser deux modules supplémentaires afin d’organiser son code d’une façon cohérente : le CoreModule et le SharedModule. Il s’agit de modules standards, mais qui respectent une certaine convention de nommage et de fonctionnement.

Previous Étape

Back to Chapitre

Next Étape