2.4. Implémentation de nos modules

Nous allons enfin implémenter nos propres modules. Je vous ai présenté les différents modules qui peuvent exister, ainsi que l’ensemble des pages disponibles dans notre application. Nous allons commencer par découper notre application en quatre modules principaux :

• Le module racine AppModule, déjà généré pour nous par Angular CLI dans le fichier app.module.ts.
• Le module PublicModule qui va contenir toutes les pages publiques de notre application : la page d’accueil, de connexion et d’inscription.
• Le module ProtectedModule, qui contiendra notre application de productivité.
• Les modules CoreModule et SharedModule, que nous avons vu précédemment.

Nous allons utiliser toute la puissance d’Angular CLI pour générer ces modules. Ouvrez donc un terminal de commandes à la racine de votre projet. La commande permettant de générer un module ressemble à quelque chose comme ça :

ng generate module <nom_module>

On peut passer certaines options supplémentaires à cette commande, afin de mieux paramétrer le module qui est généré. Par exemple, l’option routing permet d’ajouter un module de gestion des routes au module généré, et l’option module permet de préciser un module parent.

Voyons en pratique comment cela fonctionne. Respirez un grand coup, et exécutez les quatre commandes suivantes :

ng generate module core --module app
ng generate module shared
ng generate module public --routing --module core
ng generate module protected --routing --module core

Si vous retournez dans votre éditeur de code, vous devriez voir quatre nouveaux dossiers dans le sous-dossier src/app (ce sous-dossier est l’emplacement dans lequel Angular CLI génère les nouveaux fichiers).

Le CoreModule et le SharedModule sont composés d’un seul fichier. En revanche, les deux autres modules comprennent respectivement deux fichiers, car un module de gestion des routes a été généré en plus, comme nous l’avons demandé avec l’option routing :

Pour être sûr de bien comprendre… pourquoi les modules public et protected ont comme module parent le module core ?

En fait, le CoreModule a pour rôle de décharger au maximum le AppModule, qui doit conserver que son rôle de module racine, avec le strict minimum à l’intérieur. Pour les modules Protected et Public , on les charge donc dans le CoreModule, et non dans le AppModule. 👍