Introduction

Dans ce chapitre, nous allons aller plus loin dans l’exploration des possibilités qu’offre Angular. Que ce soit pour rendre votre application accessible à un public international, améliorer son référencement naturel grâce au rendu côté serveur, ou automatiser et optimiser vos processus de développement avec Angular CLI, ce chapitre vous guidera dans l’exploitation de fonctionnalités plus polyvalentes.

Rendre son application multilingue

Le fait de rendre un site multilingue n’est pas forcément la simple traduction des ressources. Voici une petite explication des termes et techniques communes.

i18n, une abréviation pour internationalization (internationalisation), englobe un second concept : l10n, qui correspond à localization (localisation). Ces abréviations sont appelées numeronyms en anglais, car cela consiste à garder uniquement la première et la dernière lettre du mot original, en complétant entre les deux du nombre de lettres restantes.

L’internationalisation consiste à concevoir et à préparer une application de manière générique pour qu’elle puisse être traduite et localisée par la suite.
La localisation est le processus d’adaptation de l’application pour une langue ou une région spécifique. Cela inclut l’intégration des traductions, des formats régionaux (date, devise) et des préférences culturelles spécifiques.

Les termes peuvent sembler un peu vagues à première vue et il n’est pas rare de les voir utilisés de manière interchangeable, ce qui peut prêter à confusion.

1. Générer un site par langue

Une approche des plateformes multilingues consiste à générer une application distincte pour chaque langue, permettant par exemple d’héberger un site spécifique à chaque version linguistique, comme fr.monsite.com. Cette méthode, supportée nativement par Angular, repose sur la configuration pour générer des artefacts par langue.

Pour cela, on utilisera la commande suivante pour installer le paquet officiel :

ng add @angular/localize

Configuration

Une fois installé, il y a deux éléments à configurer : premièrement, renseigner à Angular la liste complète des langues à gérer. Dans le fichier angular.json, directement sous le nœud du projet, on ajoutera un objet i18n qui contiendra la langue d’origine, puis les différentes traductions possibles :

"i18n": { ...

Introduction au rendu côté serveur

1. Qu’est-ce que le rendu côté serveur ?

Le rendu coté serveur ou Server-Side-Rendering (SSR) est une technique de rendu d’applications web où le contenu HTML est généré sur le serveur avant d’être envoyé au navigateur du client. Contrairement au rendu côté client, qui est l’approche basique des SPA, où le contenu HTML se construit par le navigateur, le SSR permet de livrer une page entièrement rendue dès la première requête, prête à être affichée par le navigateur.

Il est important de noter que le SSR peut désigner l’approche classique des sites web non SPA, où chaque vue est construite depuis le serveur. Cependant, dans le contexte d’une SPA, le terme SSR est plus spécifique : par défaut, il s’agit de rendre uniquement la première requête depuis le serveur, puis, une fois cette page initiale affichée dans le navigateur, le contrôle est transféré côté client, ne nécessitant plus de requêtes au serveur. Toutefois, nous verrons qu’il y a plusieurs modes de fonctionnement possibles.

Le SSR répond à plusieurs besoins clés dans le développement web moderne, notamment en matière de performances, d’expérience utilisateur et aussi de référencement (les optimisations en vue d’un bon référencement se nomment Search Engine Optimization, ou SEO). Il est particulièrement utile dans les situations suivantes :

Les utilisateurs ont des connexions lentes ou instables, où le chargement initial du JavaScript peut être un obstacle en temps normal.
Les applications nécessitent des optimisations pour les moteurs de recherche, car les contenu CSR (Client Side Rendering) rendent le contenu difficilement accessible aux scanners de sites web (ou crawlers) comme le robot de Google.

Attention, le SSR fonctionne en s’appuyant sur un serveur Node.js pour exécuter l’application et générer dynamiquement le contenu HTML des pages demandées par les utilisateurs. Lorsque le serveur reçoit une requête, il interprète les composants et templates Angular, récupère...

Plus de précisions

1. Configurer le pré-rendu

Lors de l’ajout du package SSR, une modification dont nous n’avons pas encore parlé est automatiquement apportée au fichier angular.json. Il s’agit de la propriété prerender dans les options de builder. Elle est définie à true par défaut, cela signifie que la compilation génère automatiquement les templates pour les pages détectées dans l’application. Ces pages seront alors déjà prêtes sous forme de fichiers statiques HTML, ce qui évite au serveur de devoir les rendre lui-même.

Après la compilation, vous trouverez ces fichiers .html dans le dossier browser/ des artefacts générés. Ces fichiers représentent les routes de votre application déjà pré-rendues, prêtes à être servies directement.

La propriété prerender peut être configurée de plusieurs façons :

avec un booléen, pour activer ou désactiver globalement le pré-rendu ;
avec un objet, pour définir manuellement des routes spécifiques à pré-rendre. Par exemple, il est possible de spécifier un fichier texte contenant la liste des routes à traiter ou de laisser la détection automatique des routes.

Voici un exemple de configuration :

"prerender": { 
  "discoverRoutes": false, 
  "routesFile": "prerendered-routes.txt" 
},

dont le contenu de prerendered-routes.txt est :

/home

Lors de la compilation, Angular lira ce fichier pour identifier les routes à pré-rendre. Si une route correspond à un composant de votre application, elle sera pré-rendue en un fichier HTML. Par exemple, ici, seul le composant HomeComponent sera rendu statiquement. Cette approche fonctionne également pour des pages dynamiques avec des paramètres...

Points avancés du rendu côté serveur

1. Définition du serveur Node.js

Le fichier server.ts est le cœur de la configuration du Server-Side Rendering. Il utilise un serveur Express pour gérer les requêtes entrantes, servir les fichiers statiques et retourner les pages Angular calculées côté serveur en utilisant le moteur de rendu d’Angular.

Pour bien comprendre les détails du fichier server.ts et être capable de configurer plus finement le SSR, il est recommandé d’avoir des notions en Node.js ou, plus généralement, en développement back-end.

Regardons de plus près ce qui a été généré dans ce fichier : il commence par importer les modules nécessaires, comme Express, path et les outils spécifiques au SSR fourni par Angular, tels que CommonEngine. Le dossier de distribution côté serveur est déterminé via serverDistFolder et le dossier des fichiers statiques générés pour le client est défini par browserDistFolder. Ces chemins permettent de localiser les ressources nécessaires à la fois pour le SSR (HTML, fichiers JavaScript) et pour les fichiers statiques (CSS, images).

L’application Express est initialisée avec express(). Les fichiers statiques (par exemple, CSS, JS, images) générés par Angular sont servis à partir du dossier browserDistFolder à l’aide de la méthode express.static. Ces fichiers sont mis en cache pour une durée maximale d’un an (maxAge: ’1y’), ce qui est une bonne pratique pour améliorer les performances sur des ressources immuables.

Les requêtes qui ne correspondent pas à des fichiers statiques sont traitées via une route générique "**". Cette route utilise le moteur de rendu pour générer dynamiquement...

Référencement d’une application

Pour être correctement référencée, une Single Page Application (SPA) doit s’appuyer sur le rendu côté serveur (SSR). En effet, les robots des moteurs de recherche, chargés d’explorer les sites web pour les indexer, n’exécutent pas le JavaScript. Il est donc essentiel que, dès qu’un robot accède à une page de votre site, le contenu et les balises de référencement soient déjà prêts et inclus dans le HTML initial.

1. Balises de référencement

Il est crucial d’ajouter dynamiquement le titre et les métadonnées en utilisant les services Angular Title et Meta. Ces services permettent de définir non seulement les balises essentielles, comme le titre de la page et sa description, mais aussi des balises supplémentaires, telles que celles d’OpenGraph pour les réseaux sociaux ou des instructions spécifiques destinées aux robots d’indexation :

ngOnInit(): void { 
  this.titleService.setTitle('Home'); 
  if (isPlatformServer(this.platformId)) { 
    this.metaService.addTags([ 
      { name: 'name', content: 'Home' }, 
      { name: 'description'...

Angular Material

Angular Material est une bibliothèque de composants d’interfaces utilisateur basée sur les principes de Material Design de Google accessible à cette URL : https://material.angular.io/. Elle propose un ensemble complet de composants prêts à l’emploi, conçus pour être utilisés de manière intuitive dans les applications Angular. En plus de garantir une expérience utilisateur cohérente et moderne, Angular Material intègre nativement des fonctionnalités avancées comme l’accessibilité, la responsivité et la personnalisation des thèmes.

On ne se limite pas à une bibliothèque de composants visuels ; la bibliothèque contient aussi un kit de développement de composants dit : CDK (Component Development Kit). Le CDK est une collection d’outils et de primitives conçus pour aider les développeurs à créer leurs propres composants UI personnalisés.

Contrairement aux composants prêts à l’emploi, le CDK se concentre sur les fonctionnalités et comportements sous-jacents, comme la gestion des overlays, les listes virtuelles, l’accessibilité (ARIA) ainsi que les comportements de drag-and-drop et beaucoup d’autres.

Cette bibliothèque est idéale pour accélérer le développement d’applications Angular, notamment grâce à ses composants réutilisables et bien intégrés, comme les boutons, les formulaires, les barres de navigation, et bien d’autres. Angular Material permet également de maintenir un design uniforme dans toute l’application, tout en offrant une grande flexibilité grâce à des options de personnalisation des thèmes et des couleurs.

Pour la suite, nous utiliserons SASS (Syntactically Awesome Stylesheets), un langage de styles qui, après “compilation”, est transformé en CSS. On peut le considérer comme l’équivalent de TypeScript pour le CSS, car il étend les fonctionnalités du CSS avec des outils puissants comme les variables, les mixins et l’imbrication de règles. Il existe deux syntaxes principales pour SASS : les fichiers .sass et .scss. Dans les projets Angular, nous utiliserons la syntaxe SCSS...

Configuration avancée d’un projet

1. Angular Schematics

Les schémas/plans de construction sont des outils puissants qui permettent d’automatiser et de personnaliser des tâches dans un projet Angular. Ils constituent une partie intégrante de l’Angular CLI et sont utilisés pour générer des composants, des services ou encore configurer des applications. En allant au-delà des fonctionnalités prédéfinies, les développeurs peuvent créer leurs propres schematics pour répondre à des besoins spécifiques ou automatiser des flux de travail complexes.

Un schéma est essentiellement un ensemble de règles définies dans des fichiers TypeScript. Ces règles indiquent les transformations à appliquer sur un projet, voici la structure :

un fichier collection.json qui définit les schémas disponibles et leurs options ;
un ensemble de fichiers TypeScript, selon les besoins, pour implémenter la logique des transformations ;
des templates qui serviront à la génération du ou des fichiers de sortie.

a. Création d’un schéma

Les schémas (schematics) sont des projets à part entière ayant pour but d’être compilés, puis ajoutés à un projet ou même publiés sur npm.

Commencez par installer le kit de développement des schematics, puis créez le projet avec les commandes suivantes :

npm install -g @angular-devkit/schematics-cli 
schematics blank my-schematic

On se retrouve alors avec l’arborescence suivante : un fichier collection.json qui est la cartographie du projet ainsi que l’index.ts, le fichier principal pour accueillir la logique.

Le premier, collection.json, est composé de métadonnées. Par exemple, pour chaque schéma que l’on crée, on pourra définir une description, une factory (qui est le chemin vers la méthode à exécuter) puis une propriété schema, que nous verrons plus tard.

{ 
  "$schema": "../node_modules/@angular- 
devkit/schematics/collection-schema.json", 
  "schematics": { 
    "my-schematic": { 
      "description":...

Conclusion

Ce chapitre a permis d’explorer des concepts avancés qui vont bien au-delà des bases du développement Angular. Nous avons vu comment enrichir vos applications pour répondre à des besoins complexes, comme le multilinguisme, le rendu côté serveur, ou encore l’amélioration du référencement. Ces techniques ouvrent la voie à des applications plus performantes, accessibles et adaptées à des contextes d’utilisation variés, tout en offrant une meilleure expérience utilisateur.

La deuxième partie du chapitre s’est focalisée sur des outils puissants comme Angular Material et le CDK (Component Development Kit), qui permettent de construire des interfaces utilisateur modernes et personnalisées, tout en respectant les principes d’accessibilité. Ces outils sont complétés par des pratiques avancées, telles que la création de bibliothèques et de workspaces, ou encore l’automatisation grâce aux schematics Angular, qui facilitent la maintenance et l’évolution des projets en simplifiant les tâches répétitives.

En maîtrisant ces concepts, vous avez désormais toutes les clés en main pour développer des projets Angular robustes et évolutifs. Que ce soit pour optimiser vos processus de développement ou pour...

Pour aller plus loin