Comment configurer un module de fonctionnalités avec chargement paresseux dans Angular

Dans le développement d'applications Angular complexes, la gestion des modules et des routes est essentielle pour garantir une navigation fluide et un chargement efficace des ressources. Un des concepts fondamentaux dans ce domaine est le chargement paresseux (lazy loading), qui permet de charger certains modules uniquement lorsque cela est nécessaire, afin d'optimiser la performance de l'application.

Dans cette configuration, la route 'b' est connectée via une ligne pointillée, ce qui indique qu'il s'agit d'une route à chargement paresseux. Cela signifie que route b ne sera chargée que lorsque l'utilisateur naviguera vers un chemin commençant par '/b'. Ce mécanisme permet de séparer le chargement des modules en fonction des besoins spécifiques de l'utilisateur, optimisant ainsi l'expérience et la performance du système.

Un exemple de définition de route pour rootRouter pourrait ressembler à ceci :

typescript
Copy code
const routes: Routes = [

   { path: '', redirectTo: '/a', pathMatch: 'full' },

   { path: 'a', component: AComponent, children: [

       { path: '', component: MasterComponent, outlet: 'master' },

       { path: '', component: DetailComponent, outlet: 'detail' },
   ] },

   { path: 'b', loadChildren: () => import('./b/b.module').then((module) => module.BModule), canLoad: [AuthGuard] },

   { path: 'c', loadChildren: () => import('./c/routes').then(mod => mod.C_ROUTES) },

   { path: '**', component: PageNotFoundComponent },

];

Notez que dans cet exemple, les routes '/b/a', '/b/b', '/c/a' et '/c/b' ne sont pas définies dans rootRouter. Cela nous amène à la configuration du childRouter, qui gère les routes internes de 'b' et 'c'. Voici un exemple de définition des routes pour childRouter :

typescript
Copy code
const routes: Routes = [

   { path: '', redirectTo: '/b/a', pathMatch: 'full' },
   { path: 'a', component: BAComponent },
   { path: 'b', component: BBComponent },
];

Il est important de souligner que ces routes, bien que définies dans le childRouter, sont totalement indépendantes de celles du rootRouter. Cela signifie que pour naviguer vers BAComponent, il faudra utiliser le chemin '/b/a', et pour CAComponent, le chemin '/c/a'. Ce système de hiérarchie de routes permet de maintenir une organisation claire et modulaire du code.

Dans ce contexte, chaque composant défini dans rootRouter et ses dépendances seront chargés de manière anticipée dans le premier chunk de l'application, tandis que les composants de childRouter (comme BAComponent et BBComponent) seront chargés paresseusement, c'est-à-dire uniquement lorsque l'utilisateur naviguera vers un chemin impliquant ces composants.

Mise en œuvre du chargement paresseux dans un module de fonctionnalités

1. Création du composant ManagerHome :

   Utilisez la commande suivante pour créer le composant d'accueil du module Manager :

   bash
   Copy code
   $ npx ng g c manager/managerHome manager -s -t
   

   Cela crée un nouveau composant appelé ManagerHomeComponent dans le répertoire approprié. Nous choisissons de ne pas créer de fichiers HTML et CSS séparés car ce composant est assez simple.

2. Configuration des routes pour ManagerModule :

   Dans le fichier manager-routing.module.ts, nous configurons les routes spécifiques au module ManagerModule. Le chemin de base pour ce module sera /manager. Voici la configuration des routes :

   typescript
   Copy code
   const routes: Routes = [
   
      { path: '', redirectTo: 'home', pathMatch: 'full' },
   
      { path: 'home', component: ManagerHomeComponent },
   
   ];
   

3. Chargement paresseux du module Manager :

   Pour activer le chargement paresseux pour ce module, nous devons configurer la route /manager dans le fichier app.routes.ts en utilisant l'attribut loadChildren. Cela permet à Angular de charger ManagerModule uniquement lorsque l'utilisateur accède à ce module, ce qui évite un chargement inutile au démarrage de l'application :

   typescript
   Copy code
   const routes: Routes = [
   
      { path: 'manager', loadChildren: () => import('./manager/manager.module').then(m => m.ManagerModule) },
   ];
   

Observation du chargement paresseux avec Angular DevTools

bash
Copy code
Lazy Chunk Files            | Names          |  Raw Size | src_app_manager_module_ts.js| manager-module | 358.75 kB

Cela confirme que le module ManagerModule a été chargé de manière paresseuse et est maintenant disponible pour l'utilisateur.

Ce qu’il est important de comprendre

Dans un projet Angular utilisant des modules de fonctionnalités avec chargement paresseux, il est crucial de bien configurer les routes et de s’assurer que les modules sont correctement séparés en unités logiques. Chaque module doit être autonome, gérant ses propres dépendances et ses routes. Cela permet non seulement d'optimiser la performance de l'application, mais aussi de faciliter la maintenance et l’évolutivité du code à long terme.

Comment construire une architecture complète avec la pile MEAN et une approche minimaliste

Lorsque nous abordons le développement d'applications web modernes, la question du choix de la pile technologique se pose souvent. Dans le contexte de la pile MEAN, qui combine MongoDB, Express, Angular et Node.js, il est important de comprendre non seulement la façon dont chaque composant interagit, mais aussi la philosophie qui sous-tend cette architecture. Ce chapitre s'intéresse à la mise en place d'une architecture complète en utilisant la pile MEAN, avec une approche minimaliste qui permet de mieux comprendre son fonctionnement et d'optimiser les performances.

La pile MEAN est un ensemble d'outils puissants pour la création d'applications web dynamiques. En particulier, elle s'avère particulièrement utile lorsque vous travaillez avec des bases de données JSON, grâce à MongoDB, qui permet de simplifier la gestion des données sans la nécessité de transformations complexes. Cela devient un atout considérable, surtout par rapport à d'autres technologies comme Java ou .NET qui exigent de manipuler les données sous des formats différents.

Lors de la mise en place du projet, plusieurs étapes doivent être suivies. Tout d'abord, la configuration initiale passe par la création de deux fichiers .env : un à la racine du projet et un autre sous le dossier du serveur. Ces fichiers permettent de contenir les informations de configuration privées. Le projet peut ensuite être compilé en exécutant npm run build à la racine, ce qui permet de générer à la fois le serveur et l'application web.

Une fois l'application prête, Docker est utilisé pour créer des versions containerisées du serveur, de l'application web et de la base de données MongoDB. En exécutant la commande docker compose up --build, vous pouvez facilement déployer l'ensemble des services. L'application web sera accessible via l'adresse http://localhost:8080, où vous pourrez vous connecter en utilisant des identifiants par défaut. Quant au serveur, il sera accessible à http://localhost:3000, avec la documentation API interactive disponible à http://localhost:3000/api-docs.

Le véritable défi de l'architecture full-stack réside dans la gestion et l'intégration de tous ces composants. En tant que développeur, bien que vous n'ayez pas besoin de maîtriser tous les aspects de chaque technologie, une compréhension de la façon dont elles interagissent entre elles est essentielle. Il est difficile de devenir un expert absolu dans chaque domaine, mais une solide maîtrise des outils que vous utilisez, tels que TypeScript, Docker et GitHub, vous permettra de mieux appréhender les différentes couches d'une application web complète.

Le concept de "full-stack" désigne cette capacité à intervenir sur toutes les couches d'une application, de la base de données au front-end, mais dans la réalité, chaque domaine nécessite une expertise spécifique. Toutefois, une compréhension générale des technologies utilisées permet de mieux gérer les dépendances et de s'assurer que le développement reste fluide et cohérent.

Une approche minimaliste dans l'usage des technologies et des outils peut s'avérer bénéfique à long terme. En évitant de surcharger le projet avec des bibliothèques et des dépendances inutiles, vous réduisez non seulement la complexité du code, mais vous améliorez également les performances et la maintenabilité du projet. Cela permet d'éviter le cercle vicieux d'ajouter de nouvelles bibliothèques pour résoudre des problèmes créés par d'autres dépendances. En se concentrant sur l'essentiel, vous devenez un développeur plus efficace.

Ainsi, lorsque vous choisissez votre pile technologique, il est crucial de prendre en compte non seulement la compatibilité avec les exigences du projet, mais aussi la facilité d'utilisation, le bien-être des développeurs et leur efficacité dans le long terme. Un code facile à maintenir, une architecture cohérente et un environnement de développement agréable sont des facteurs qui influencent directement le succès de l'application.

La philosophie du "minimal MEAN" repose sur l'idée qu'il est préférable de maîtriser quelques outils fondamentaux plutôt que de se disperser dans une multitude de bibliothèques et de technologies. Cela ne signifie pas que vous devez éviter l'innovation ou les nouvelles pratiques, mais plutôt que vous devez prendre le temps de comprendre les outils que vous utilisez et attendre que les bibliothèques arrivent à maturité avant de les intégrer dans votre projet. Le but est de rester simple, d'éviter les outils en version bêta et de se concentrer sur la base solide des technologies éprouvées.

Le projet LemonMart est un exemple concret de cette approche minimaliste, combinant Angular pour la couche présentation, Express pour l'API, et MongoDB pour la gestion des données. Express, avec son écosystème de plugins, offre une grande flexibilité, et Node.js, en tant que runtime léger et performant, permet une exécution rapide des applications. MongoDB complète l'architecture en permettant une gestion simple et efficace des données dans un format JSON.

L'un des points cruciaux que tout développeur devrait garder à l'esprit lorsqu'il travaille avec une pile complète comme celle-ci est la gestion des API. Le choix entre REST et GraphQL, par exemple, dépendra de la nature de l'application et de la manière dont les données sont utilisées. REST, bien que plus simple à mettre en place, peut devenir complexe à gérer lorsque l'application évolue. GraphQL, quant à lui, offre plus de flexibilité et d'efficacité, mais nécessite une configuration plus avancée.

En conclusion, la pile MEAN offre un cadre puissant et flexible pour développer des applications web modernes, mais comme pour toute technologie, il est essentiel de choisir les bons outils et de s'assurer qu'ils répondent aux besoins spécifiques du projet. Le plus important est de comprendre l'interaction entre ces outils et de garder à l'esprit que la simplicité et la cohérence de l'architecture sont des clés du succès.

Pourquoi les tests unitaires Angular ne sont-ils pas vraiment des tests unitaires ?

Dans le monde du développement logiciel, particulièrement dans des frameworks comme Angular, la pression est forte pour livrer des résultats rapidement et efficacement. Les longues sessions de codage alimentées par la motivation, les réponses copiées de StackOverflow, un paquet npm ou même une bibliothèque majeure comme Angular, deviennent un terrain propice aux erreurs. Nous devons livrer des résultats de qualité dans des délais souvent serrés, ce qui engendre inévitablement des bugs dans notre code. Les tests automatisés sont censés garantir que notre code est correct et reste correct. Cependant, ces tests ne sont efficaces que si la qualité des tests eux-mêmes est irréprochable. C’est là que les tests unitaires d'Angular montrent leurs limites.

Les tests unitaires : essentiel mais mal compris

Les tests unitaires sont des éléments essentiels pour garantir que le comportement de votre application ne change pas de manière non intentionnelle au fil du temps. Ils permettent aux développeurs et à leurs équipes de modifier l'application sans risquer d'altérer des fonctionnalités déjà vérifiées. Cependant, pour qu’un test unitaire soit vraiment utile, il doit être écrit avec soin et, surtout, avec une discipline rigoureuse. L’objectif d’un test unitaire est d’isoler un bloc de code pour tester son comportement indépendamment de tout autre composant, ce qui le rend rapide, autonome et répétable.

Le piège des tests Angular

Dans le cadre d'Angular, le problème devient encore plus évident. Un composant Angular n’est pas simplement une classe avec des méthodes : il est constitué d’une classe et d’un modèle (template). Pour tester un véritable composant, une interaction avec le DOM est nécessaire, ce qui implique l’utilisation de TestBed, un outil destiné à configurer l’environnement de test. Malheureusement, TestBed se révèle lent et fragile, ce qui le rend peu adapté aux tests unitaires, qui doivent être rapides et isolés. De plus, la configuration de l'injection de dépendances dans Angular est complexe et nécessite souvent de nombreuses manipulations pour simuler des comportements extérieurs.

C'est ici que les tests unitaires Angular se transforment en tests d’intégration, car ils ne sont plus limités à un seul composant ou à un seul service, mais incluent toute une série de dépendances. Par conséquent, les tests Angular, bien qu’ils soient appelés "unitaires", ne remplissent pas les critères d'un véritable test unitaire. Il s'agit plutôt de tests d'intégration, où plusieurs parties du système sont testées ensemble. Cette réalité pousse à reconsidérer la manière dont on structure les tests dans un projet Angular.

Le rôle des "doubles de test"

L’un des moyens de tenter de contourner ces limites est l’utilisation de ce que l’on appelle des "doubles de test" (mocks ou fakes). Un double de test permet de simuler des services ou des composants externes afin de contrôler les dépendances et isoler les tests. Par exemple, au lieu d’utiliser un HttpService réel dans un composant, on peut injecter un faux service ou une version simulée du service. Cela permet de rendre les tests plus rapides, plus isolés et plus prévisibles. Cependant, même avec des doubles de test, les tests Angular ne sont toujours pas aussi efficaces et rapides que des tests unitaires classiques.

Un déséquilibre dans la pyramide des tests

La pyramide des tests, popularisée par Mike Cohn, offre une vue d'ensemble sur les types de tests qu’un développeur devrait mettre en place. Elle place les tests unitaires à la base, en raison de leur rapidité et de leur coût réduit, tandis que les tests d'intégration et les tests UI occupent les niveaux supérieurs de la pyramide en raison de leur lenteur et de leur coût plus élevé. Cependant, en Angular, les tests unitaires sont souvent poussés dans une catégorie d’intégration, ce qui fausse l'équilibre de cette pyramide.

Les tests d'intégration, qui vérifient l'interaction de plusieurs composants entre eux (et non un seul), nécessitent des temps d'exécution plus longs et une maintenance plus régulière. De même, les tests UI, qui simulent l'interaction avec l'application telle qu'un utilisateur le ferait, sont souvent les plus lents et les plus fragiles. Leur mise en œuvre dans un projet Angular, bien que cruciale pour les tests d’acceptation, ne remplace en rien les tests unitaires et ne doit pas être une solution de contournement.

Réflexions sur les tests Angular

Il est également essentiel de garder à l'esprit qu'un test unitaire efficace ne doit pas être seulement un test qui fonctionne, mais un test qui permet de garantir la stabilité du code au fil du temps. Ainsi, même si Angular ne permet pas de réaliser des tests unitaires purs, il reste crucial de revoir la manière dont les tests sont structurés dans le projet pour atteindre un juste équilibre entre tests unitaires, d’intégration et d’acceptation.