Partie 1 : Démarrer un projet sur de bonnes bases
Partie 2 : Construire un espace membre sécurisé avec JWT
Partie 3 : Implémenter des fonctionnalités métiers
Partie 4 : Bonus

2.4.3. Réorganiser les importations de ses modules

Précédemment, nous avons généré un module nommé SharedModule. Nous pouvons déjà nous en servir, même si notre application est encore très limitée. Ce module va nous servir à factoriser les importations communes des autres modules.

En fait, Angular CLI génère chaque nouveau module en important automatiquement le module CommonModule. Il s’agit en quelque sorte du module “minimum” qui doit être importé dans chacun de vos nouveaux modules (excepté le module racine). Nous allons factoriser cette importation dans le SharedModule, afin d’anticiper les futurs développements.

Imaginons que plus tard, nous ajouterons des formulaires dans plusieurs modules différents. Nous serons obligés d’importer le module natif ReactiveFormsModule à chaque fois. Mais grâce à la factorisation que nous allons faire, il suffira d’importer une seule fois le ReactiveFormsModule dans le SharedModule, et il sera directement disponible pour tous les autres modules (enfin, tous les autres modules qui importent le SharedModule).

Bon, occupons-nous de cette factorisation. La première étape est de réexporter le module CommonModule que nous voulons factoriser, depuis le SharedModule. Ouvrez donc le fichier shared.module.ts, et ajoutez l’exportation suivante, à la ligne 10 :

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';

@NgModule({
  declarations: [],
  imports: [
   CommonModule
  ],
  exports: [
    CommonModule
  ]
})
export class SharedModule{}

Ensuite, dans tous les modules concernés, nous allons remplacer l’importation du CommonModule par notre SharedModule. Les modules concernés sont :

  • Les modules PublicModule et ProtectedModule.
  • Les autres modules : HomeModule, LoginModule, RegisterModule, DashboardModule, ParametersModule, PlanningModule, ProfilModule et WorkdayModule.

Nous ajoutons donc l’importation du SharedModule dans le premier module PublicModule :

import { NgModule } from '@angular/core';
// Remplacer l’importation du CommonModule par cette ligne :
import { SharedModule } from 'src/app/shared/shared.module';
import { PublicRoutingModule } from './public-routing.module';

@NgModule({
 declarations: [],
 imports: [
  // Impoter le SharedModule plutôt que le CommonModule :
  SharedModule,
  PublicRoutingModule
 ]
})
export class PublicModule { }

Ensuite, je vous laisse le soin d’appliquer les mêmes modifications aux autres modules. 👈

Dès que vous aurez terminé, nous aurons une base intéressante pour la suite des développements de notre application. Nous aurons juste à répartir nos futurs modules, composants, services, ou directives, dans les différents modules que nous avons mis en place.

On est prêt à passer à la suite du coup, même pas peur ! 😎

Attend ! Je pense avoir compris pas mal choses sur les modules, mais je ne suis pas sûr d’avoir bien compris le mécanisme d’importation et d’exportation des modules…

Effectivement, certains éléments peuvent encore sembler perturbants. Par exemple, pourquoi le module Register est importé dans le module Public, qui est lui-même importé dans le CoreModule, qui enfin est importé dans le AppModule, alors qu’aucun de ces modules n’exportent quoi que ce soit…

C’est une bonne question. La réponse la plus simple et concise que je puisse vous donner, est la suivante :

👉Tant qu’un module n’est pas relié d’une manière ou d’une autre au module racine AppModule, alors il n’existe pas pour Angular.

En effet, une application Angular est avant tout une hiérarchie de module, et donc tous les modules doivent être reliés à un moment ou à un autre au module racine, sinon il n’existe pas. Si on s’embête avec autant de modules, c’est parce que l’architecture des modules est importante dans une application Angular, comme nous le verrons par la suite (Structure du projet, chargement paresseux pour améliorer le temps de chargement de notre application, mise en place de la hiérarchie des injecteurs).

Aussi, une autre règle à garder en tête, qui m’a servi et me sert encore :

👉Un module n’exporte un module que si celui ci-contient un composant, une directive, ou un pipe, et que nous avons besoin de ces éléments ailleurs dans l’application.

L’exemple de base, c’est notre module NgxBootstrap, qui exporte des composants et des directives relatifs à Bootstrap. Mais dans l’exemple du module register-routing.module.ts, nous n’exportons que des routes. Dans ce cas, un import suffit. J’espère que c’est plus clair pour vous avec ces explications supplémentaires. 😉