POO, design patterns et frameworks

Vous allez créer des créatures avec leur propre énergie, puis faire évoluer une application de réservation d’ateliers. Ces cas pratiques permettent de découvrir les classes, l’encapsulation, les interfaces et la collaboration entre objets, puis les design patterns et les frameworks.

Les exemples utilisent TypeScript. Pour démarrer, il suffit de savoir écrire des fonctions et manipuler des objets et des tableaux.

La POO dans le code web

Si vous écrivez du JavaScript pour le navigateur, vous utilisez déjà des objets, même sans les nommer ainsi. Un bouton de la page est une instance de HTMLButtonElement, une classe qui hérite de HTMLElement, puis de Element, Node et EventTarget. La méthode addEventListener vient de cette dernière classe et applique le pattern Observer, que le cours étudie. Angular, NestJS et Lit écrivent aussi leurs composants et leurs services en classes, comme Laravel et Symfony en PHP. La POO sert donc dans le développement web, et pas seulement en Java ou dans les applications de bureau.

Contrairement à Java, TypeScript n’oblige pourtant pas à tout écrire en classes. Un module, un objet écrit avec des accolades ou une fonction suffisent souvent, et React, Vue ou Svelte décrivent leurs composants avec des fonctions ou des fichiers compilés. Le cours retient donc les idées de la POO qui servent dans les deux styles : protéger les règles d’un objet, faire dépendre le code d’un contrat, et assembler des objets qui collaborent au lieu de construire de longues chaînes d’héritage. Chaque séance de pattern montre d’abord une version en classes, puis la même idée écrite avec des fonctions.

Le parcours essentiel

Ce parcours rassemble ce qu’un développeur TypeScript utilise le plus souvent dans un projet web. Suivez-le dans l’ordre, parce que chaque étape reprend le code ou les notions de la précédente.

1. Lancez l’application de réservation et suivez une réservation dans son code avec Démarrer.
2. Lisez les bases de la POO, qui expliquent l’encapsulation, les contrats, le typage structurel et la composition. Les sections sur l’écosystème et sur la classe abstraite peuvent attendre.
3. Pratiquez ces notions en construisant une grenouille et un poisson avec les exercices de créatures.
4. Faites évoluer l’application avec les cinq séances de patterns du tableau suivant. Les mises en situation décrivent les demandes auxquelles elles répondent.
5. Construisez une interface réactive avec la série mini framework. Ses sept chapitres réutilisent Observer et l’injection de dépendances pour expliquer le fonctionnement de React, Vue, Svelte ou Angular.

Chaque séance sur un pattern utilise une copie du programme de départ. Les chapitres du mini framework se suivent et font évoluer les mêmes fichiers.

Les fiches aide-mémoire

Chaque fiche résume un pattern sur une page illustrée, avec son schéma, son code et une question pour vérifier que vous l’avez compris. Ouvrez-la à la fin de la séance, ou relisez-la avant un exercice.

• Strategy range plusieurs façons de faire la même chose derrière un même contrat.
• Observer prévient tous les abonnés quand l’état d’un objet change.
• Adapter et Facade traduisent une interface étrangère ou cachent plusieurs objets derrière une méthode simple.
• Decorator ajoute un comportement autour d’un objet sans changer son contrat.
• Template Method fixe l’ordre des étapes et laisse les sous-classes en remplir certaines, comme le font les frameworks.

Approfondir

Les chapitres suivants restent utiles, mais ils peuvent attendre la fin du parcours. Lisez-les quand un problème précis se présente, ou pour préparer un entretien technique ou un jury, où l’on demande souvent ce vocabulaire et ces diagrammes.

• SOLID détaille cinq principes de conception. Dans un projet web, ce sont surtout S et D qui servent. S demande de séparer le code qui change pour des raisons différentes, comme le calcul d’un tarif et le texte d’une confirmation. D demande que les règles dépendent d’un contrat, puis qu’on leur fournisse le stockage ou le client d’API qui le respecte. Les séances Strategy et Repository appliquent déjà ces deux idées.
• UML apprend à lire et à dessiner un diagramme de classes. Pour suivre le cours, savoir lire une classe et ses relations suffit.
• Factory distingue plusieurs façons de regrouper la création des objets. En TypeScript, une fonction qui renvoie un objet couvre la plupart des besoins.

Le glossaire rassemble le vocabulaire, et la bibliographie commentée classe les lectures par sujet.

Les familles de patterns

Le catalogue Design Patterns, écrit par Gamma, Helm, Johnson et Vlissides, est souvent appelé GoF pour Gang of Four. Il distingue trois familles selon le problème traité. Le schéma suivant situe les patterns de ce catalogue étudiés dans le cours.

flowchart LR
  accTitle: Trois familles de patterns GoF
  accDescr: Les patterns de création organisent la fabrication des objets, comme Factory Method et Abstract Factory. Les patterns structurels organisent leur assemblage, comme Adapter et Decorator. Les patterns comportementaux organisent leurs collaborations, comme Strategy et Observer.
  Creation[Création] --> Fabriques[Factory Method et Abstract Factory]
  Structure[Structure] --> Adapter[Adapter]
  Structure --> Decorator[Decorator]
  Comportement[Comportement] --> Strategy[Strategy]
  Comportement --> Observer[Observer]

« Factory » est un terme général. Une fonction de fabrique simple n’est pas nécessairement un Factory Method. Repository appartient aux patterns d’architecture d’entreprise, hors du catalogue GoF. Patterns.dev présente aussi des organisations propres au Web, comme les modules JavaScript et la séparation entre données et présentation.

Le catalogue GoF décrit 23 patterns orientés objet. Reconnaître ceux du schéma suffit pour commencer. Les fiches de Refactoring.Guru présentent leurs structures classiques et leur pseudo-code, ainsi que les patterns que le cours n’étudie pas.

Repères historiques

Simula a introduit la programmation par objets en 1967, puis Smalltalk l’a diffusée depuis le Xerox PARC dans les années 1970. Un objet regroupe un état et des méthodes. L’encapsulation lui permet de protéger ses règles, et le polymorphisme permet à plusieurs objets de répondre au même appel chacun à sa manière.

Démarrer, lire une application qui fonctionne

Lancez un programme d’inscription à des ateliers, puis suivez une réservation dans son code. Il utilise un tarif unique, garde les données en mémoire et simule les notifications. Vous le ferez évoluer dans les séances suivantes.

Exécuter le point de départ

1. Téléchargez ateliers.ts dans un dossier de travail.
2. Ouvrez un terminal dans ce dossier et assurez-vous que Node.js 24 est installé.
3. Exécutez le fichier.

node ateliers.ts

Le programme affiche exactement les quatre lignes suivantes si ses assertions réussissent.

Vérifications réussies.
Ateliers au catalogue : 2
Réservations actives : 2
Notifications en mémoire : 4

Ces nombres résultent des opérations exécutées par les assertions en fin de fichier. Une assertion compare un résultat à ce qui est attendu. Si elle échoue, le programme s’arrête.

Suivre une réservation dans le code

Le programme repose sur une classe, Inscriptions. Son constructeur reçoit le catalogue des ateliers, et ses champs privés conservent les réservations, les notifications et le prochain identifiant. Le code extérieur passe par ses méthodes publiques. Les assertions lisent l’état avec deux getters, des accesseurs qui exécutent du code lors de la lecture d’une propriété. Ceux du programme renvoient des copies, si bien que modifier les valeurs reçues ne change pas les réservations et les notifications internes.

Repérez d’abord les données à l’aide du tableau suivant, puis lisez les opérations qui les utilisent :

Le tableau ateliers reste partagé entre le programme et l’objet inscriptions. Quand les assertions modifient un prix au catalogue, la classe voit ce nouveau prix pour les réservations suivantes.

Retrouvez l’appel inscriptions.reserver(1, " Lea@example.test "), puis suivez la valeur de l’adresse jusqu’à son enregistrement. Repérez ensuite les lignes qui peuvent modifier une réservation ou une notification. Remarquez que les contrôles provoquant un refus arrivent avant ces modifications.

Trois questions pour suivre le code :

1. Pourquoi une seconde inscription avec LEA@example.test est-elle refusée ?
2. Où trouve-t-on le nombre de places restantes ? Est-ce une donnée mémorisée ou un calcul ?
3. Que devient le montant d’une ancienne réservation quand le prix de l’atelier change ?

Le programme retire les espaces autour de l’adresse et la convertit en minuscules. Cette normalisation lui permet de reconnaître le doublon malgré les différences d’écriture. Le nombre de places disponibles se calcule dans la méthode listerAteliers. Quant au montant, il est enregistré dans la réservation lors de sa création et n’est pas recalculé depuis le catalogue à chaque lecture.

Les règles de réservation

Le programme respecte les règles suivantes, appelées invariants.

• Une réservation refusée n’ajoute ni réservation ni notification.
• Une adresse normalisée ne permet pas de réserver deux fois le même atelier.
• La capacité n’est pas dépassée dans cette simulation séquentielle, où les réservations sont traitées l’une après l’autre.
• Un montant enregistré reste inchangé après une modification du prix au catalogue.
• Une annulation libère une place et produit une notification.
• Les identifiants ne sont pas réutilisés après une annulation.

Les assertions vérifient ces comportements avant et après une refactorisation, c’est-à-dire une réorganisation du code qui conserve son comportement observable.

Le modèle en objets

Le fichier représente le participant par son adresse de courriel. Les ateliers et les réservations sont de simples objets de données, et seule Inscriptions est une classe. Le modèle UML d’ateliers et de réservations montre une autre représentation de ces mêmes notions, avec trois classes.

Introduire une variation

Essayez d’ajouter un tarif avec Strategy, puis relancez node ateliers.ts pour vérifier le résultat. Les mises en situation proposent les évolutions suivantes. Repartez du programme initial pour chaque séance.

Limites de la simulation

Les données restent en mémoire et ne sont pas conservées entre deux exécutions. De même, les notifications sont des chaînes de caractères enregistrées en mémoire pour observer le résultat des opérations. Aucun courriel n’est réellement envoyé.

Les bases de la programmation orientée objet

Dans l’application de réservation, on vérifie qu’il reste une place et que la personne n’est pas déjà inscrite avant d’ajouter son inscription. La programmation orientée objet permet de réunir un état et les opérations qui le consultent ou le modifient. On peut ainsi confier ces règles à un objet, plutôt que demander à chaque code qui l’utilise de les vérifier lui-même. Ce code est son appelant.

On commence avec des créatures qui se présentent, avancent et se reposent, puis on retrouve ces notions dans l’application de réservation d’ateliers. Chaque exemple s’exécute séparément, même lorsque plusieurs blocs reprennent un même nom de classe. Le glossaire rassemble le vocabulaire du cours.

Objets, classes et encapsulation

L’état d’un objet correspond aux valeurs qu’il conserve dans ses propriétés à un moment donné. Ses méthodes sont les opérations que l’on peut lui demander d’exécuter. Une créature peut ainsi conserver son énergie et proposer une méthode pour avancer en utilisant cette énergie.

Une classe décrit comment créer des objets de même structure et les méthodes qu’ils proposent. Chaque objet créé à partir de cette classe est une instance, avec son propre état. La classe n’est donc pas une créature particulière, mais la description qui permet d’en créer plusieurs. JavaScript permet aussi de créer des objets sans classe, notamment avec des accolades, comme on le verra avec les réservations.

Lire une classe pas à pas

Une créature possède un nom et sait se présenter. La classe décrit ces deux éléments. Les appels à new créent les deux créatures, puis les assertions vérifient leur présentation et leur identité.

import assert from "node:assert/strict";

class Creature {
	nom: string;

	constructor(nom: string) {
		this.nom = nom;
	}

	sePresenter(): string {
		return `Je m'appelle ${this.nom}.`;
	}
}

const grenouille = new Creature("René");
const poisson = new Creature("Mina");

assert.equal(grenouille.sePresenter(), "Je m'appelle René.");
assert.equal(poisson.sePresenter(), "Je m'appelle Mina.");
assert.notEqual(grenouille, poisson);

class Creature donne un nom à la classe. À l’intérieur des accolades, nom: string déclare une propriété qui contiendra du texte. Cette annotation indique à TypeScript quel type vérifier avant l’exécution. Elle ne fournit pas de valeur à la propriété. Le constructeur s’en chargera pour chaque objet créé.

L’expression new Creature("René") crée une instance et appelle son constructor, le constructeur. Le paramètre nom reçoit la valeur "René". Dans this.nom = nom, la partie droite désigne ce paramètre, tandis que this.nom désigne la propriété de l’objet en cours de construction. L’affectation conserve donc le nom dans cet objet.

Le second new, avec "Mina", crée un autre objet et appelle à nouveau le constructeur. Chaque instance conserve son propre nom. Changer celui de la grenouille ne changerait donc pas celui du poisson.

sePresenter() est une méthode d’instance. Dans l’appel grenouille.sePresenter(), this désigne grenouille. La méthode lit donc son nom. Dans poisson.sePresenter(), elle lit celui de poisson. L’annotation : string après les parenthèses indique que la méthode renvoie du texte. On peut retrouver cette syntaxe dans la présentation des classes de MDN.

Protéger les règles de l’objet

Dans le premier exemple, l’appelant peut lire ou remplacer le nom. Avec une énergie limitée, autoriser n’importe quelle affectation permettrait de donner une énergie négative à la créature. On va donc modifier son énergie uniquement en avançant ou en se reposant.

Le code appelant passe alors par les opérations publiques de l’objet, sans devoir reproduire ses contrôles ni connaître son organisation interne. Les membres accessibles à l’appelant constituent son interface publique. Le mot « interface » désigne ici ce que l’objet expose, pas encore une déclaration de type TypeScript.

L’encapsulation consiste à contrôler les accès à l’état d’un objet pour préserver ses règles. Ici, une créature commence avec 100 points d’énergie et doit rester entre 0 et 100. Se déplacer lui coûte 10 points, tandis que se reposer lui en rend 20, sans dépasser 100.

flowchart TB
  accTitle: Une classe décrit plusieurs objets avec leur propre état
  accDescr: Creature définit une variable de classe, une variable d'instance et deux méthodes. La grenouille et le poisson ont chacun leur énergie. Après avancer(), la grenouille est à 90. Le poisson reste à 100.
  Classe["Classe Creature<br/>Variable de classe : energieMax = 100<br/>Variable d'instance : #energie<br/>Méthodes : avancer(), seReposer()"]
  Classe -->|new Creature| Grenouille["Objet grenouille<br/>Instance de Creature<br/>Après avancer() : #energie = 90"]
  Classe -->|new Creature| Poisson["Objet poisson<br/>Instance de Creature<br/>#energie = 100"]

Les propriétés propres à chaque objet sont appelées variables d’instance. Les méthodes avancer() et seReposer() agissent sur l’énergie de l’objet qui les reçoit. Dans le schéma, déplacer la grenouille ne consomme donc pas l’énergie du poisson. En revanche, la variable de classe, déclarée static, appartient à Creature et se consulte avec Creature.energieMax. Elle indique une limite commune, pas une réserve d’énergie partagée. Elle est ici readonly, donc TypeScript interdit de lui affecter une autre valeur.

class Creature {
  static readonly energieMax = 100;
  #energie = Creature.energieMax;

  get energie(): number {
    return this.#energie;
  }

  avancer(): boolean {
    if (this.#energie < 10) return false;
    this.#energie -= 10;
    return true;
  }

  seReposer(): void {
    this.#energie = Math.min(Creature.energieMax, this.#energie + 20);
  }
}

const grenouille = new Creature();
grenouille.avancer();
console.log(grenouille.energie); // 90

Le champ #energie est privé. L’appelant ne peut pas le lire ou le modifier directement. Le getter, c’est-à-dire l’accesseur en lecture, permet de consulter sa valeur depuis l’extérieur. La lecture grenouille.energie, sans parenthèses, exécute le corps de cet accesseur et renvoie le nombre conservé dans le champ privé. Elle ne rend pas ce champ modifiable.

Au premier déplacement, le contrôle constate que la créature possède au moins 10 points. La méthode en retire 10 et renvoie true pour signaler la réussite. C’est pourquoi le programme affiche 90. Lorsque l’énergie est insuffisante, la méthode renvoie false avant la soustraction et laisse l’état inchangé. Lors du repos, le choix du minimum entre 100 et l’énergie augmentée empêche de dépasser la limite.

Dans les signatures, boolean annonce une réponse true ou false, tandis que void indique que l’appelant n’attend pas de valeur de retour. Une méthode peut donc modifier l’état sans renvoyer de résultat.

La limite de 0 à 100 est un invariant, c’est-à-dire une règle vraie à la création de l’objet et préservée après ses opérations publiques. avancer() et seReposer() la maintiennent grâce à leurs contrôles. Le code appelant utilise ces méthodes sans reproduire leurs vérifications.

Un setter, ou accesseur en écriture, exécute du code lors de l’affectation d’une propriété et peut contrôler la valeur reçue. S’il acceptait n’importe quel nombre, l’énergie pourrait devenir -50 ou 500. Ici, les méthodes de déplacement et de repos suffisent, sans setter pour choisir directement la nouvelle énergie.

En TypeScript, une propriété ou une méthode est public par défaut, comme nom et sePresenter() dans le premier exemple. Le mot private, dans une déclaration telle que private energie = 100, réserve l’accès au code de cette classe pendant la vérification des types. protected autorise aussi le code des sous-classes, que l’on découvre avec l’héritage.

Les modificateurs TypeScript private et protected disparaissent du JavaScript exécuté. Ils contrôlent les accès pendant la vérification des types. La syntaxe JavaScript #energie contrôle aussi l’accès au champ à l’exécution. Ce champ privé n’est pas une propriété publique nommée energie que l’on pourrait retrouver avec une chaîne de caractères.

De même, readonly est un contrôle TypeScript. Dans static readonly energieMax = 100, il interdit de réaffecter ce membre après son initialisation. Appliqué à une propriété qui contient un objet, il empêche d’y affecter une autre référence, sans interdire les modifications des propriétés de cet objet.

Distinguer deux objets et deux références

L’encapsulation oblige aussi à distinguer l’objet des variables qui le désignent. Deux appels à new Creature("René") créent deux objets, même s’ils contiennent le même nom. À l’inverse, l’affectation b = a ne crée aucun objet. Elle copie une référence, c’est-à-dire une valeur qui permet de retrouver le même objet. a et b deviennent alors deux noms pour cet objet. Une modification autorisée par l’un est donc visible par l’autre.

Le même mécanisme s’applique aux objets écrits avec des accolades. On peut l’observer avec une réservation dont les champs sont des nombres et du texte.

import assert from "node:assert/strict";

const reservation = { id: 1, email: "lea@example.test", montantCentimes: 2000 };
const autreReservation = { id: 1, email: "lea@example.test", montantCentimes: 2000 };
const alias = reservation;

assert.equal(reservation === autreReservation, false);
assert.equal(reservation === alias, true);
alias.montantCentimes = 1500;
assert.equal(reservation.montantCentimes, 1500);

const copie = { ...reservation };
copie.montantCentimes = 1000;
assert.equal(reservation.montantCentimes, 1500);
assert.equal(copie === reservation, false);

const atelier = { titre: "Photo", participants: ["Léa"] };
const copieAtelier = { ...atelier };
copieAtelier.participants.push("Sam");
assert.equal(copieAtelier.participants === atelier.participants, true);
assert.deepEqual(atelier.participants, ["Léa", "Sam"]);

Pour des objets, === compare l’identité, donc le fait de désigner le même objet. Il ne compare pas le contenu des propriétés. La première assertion vaut ainsi false, même si les deux réservations possèdent initialement les mêmes valeurs, y compris le même identifiant. Le champ qui identifie une réservation dans l’application ne détermine pas l’identité de l’objet JavaScript. Après const alias = reservation, modifier alias.montantCentimes modifie au contraire la réservation que les deux variables désignent. L’alias n’en est pas une copie indépendante.

const interdit de réaffecter une variable à une autre valeur. Il n’interdit pas de modifier les propriétés de l’objet qu’elle désigne. C’est pourquoi l’affectation à alias.montantCentimes est possible dans cet exemple.

La syntaxe de décomposition ... crée ici une copie superficielle. { ...reservation } produit un nouvel objet avec les valeurs de ses propriétés. Modifier le nombre copie.montantCentimes laisse donc l’original intact.

Dans atelier, en revanche, la propriété participants contient une référence vers un tableau. La copie conserve cette référence, donc les deux objets partagent le même tableau. Ajouter Sam depuis la copie modifie ce tableau partagé, ce que vérifie la dernière assertion. « Superficielle » signifie que la copie s’arrête au premier niveau de propriétés, sans recopier les objets et les tableaux qu’elles désignent.

Dans la séance Repository, les champs d’une réservation sont tous primitifs, comme les nombres et les chaînes de cet exemple. Une copie superficielle suffit alors à éviter qu’un résultat reçu serve à modifier les enregistrements internes. Si on ajoute un tableau ou un objet imbriqué, il faudra revoir cette garantie.

Modéliser un écosystème

Dans une simulation d’écosystème, chaque créature peut gérer son énergie tandis que le monde gère la météo et les événements. Le monde demande un déplacement, et la créature l’accepte ou le refuse selon son énergie. Un journal affiche ce qui se passe.

Murmur simule des écosystèmes, dont la forêt Plot ci-dessous. On peut s’en inspirer pour imaginer notre mare Pond. Le découpage proposé ici est un exemple pédagogique, sans décrire l’architecture interne de Murmur.

Contrats et polymorphisme

On a décrit ce qu’un déplacement peut faire à l’énergie de la créature et comment l’appelant sait s’il a réussi. Ces précisions forment un contrat. L’appelant peut demander un déplacement, mais celui-ci peut être refusé. En cas de refus, il sait que l’énergie reste inchangée. Un contrat indique donc les opérations disponibles, leurs conditions d’utilisation et les garanties sur leur résultat ou leurs effets.

Une interface TypeScript décrit la partie que le système de types peut vérifier, comme les noms des méthodes et leurs types de retour. Dans l’exemple suivant, on veut décrire un animal qui sait nager. La fonction n’a besoin de connaître ni son espèce ni ses autres capacités. On nomme donc la capacité attendue plutôt qu’une classe particulière. L’interface déclare une méthode sans argument qui renvoie du texte, mais ne fournit pas le code de cette méthode.

TypeScript utilise un typage structurel. Le compilateur compare les membres et leurs types pour vérifier leur compatibilité. Une classe peut donc satisfaire une interface sans déclarer qu’elle l’implémente, c’est-à-dire qu’elle fournit les membres décrits. La documentation TypeScript sur la compatibilité des types détaille cette vérification.

import assert from "node:assert/strict";

interface Nageur {
	nager(): string;
}

class Canard {
	nager(): string {
		return "Le canard nage.";
	}

	voler(): string {
		return "Il vole.";
	}
}

class Poisson {
	nager(): string {
		return "Le poisson nage.";
	}
}

function decrire(animal: Nageur): string {
	return animal.nager();
}

assert.equal(decrire(new Canard()), "Le canard nage.");
assert.equal(decrire(new Poisson()), "Le poisson nage.");

Ni Canard ni Poisson ne mentionnent Nageur. TypeScript accepte pourtant leurs instances, parce que chacune possède une méthode nager() qui renvoie du texte. L’interface exprime ici une capacité commune, pas un ancêtre commun. La section Lire extends, super et implements montre comment déclarer ce lien explicitement.

Le polymorphisme permet à decrire d’appeler la même opération sur des objets de classes différentes. La ligne animal.nager() exécute la méthode du canard ou celle du poisson, selon l’objet reçu. La fonction n’a pas besoin de tester l’espèce pour choisir la bonne méthode. Le canard possède aussi une méthode voler() que cette fonction n’a pas besoin de connaître. Elle utilise seulement la capacité de nage annoncée par son paramètre.

Dans l’application d’ateliers, on retrouvera cette organisation avec les tarifs. Un calcul de réservation pourra demander un montant à une règle de tarification, sans connaître le détail de chaque tarif. Le contrat devra alors préciser davantage qu’un type de retour, notamment l’unité du montant.

Duck typing et typage structurel

Le duck typing, ou typage canard, consiste à utiliser les opérations d’un objet sans exiger une classe précise. L’image du canard donne son nom à cette approche. Si l’objet fournit l’opération attendue, le code l’utilise. Le glossaire Python décrit ce style, également courant en JavaScript.

En JavaScript, cet appel se résout à l’exécution. Il ne nécessite ni interface déclarée ni test de classe. L’objet écrit directement avec des accolades dans le premier appel suffit, parce qu’il fournit la méthode attendue. Le second objet ne la fournit pas, et l’appel échoue.

import assert from "node:assert/strict";

function decrire(animal) {
	return animal.nager();
}

assert.equal(decrire({ nager: () => "Je nage." }), "Je nage.");
assert.throws(() => decrire({ voler: () => "Je vole." }), TypeError);

La première assertion vérifie la phrase renvoyée. La seconde vérifie qu’essayer d’appeler la méthode absente provoque une erreur. Le code ne rejette pas une espèce d’animal, il tente une opération que l’objet ne permet pas d’exécuter.

Le typage structurel de l’exemple TypeScript précédent effectue une vérification avant l’exécution. Le duck typing désigne la manière d’utiliser l’objet, pas une vérification du compilateur. Les deux approches permettent d’utiliser des objets indépendants d’une hiérarchie de classes.

Même lorsque le compilateur accepte le code, la présence de nager() ne prouve pas le respect du contrat comportemental. Une méthode peut renvoyer une chaîne tout en produisant un effet interdit ou en levant une erreur inattendue. Le compilateur contrôle des types, tandis que la description du contrat et les tests précisent le comportement attendu.

Cohésion, couplage et responsabilités

Pour examiner comment les objets travaillent ensemble, on regarde ce qui est regroupé et ce que chaque partie connaît des autres. Un module est une partie du programme qui regroupe du code, par exemple dans un fichier. Sa cohésion est forte lorsque ses éléments contribuent au même rôle. Des calculs de tarifs peuvent ainsi former un ensemble cohérent sans prendre aussi en charge le texte des confirmations.

Le couplage décrit ce qu’un module doit connaître des autres pour fonctionner. Si chaque écran connaît les champs propres à un fournisseur, changer ce fournisseur oblige à modifier plusieurs écrans. On peut limiter cette connaissance en intercalant un contrat adapté aux opérations de réservation, comme dans le schéma suivant.

flowchart LR
  accTitle: Dépendances d'une réservation
  accDescr: L'interface utilise les règles métier. Les règles dépendent d'un contrat de réservations que le stockage implémente.
  UI[Interface] -->|appelle| Metier[Règles métier]
  Metier -->|utilise| Contrat[Contrat des réservations]
  Stockage[Stockage] -.->|implémente| Contrat

L’interface appelle le code qui applique les règles de réservation. Ces règles utilisent un contrat pour demander l’enregistrement ou la lecture des réservations. Le stockage fournit les opérations annoncées par ce contrat. Les règles peuvent ainsi exprimer ce dont elles ont besoin sans connaître le format propre au stockage.

Les flèches représentent ce que chaque partie du code doit connaître pour fonctionner. Les données peuvent circuler dans les deux sens. Avec ce découpage, changer le format du stockage ne demande pas de modifier les écrans ni les règles de réservation.

Les principes SOLID

L’encapsulation explique comment un objet protège son état. Les contrats expliquent comment d’autres codes peuvent l’utiliser. Les principes SOLID prolongent ces questions en examinant les responsabilités, les variations et les dépendances. Le chapitre SOLID les illustre avec des exemples de réservation avant et après modification.

Remplacer sans rompre le contrat

Le polymorphisme suppose que les objets proposés à l’appelant tiennent les promesses sur lesquelles son code s’appuie. Une réservation non annulable ne peut donc pas tenir la promesse d’un type qui garantit l’annulation. Présenter une méthode portant le bon nom ne résout pas cette incompatibilité. Le principe de Liskov explique cette difficulté. L’exemple corrigé de réservation distingue les capacités de consultation et d’annulation, puis vérifie leurs garanties.

Composition et héritage

L’héritage et la composition permettent de partager un comportement ou de le faire varier. Hériter, c’est définir une classe à partir d’une autre en reprenant ses membres. Une CommandePromotionnelle hérite ainsi de Commande et doit en respecter les promesses pour être utilisée à sa place.

Composer, c’est assembler des objets ou des fonctions qui travaillent ensemble. Au lieu d’hériter d’une nouvelle sorte de commande pour chaque promotion, une commande peut recevoir une règle de réduction et lui confier le calcul de la remise. Le traitement de la commande utilise le résultat, tandis que la règle choisie détermine le calcul. Un changement de promotion revient alors à lui fournir une autre règle.

classDiagram
  direction LR
  accTitle: Une commande peut hériter ou utiliser un collaborateur
  accDescr: CommandePromotionnelle hérite de Commande. Une commande connaît une règle de réduction. Le triangle creux indique l'héritage, la flèche simple indique la collaboration.
  Commande <|-- CommandePromotionnelle
  Commande --> Reduction : utilise

On lit « une commande promotionnelle est une commande » et « une commande a une réduction ». Le triangle pointe vers la classe parente, dont la sous-classe reprend le code. La flèche simple représente le collaborateur utilisé, auquel la commande confie une partie du travail. Ces deux liens peuvent coexister. L’héritage lie les classes entre elles, tandis que la collaboration demande au collaborateur de satisfaire le contrat attendu. Partager quelques lignes de code ne suffit donc pas à justifier un héritage.

L’article Héritage vs composition de LeanDeep introduit cette distinction avec des exemples Python. Les formulations « est un » et « a un » aident à distinguer ces deux relations. Le chapitre UML, lire et dessiner un diagramme de classes explique les flèches, les multiplicités et le sens plus précis de la composition en UML.

Dans le code web, l’héritage sert surtout à étendre une classe fournie par la plateforme ou par une bibliothèque. Un élément HTML personnalisé hérite ainsi de HTMLElement, et une erreur propre à l’application peut hériter de Error pour garder sa pile d’appels et se reconnaître avec instanceof. On dépasse rarement ce premier niveau. Pour faire varier un comportement, on fournit plutôt un objet ou une fonction à la classe qui l’utilise, ce qui revient à composer.

Le chapitre Strategy utilise cette composition pour changer une règle de calcul. Réorganiser le code en conservant son comportement est un refactoring. Les principes DRY, KISS et YAGNI aident à limiter les répétitions et la complexité.

Lire extends, super et implements

Le code suivant reprend les créatures pour distinguer deux relations. Presentable décrit une opération que l’appelant veut utiliser. Creature fournit le code de cette opération, puis Grenouille hérite de ce code et le complète. Satisfaire le contrat et hériter d’une classe sont donc deux décisions distinctes.

import assert from "node:assert/strict";

interface Presentable {
	sePresenter(): string;
}

class Creature implements Presentable {
	protected nom: string;

	constructor(nom: string) {
		this.nom = nom;
	}

	sePresenter(): string {
		return `Je m'appelle ${this.nom}.`;
	}
}

class Grenouille extends Creature {
	constructor(nom: string) {
		super(nom);
	}

	override sePresenter(): string {
		return `${super.sePresenter()} Je vis près de la mare.`;
	}
}

const grenouille = new Grenouille("René");
const presentation: Presentable = grenouille;
assert.equal(presentation.sePresenter(), "Je m'appelle René. Je vis près de la mare.");

extends Creature fait de Grenouille une sous-classe de Creature. Dans son constructeur, super(nom) appelle le constructeur parent, qui initialise le nom. Dans un constructeur de sous-classe, cet appel doit avoir lieu avant d’utiliser this. La propriété nom est ici protected, donc la classe parente et ses sous-classes peuvent l’utiliser dans le code TypeScript.

La méthode sePresenter() existe déjà dans la classe parente. La sous-classe la redéfinit pour compléter la présentation. super.sePresenter() exécute la version parente sur la même grenouille, puis la méthode ajoute une phrase. Cet appel ne crée pas une seconde créature. Le mot TypeScript override permet au compilateur de vérifier qu’une méthode de ce nom existe bien dans la classe parente.

implements Presentable demande une autre vérification. TypeScript contrôle que Creature fournit l’opération décrite par l’interface, avec les types compatibles. Ce mot n’ajoute donc aucun code à la classe. Avec extends, on hérite du code de la classe parente. Avec implements, on annonce explicitement un contrat de types que son propre code doit satisfaire. La documentation des classes TypeScript précise cette distinction.

L’affectation à presentation permet ensuite d’utiliser la grenouille à travers ce contrat. Elle ne crée pas un nouvel objet et ne retire pas les capacités de la grenouille. Elle indique quelles opérations le code peut utiliser à travers cette variable. L’appel final exécute donc toujours la méthode redéfinie par la grenouille.

Le typage structurel accepte aussi un objet qui possède une méthode sePresenter(): string, sans écrire implements Presentable. Le principe de Liskov complète cette compatibilité des types par le respect du comportement attendu.

Comparer une interface et une classe abstraite

Une interface décrit les membres attendus, sans fournir leur code. Une classe abstraite peut aussi conserver un état et fournir des méthodes communes, tout en laissant certaines méthodes à écrire dans les sous-classes. Elle associe donc du code partagé à des opérations encore incomplètes.

Dans l’exemple suivant, le poisson hérite d’une façon de conserver son nom et de se présenter, mais fournit sa propre façon de nager. L’observateur demande seulement la capacité de nage, ce qui lui permet aussi d’accepter un robot indépendant de cette hiérarchie.

import assert from "node:assert/strict";

interface Nageur {
	nager(): string;
}

abstract class CreatureAquatique implements Nageur {
	protected nom: string;

	constructor(nom: string) {
		this.nom = nom;
	}

	sePresenter(): string {
		return `Je m'appelle ${this.nom}.`;
	}

	abstract nager(): string;
}

class Poisson extends CreatureAquatique {
	nager(): string {
		return `${this.nom} nage sous l'eau.`;
	}
}

class Robot {
	nager(): string {
		return "Le robot avance à la surface.";
	}
}

function observerNage(nageur: Nageur): string {
	return nageur.nager();
}

const poisson = new Poisson("Mina");
assert.equal(poisson.sePresenter(), "Je m'appelle Mina.");
assert.equal(observerNage(poisson), "Mina nage sous l'eau.");
assert.equal(observerNage(new Robot()), "Le robot avance à la surface.");

abstract class CreatureAquatique fournit le constructeur, le champ et la présentation. La déclaration abstract nager(): string annonce une méthode sans corps. Puisque cette classe est abstraite, TypeScript interdit de créer directement une de ses instances. Une sous-classe concrète telle que Poisson doit fournir le code manquant avant de pouvoir être instanciée.

Poisson hérite ici de la présentation sans la réécrire. Comme Poisson ne déclare pas de constructeur, son constructeur par défaut transmet le nom au constructeur de CreatureAquatique. À l’inverse, Robot n’hérite d’aucune de ces classes et ne déclare pas implements Nageur. Ses instances satisfont pourtant l’interface Nageur, donc observerNage les accepte.

Une interface décrit la capacité dont l’appelant a besoin. Une classe abstraite partage aussi un état et du code entre ses sous-classes. Ici, les créatures aquatiques partagent leur nom et leur présentation, tandis que l’interface Nageur permet d’observer aussi le robot.

Pour pratiquer, créez vos créatures en trois étapes.

Mise en situation

L’application de réservation permet de consulter les ateliers, de réserver une place et d’annuler une inscription. Voici trois évolutions à essayer.

Situation 1, des tarifs qui varient

Ajoutez un tarif solidaire qui réduit le prix de moitié, arrondi au centime le plus proche. Pour un prix de 2 001 centimes, la réservation doit enregistrer 1 001 centimes. Son montant reste ensuite inchangé, même si le prix du catalogue évolue.

La séance Strategy montre comment ajouter ce tarif à reserver, d’abord avec une condition, puis avec un objet qui calcule le montant. La séance Factory regroupe le choix du tarif quand plusieurs endroits en ont besoin.

Situation 2, une API externe et un enregistrement qui échoue

Un partenaire fournit les places disponibles dans un champ remaining_seats. Branchez cette information sur la liste des ateliers avec Adapter. Une réponse invalide ou une panne doit être signalée, sans être confondue avec un atelier complet.

On souhaite aussi conserver les réservations après un redémarrage. La séance Repository prépare les échanges avec le stockage et simule un échec d’écriture. La confirmation ne doit être envoyée qu’après un enregistrement réussi. Le stockage durable reste à ajouter.

Situation 3, plusieurs réactions puis une interface

Après une réservation confirmée, l’application ajoute une entrée dans un journal, envoie un courriel et actualise les places disponibles. L’échec du courriel laisse la réservation confirmée. Quand la vue est retirée, elle ne reçoit plus les changements suivants.

Avec Observer, abonnez la vue et le courriel aux réservations, puis essayez de retirer la vue et de faire échouer le courriel. La série sur les frameworks reprend ces mécanismes dans une interface. Pour ajouter une trace autour d’un appel, voyez aussi Decorator.

Représenter les succès et les échecs séparément

Cette séquence montre l’ordre des appels. L’enregistrement et l’envoi du courriel ont chacun leur résultat.

sequenceDiagram
  accTitle: Une sauvegarde réussie reste distincte de l'envoi du courriel
  accDescr: L'interface demande une réservation. Si le stockage refuse l'enregistrement, le service ne demande aucun courriel et signale l'échec. Après une sauvegarde confirmée, le service demande le courriel. Son échec laisse la réservation confirmée et produit une indication séparée.
  participant UI as Interface
  participant Reservation as Service de réservation
  participant Stockage
  participant Courriel
  UI->>Reservation: réserver une place
  Reservation->>Stockage: enregistrer la réservation
  alt Enregistrement refusé
    Stockage-->>Reservation: refus
    Reservation-->>UI: réservation non confirmée
    Note over Reservation,Courriel: Aucun courriel demandé
  else Sauvegarde confirmée par le stockage
    Stockage-->>Reservation: réservation enregistrée
    Reservation->>Courriel: envoyer la confirmation
    alt Envoi accepté
      Courriel-->>Reservation: accepté
      Reservation-->>UI: réservation confirmée, envoi accepté
    else Échec de l'envoi
      Courriel-->>Reservation: erreur
      Reservation-->>UI: réservation confirmée, courriel en échec
    end
  end

Exporter les réservations

Ajoutez une fonction qui exporte les réservations actives avec leurs champs id, atelierId, email et montantCentimes. Essayez-la après quelques inscriptions et une annulation. L’export ne modifie aucun enregistrement et n’émet aucune notification.

Ajouter un tarif avec Strategy

Le programme des ateliers applique le prix du catalogue à chaque réservation. Vous allez y ajouter un tarif solidaire, égal à la moitié du prix normal arrondie au centime le plus proche. Pour un prix de 2 001 centimes, la réservation enregistre donc 1 001 centimes.

Travaillez dans une copie du programme de départ ateliers.ts. Le démarrage de l’atelier explique comment l’exécuter. Les assertions du départ doivent passer après chaque étape.

Le problème

La solution la plus directe ajoute un troisième paramètre à reserver et une condition dans son calcul.

const montantCentimes = tarif === "solidaire"
	? Math.round(atelier.prixCentimes / 2)
	: atelier.prixCentimes;

Elle fonctionne pour deux tarifs. Pourtant, chaque nouveau tarif, étudiant ou groupe, ajoute une branche dans reserver, une méthode qui vérifie déjà l’atelier, le courriel, les doublons et les places. Les règles de prix et les règles d’inscription finissent mélangées au même endroit.

Strategy range chaque façon de calculer dans son propre objet, derrière un contrat commun. reserver reçoit l’un de ces objets et l’utilise sans savoir lequel.

La refacto pas à pas

Étape 1, le contrat

Ajoutez cette interface au-dessus de la classe Inscriptions. Elle décrit ce que tout tarif sait faire : recevoir un prix en centimes et renvoyer un montant en centimes entiers, positif ou nul.

interface Tarif {
	appliquer(prixCentimes: number): number;
}

Étape 2, les classes qui le respectent

Écrivez une classe par tarif, juste sous l’interface. Chacune implémente Tarif avec sa propre règle.

class TarifNormal implements Tarif {
	appliquer(prixCentimes: number): number {
		return prixCentimes;
	}
}

class TarifSolidaire implements Tarif {
	appliquer(prixCentimes: number): number {
		return Math.round(prixCentimes / 2);
	}
}

Étape 3, le code qui utilise le contrat

reserver reçoit maintenant un tarif et lui confie le calcul du montant. Remplacez la méthode reserver par celle-ci. Deux choses changent, le troisième paramètre et le calcul de montantCentimes.

class Inscriptions {
	// Les champs, le constructeur et les autres méthodes ne changent pas.

	reserver(atelierId: number, email: string, tarif: Tarif = new TarifNormal()): Reservation {
		const atelier = this.#ateliers.find(a => a.id === atelierId);
		if (!atelier) throw new Error("Atelier inconnu");
		const adresse = email.trim().toLowerCase();
		if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(adresse)) throw new Error("Courriel invalide");
		if (this.#reservations.some(r => r.atelierId === atelierId && r.email === adresse))
			throw new Error("Déjà inscrit");
		if (this.#reservations.filter(r => r.atelierId === atelierId).length >= atelier.capacite)
			throw new Error("Atelier complet");
		const montantCentimes = tarif.appliquer(atelier.prixCentimes);
		if (!Number.isSafeInteger(montantCentimes) || montantCentimes < 0)
			throw new Error("Montant invalide");
		const reservation = {
			id: this.#prochainId++, atelierId, email: adresse, montantCentimes,
		};
		this.#reservations.push(reservation);
		this.#notifications.push(`Confirmation ${reservation.id} pour ${adresse}`);
		return { ...reservation };
	}
}

La valeur par défaut garde valides les appels à deux arguments du départ. Le contrôle refuse un montant impossible, comme NaN ou une valeur négative, avant d’enregistrer quoi que ce soit.

Étape 4, le branchement

Le code qui appelle reserver choisit le tarif et le lui transmet. Ajoutez ces lignes après les assertions du départ. L’atelier Photo a encore une place à cet endroit.

ateliers[1].prixCentimes = 2001;
const mia = inscriptions.reserver(2, "mia@example.test", new TarifSolidaire());
assert.equal(mia.montantCentimes, 1001);

Fournir ainsi l’objet en paramètre s’appelle une injection de dépendance. Le corrigé ateliers-tarifs.ts contient le programme complet, avec d’autres vérifications.

À vous

Ajoutez un tarif étudiant, égal à 70 % du prix arrondi au centime, sans modifier la classe Inscriptions. new TarifEtudiant().appliquer(2001) doit valoir 1 401.

La même idée avec une fonction

Le contrat Tarif ne contient qu’une méthode, qui reçoit un prix et renvoie un montant. Une fonction fait exactement cela. En TypeScript, un type de fonction peut donc remplacer l’interface, et chaque tarif devient une constante.

type CalculTarif = (prixCentimes: number) => number;

const tarifNormal: CalculTarif = prix => prix;
const tarifSolidaire: CalculTarif = prix => Math.round(prix / 2);

Dans cette version, reserver déclare tarif: CalculTarif = tarifNormal et calcule tarif(atelier.prixCentimes). L’appel devient inscriptions.reserver(2, "mia@example.test", tarifSolidaire). Vous utilisez déjà ce mécanisme pour trier un tableau. Dans [...ateliers].sort((a, b) => a.prixCentimes - b.prixCentimes), sort garde l’algorithme de tri, et la fonction de comparaison décide de l’ordre.

Les classes restent préférables quand une stratégie regroupe plusieurs opérations, par exemple un tarif qui calcule un montant et fournit aussi son libellé. Elles conviennent aussi quand un framework comme Angular ou NestJS crée les objets à partir de classes.

Pour réviser

La fiche Strategy résume le pattern sur un schéma, et la fiche de Refactoring.Guru le présente avec d’autres exemples. Si plusieurs endroits du programme doivent choisir le même tarif, la séance Factory regroupe ce choix.

Lire les places du partenaire avec Adapter

Un partenaire annonce lui aussi les places de nos ateliers, et l’application doit les afficher. Sa réponse utilise son propre vocabulaire, avec un champ remaining_seats, alors que notre code parle de « places ». Cette séance range la traduction entre les deux dans une seule classe. Elle utilise un partenaire simulé, dont vous choisissez les réponses sans contacter de service externe. Travaillez dans une copie d’ateliers.ts et gardez ses assertions de départ.

Le problème

Le partenaire fournit la méthode décrite par cette interface. Ajoutez-la après les types du fichier.

interface Partenaire {
	getAvailability(code: string): Promise<unknown>;
}

Promise indique que la réponse arrive plus tard. Le type unknown oblige à vérifier sa forme avant de la lire, car TypeScript ne contrôle pas le contenu d’une réponse externe pendant l’exécution.

La solution directe ajoute à Inscriptions une méthode qui construit le code atelier-1 attendu par le partenaire, appelle getAvailability, puis vérifie que la réponse contient un remaining_seats entier et positif. La classe des règles de réservation connaît alors le format du partenaire. Une deuxième méthode qui aurait besoin des places répéterait ce travail, et un changement de format chez le partenaire obligerait à modifier Inscriptions.

Adapter place un objet intermédiaire entre notre code et le service. Notre code demande les places avec ses propres mots, et l’adaptateur traduit cette demande dans la langue du partenaire.

La refacto pas à pas

Étape 1, le contrat

Le contrat exprime, avec le vocabulaire de l’application, la seule question qu’elle pose au partenaire, le nombre de places d’un atelier. Ajoutez-le après l’interface Partenaire.

interface Places {
	disponibles(atelierId: number): Promise<number>;
}

Étape 2, la classe qui le respecte

AdaptateurPlaces reçoit le partenaire, construit son code et vérifie sa réponse. Une réponse invalide lance une erreur au lieu de devenir zéro place, car zéro signifierait « atelier complet ». Ajoutez cette classe avant Inscriptions.

class AdaptateurPlaces implements Places {
	#api: Partenaire;

	constructor(api: Partenaire) {
		this.#api = api;
	}

	async disponibles(atelierId: number): Promise<number> {
		const data = await this.#api.getAvailability(`atelier-${atelierId}`);
		if (typeof data !== "object" || data === null ||
			!("remaining_seats" in data)) throw new Error("Format invalide");
		const places = data.remaining_seats;
		if (typeof places !== "number" || !Number.isSafeInteger(places) || places < 0)
			throw new Error("Places invalides");
		return places;
	}
}

Étape 3, le code qui utilise le contrat

Ajoutez cette méthode à Inscriptions. Elle demande les places à travers Places, sans connaître remaining_seats ni le code atelier-1.

class Inscriptions {
	// Les champs, le constructeur et les méthodes du départ ne changent pas.

	async listerAteliersPartenaire(places: Places) {
		return Promise.all(this.#ateliers.map(async atelier => ({
			...atelier,
			places: await places.disponibles(atelier.id),
		})));
	}
}

Promise.all attend toutes les réponses, et la liste échoue dès qu’une réponse échoue. N’ajoutez pas de catch qui renverrait un tableau vide, sinon l’appelant confondrait une panne avec une liste sans atelier.

Étape 4, le branchement

Le partenaire se choisit hors de Inscriptions, au moment où l’on crée l’adaptateur. Ajoutez ce bloc à la fin du fichier. Il crée un partenaire simulé, qui renvoie la réponse prévue pour chaque code, le branche, puis vérifie la liste et le refus des réponses invalides. await attend la réponse, et assert.rejects vérifie qu’une promesse échoue.

class PartenaireSimule implements Partenaire {
	#reponses: Record<string, unknown>;

	constructor(reponses: Record<string, unknown>) {
		this.#reponses = reponses;
	}

	async getAvailability(code: string): Promise<unknown> {
		return this.#reponses[code];
	}
}

const partenaire = new PartenaireSimule({
	"atelier-1": { remaining_seats: 3 },
	"atelier-2": { remaining_seats: 0 },
});
const places = new AdaptateurPlaces(partenaire);
const liste = await inscriptions.listerAteliersPartenaire(places);
assert.deepEqual(liste.map(a => a.places), [3, 0]);

for (const reponse of [null, {}, { remaining_seats: "3" }, { remaining_seats: -1 }, { remaining_seats: 1.5 }]) {
	const invalide = new AdaptateurPlaces(new PartenaireSimule({ "atelier-1": reponse }));
	await assert.rejects(() => invalide.disponibles(1));
}

Pour brancher le vrai service, seule la création de l’adaptateur changera. La liste annonce trois places pour Dessin alors que notre catalogue en prévoit deux, car le partenaire publie ses propres disponibilités sans connaître nos réservations.

À vous

Écrivez une classe PartenaireEnPanne dont getAvailability lance l’erreur « Partenaire indisponible ». Ces lignes doivent alors passer, ce qui montre qu’une panne reste visible.

const enPanne = new AdaptateurPlaces(new PartenaireEnPanne());
await assert.rejects(() => inscriptions.listerAteliersPartenaire(enPanne), /Partenaire indisponible/);

La même idée avec une fonction

Places ne contient qu’une méthode, donc un type de fonction peut le remplacer. placesDuPartenaire reçoit le partenaire et renvoie l’adaptateur. La fonction renvoyée garde accès à api après l’appel, grâce à une fermeture.

type Places = (atelierId: number) => Promise<number>;

function placesDuPartenaire(api: Partenaire): Places {
	return async atelierId => {
		const data = await api.getAvailability(`atelier-${atelierId}`);
		if (typeof data !== "object" || data === null ||
			!("remaining_seats" in data)) throw new Error("Format invalide");
		const places = data.remaining_seats;
		if (typeof places !== "number" || !Number.isSafeInteger(places) || places < 0)
			throw new Error("Places invalides");
		return places;
	};
}

Les appels places.disponibles(atelier.id) deviennent places(atelier.id), et chaque new AdaptateurPlaces(...) devient placesDuPartenaire(...). Vous écrirez cette traduction dans presque tous les projets qui appellent une API. Après un fetch, une fonction vérifie le JSON et renvoie un objet qui porte les noms de l’application. La classe redevient utile quand l’adaptateur expose plusieurs méthodes qui partagent le même client, par exemple pour lire les places, réserver et annuler avec le même jeton d’accès.

Pour réviser

La fiche Adapter et Facade résume le pattern sur un schéma, et la fiche Adapter de Refactoring.Guru le reprend avec d’autres exemples. La séance Repository traite le besoin suivant, conserver les réservations après un redémarrage.

Tracer une réservation avec Decorator

Après une réservation réussie, on veut garder une trace de son enregistrement, sans changer le résultat renvoyé à l’appelant. Travaillez dans une copie d’ateliers.ts.

Le problème

La solution directe écrit la trace dans reserver, ou bien après chaque appel.

const mia = inscriptions.reserver(2, "mia@example.test");
traces.push(`Réservation ${mia.id} enregistrée`);

Dans reserver, la trace s’ajoute aux règles d’inscription, et chaque besoin technique suivant, comme mesurer une durée ou réessayer après une panne, grossira encore la méthode. Après chaque appel, la même ligne se répète partout, et un oubli passe inaperçu.

Decorator place une enveloppe autour de l’objet. Cette enveloppe respecte le même contrat que lui, transmet chaque appel et ajoute son comportement autour. L’appelant l’utilise comme l’objet d’origine, sans voir la différence.

La refacto pas à pas

Étape 1, le contrat

Ajoutez cette interface au-dessus de la classe Inscriptions. Elle décrit la seule opération que l’enveloppe expose. Inscriptions la respecte déjà, puisque sa méthode reserver a la même signature, et TypeScript l’accepte sans implements.

interface ServiceReservation {
	reserver(atelierId: number, email: string): Reservation;
}

Étape 2, l’enveloppe

L’enveloppe garde le service reçu dans son constructeur. Elle lui transmet les mêmes arguments, ajoute la trace seulement après un succès et renvoie le même résultat. Ajoutez-la sous l’interface.

class ReservationTracee implements ServiceReservation {
	#service: ServiceReservation;
	readonly traces: string[] = [];

	constructor(service: ServiceReservation) {
		this.#service = service;
	}

	reserver(atelierId: number, email: string): Reservation {
		const reservation = this.#service.reserver(atelierId, email);
		this.traces.push(`Réservation ${reservation.id} enregistrée`);
		return reservation;
	}
}

Étape 3, le code qui utilise le contrat

Cette fonction représente le formulaire d’inscription. Elle dépend du contrat, et non d’une classe, donc elle accepte aussi bien inscriptions que sa version tracée. Ajoutez-la sous l’enveloppe.

function envoyerFormulaire(service: ServiceReservation, atelierId: number, email: string): string {
	const reservation = service.reserver(atelierId, email);
	return `Réservation ${reservation.id} confirmée`;
}

Vérifiez qu’elle fonctionne déjà avec inscriptions, en ajoutant cette ligne après les assertions du départ. L’atelier Dessin est complet à cet endroit.

assert.throws(() => envoyerFormulaire(inscriptions, 1, "noe@example.test"), /Atelier complet/);

Étape 4, le branchement

Le code qui assemble l’application place l’enveloppe autour de inscriptions, puis la donne au formulaire. Ajoutez ce scénario à la suite. Les identifiants 1 à 3 sont déjà pris, et l’atelier Photo a encore une place.

const tracee = new ReservationTracee(inscriptions);
assert.equal(envoyerFormulaire(tracee, 2, "mia@example.test"), "Réservation 4 confirmée");
assert.deepEqual(tracee.traces, ["Réservation 4 enregistrée"]);
assert.throws(() => envoyerFormulaire(tracee, 2, "noa@example.test"), /Atelier complet/);
assert.equal(tracee.traces.length, 1);

Le second appel est refusé, et l’enveloppe n’ajoute aucune trace, car l’erreur interrompt sa méthode avant la ligne qui écrit la trace.

À vous

Écrivez une enveloppe ReservationComptee qui compte chaque appel à reserver, réussi ou refusé, puis placez-la autour de tracee. Après l’appel refusé envoyerFormulaire(comptee, 2, "noa@example.test"), comptee.tentatives doit valoir 1, et tracee.traces ne doit toujours contenir qu’une ligne.

La même idée avec une fonction

Une enveloppe peut aussi entourer une fonction. avecTrace reçoit une fonction de réservation et renvoie une nouvelle fonction de même signature, qui appelle la première puis ajoute la trace.

type Reserver = (atelierId: number, email: string) => Reservation;

function avecTrace(reserver: Reserver, traces: string[]): Reserver {
	return (atelierId, email) => {
		const reservation = reserver(atelierId, email);
		traces.push(`Réservation ${reservation.id} enregistrée`);
		return reservation;
	};
}

const traces: string[] = [];
const reserverTracee = avecTrace((id, email) => inscriptions.reserver(id, email), traces);
const mia = reserverTracee(2, "mia@example.test");
assert.deepEqual(traces, [`Réservation ${mia.id} enregistrée`]);

La fonction fléchée (id, email) => inscriptions.reserver(id, email) a son importance. Passée seule, inscriptions.reserver serait appelée sans son objet, this vaudrait alors undefined, et l’appel échouerait avec une TypeError. L’écriture inscriptions.reserver.bind(inscriptions) produit le même résultat que la fonction fléchée.

On retrouve cette enveloppe dans le code web. Une fonction qui entoure fetch pour ajouter un en-tête garde la signature de fetch. Les middlewares de Hono exécutent leur code avant et après await next(), qui appelle la route sans qu’elle le sache. Les décorateurs de TypeScript, écrits @Component dans Angular, portent le même nom mais servent surtout à annoter une classe.

Pour réviser

La fiche Decorator résume le pattern sur un schéma, et la fiche de Refactoring.Guru le présente avec d’autres exemples. Decorator conserve le contrat de l’objet entouré, alors qu’un Adapter traduit un contrat différent.

Préparer la persistance avec Repository

Pour retrouver les réservations après un redémarrage, l’application devra les enregistrer dans un stockage durable, par exemple une base de données. Cette séance prépare ce changement. Elle place les réservations derrière un contrat, puis vérifie les échanges avec un stockage simulé en mémoire. Travaillez dans une copie d’ateliers.ts.

Le problème

Dans le départ, Inscriptions garde elle-même le tableau #reservations et le compteur #prochainId. Les méthodes listerAteliers, reserver et annuler lisent et modifient ce tableau directement. Pour passer à une base de données, il faudrait réécrire chacune d’elles, et les requêtes vers le stockage se mêleraient aux règles de réservation.

Un Repository présente les objets enregistrés comme une collection, derrière un contrat. Le code des règles lit et ajoute des réservations sans savoir où elles sont rangées. Ce pattern vient du catalogue de Martin Fowler, et non du livre du Gang of Four.

La refacto pas à pas

Étape 1, le contrat

Ajoutez ce contrat après le type Reservation.

interface Reservations {
	lister(): Promise<Reservation[]>;
	ajouter(nouvelle: Omit<Reservation, "id">): Promise<Reservation>;
	retirer(id: number): Promise<Reservation>;
}

Les méthodes renvoient des promesses, car un vrai stockage répond plus tard. En cas de panne, la promesse est rejetée et l’appelant reçoit l’erreur quand il attend le résultat. Omit<Reservation, "id"> décrit une réservation sans identifiant, puisque c’est le stockage qui l’attribue.

Étape 2, la classe qui le respecte

ReservationsEnMemoire reprend le tableau et le compteur, qui quittent Inscriptions. Ajoutez-la avant cette classe.

class ReservationsEnMemoire implements Reservations {
	#reservations: Reservation[] = [];
	#prochainId = 1;

	async lister(): Promise<Reservation[]> {
		return this.#reservations.map(r => ({ ...r }));
	}

	async ajouter(nouvelle: Omit<Reservation, "id">): Promise<Reservation> {
		const reservation = { ...nouvelle, id: this.#prochainId++ };
		this.#reservations.push(reservation);
		return { ...reservation };
	}

	async retirer(id: number): Promise<Reservation> {
		const index = this.#reservations.findIndex(r => r.id === id);
		if (index === -1) throw new Error("Réservation inconnue");
		const reservation = this.#reservations[index];
		this.#reservations.splice(index, 1);
		return { ...reservation };
	}
}

La classe renvoie des copies, pour qu’un appelant ne puisse pas modifier une réservation stockée à travers le résultat reçu. La différence entre deux objets et deux références explique cette précaution. Le tableau perd ses données à l’arrêt du programme, donc cette classe sert seulement à vérifier les échanges.

Étape 3, le code qui utilise le contrat

Remplacez la classe Inscriptions par celle-ci. Elle reçoit le stockage dans son constructeur, ses trois méthodes deviennent asynchrones et le getter reservations disparaît. Les assertions de départ ne fonctionnent plus à cette étape, et l’étape 4 les remplace.

class Inscriptions {
	#ateliers: Atelier[];
	#stockage: Reservations;
	#notifications: string[] = [];

	constructor(ateliers: Atelier[], stockage: Reservations) {
		this.#ateliers = ateliers;
		this.#stockage = stockage;
	}

	get notifications(): string[] {
		return [...this.#notifications];
	}

	async listerAteliers() {
		const existantes = await this.#stockage.lister();
		return this.#ateliers.map(atelier => ({
			...atelier,
			places: atelier.capacite - existantes.filter(r => r.atelierId === atelier.id).length,
		}));
	}

	async reserver(atelierId: number, email: string): Promise<Reservation> {
		const atelier = this.#ateliers.find(a => a.id === atelierId);
		if (!atelier) throw new Error("Atelier inconnu");
		const adresse = email.trim().toLowerCase();
		if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(adresse)) throw new Error("Courriel invalide");
		const existantes = await this.#stockage.lister();
		if (existantes.some(r => r.atelierId === atelierId && r.email === adresse))
			throw new Error("Déjà inscrit");
		if (existantes.filter(r => r.atelierId === atelierId).length >= atelier.capacite)
			throw new Error("Atelier complet");
		const reservation = await this.#stockage.ajouter({
			atelierId, email: adresse, montantCentimes: atelier.prixCentimes,
		});
		this.#notifications.push(`Confirmation ${reservation.id} pour ${adresse}`);
		return { ...reservation };
	}

	async annuler(reservationId: number): Promise<void> {
		const reservation = await this.#stockage.retirer(reservationId);
		this.#notifications.push(`Annulation ${reservation.id} pour ${reservation.email}`);
	}
}

La confirmation est ajoutée seulement après await this.#stockage.ajouter(...). Si le stockage refuse l’enregistrement, l’erreur interrompt la méthode avant cette ligne.

Étape 4, le branchement

Le stockage se crée hors de Inscriptions, puis passe à son constructeur. Remplacez tout ce qui suit la déclaration de ateliers par ce scénario, qui attend chaque résultat avec await.

const memoire = new ReservationsEnMemoire();
const inscriptions = new Inscriptions(ateliers, memoire);

await assert.rejects(() => inscriptions.reserver(999, "lea@example.test"), /Atelier inconnu/);
const lea = await inscriptions.reserver(1, " Lea@example.test ");
assert.equal(lea.id, 1);
await assert.rejects(() => inscriptions.reserver(1, "LEA@example.test"), /Déjà inscrit/);
const sam = await inscriptions.reserver(1, "sam@example.test");
await assert.rejects(() => inscriptions.reserver(1, "zoe@example.test"), /Atelier complet/);
assert.deepEqual((await inscriptions.listerAteliers()).map(a => a.places), [0, 1]);

await inscriptions.annuler(lea.id);
await assert.rejects(() => inscriptions.annuler(lea.id), /Réservation inconnue/);
assert.deepEqual((await memoire.lister()).map(r => r.id), [sam.id]);
console.log("Vérifications réussies.");

assert.rejects vérifie qu’une promesse échoue, comme assert.throws le fait pour un appel synchrone. Le jour où un vrai stockage existera, seule la ligne qui crée memoire changera.

À vous

Écrivez une classe StockageRefusant qui implémente Reservations et reçoit memoire dans son constructeur. Sa méthode lister lit les réservations de memoire, ajouter lance l’erreur « Enregistrement refusé » et retirer lance « Retrait refusé ». Ajoutez ensuite ces lignes à la fin du fichier, elles doivent passer.

const enPanne = new Inscriptions(ateliers, new StockageRefusant(memoire));
await assert.rejects(() => enPanne.reserver(2, "mia@example.test"), /Enregistrement refusé/);
assert.deepEqual(enPanne.notifications, []);
assert.equal((await memoire.lister()).length, 1);

Un enregistrement refusé ne produit donc aucune confirmation, et la mémoire garde sa réservation.

La même idée avec une fonction

Le contrat a trois méthodes, il reste donc un objet. Cet objet n’a pourtant pas besoin d’une classe. Une fonction peut le créer avec des accolades et garder le tableau et le compteur dans ses variables locales, que le code extérieur ne peut pas atteindre.

function creerReservationsEnMemoire(): Reservations {
	const reservations: Reservation[] = [];
	let prochainId = 1;
	return {
		async lister() {
			return reservations.map(r => ({ ...r }));
		},
		async ajouter(nouvelle) {
			const reservation = { ...nouvelle, id: prochainId++ };
			reservations.push(reservation);
			return { ...reservation };
		},
		async retirer(id) {
			const index = reservations.findIndex(r => r.id === id);
			if (index === -1) throw new Error("Réservation inconnue");
			const reservation = reservations[index];
			reservations.splice(index, 1);
			return { ...reservation };
		},
	};
}

new ReservationsEnMemoire() devient creerReservationsEnMemoire(), et Inscriptions ne change pas, puisqu’elle dépend seulement du contrat. Dans un serveur Node, on retrouve ce découpage dans le module qui regroupe les requêtes vers la base de données, en SQL, avec Prisma ou avec Drizzle. Les routes appellent lister ou ajouter sans connaître les tables, et les tests leur fournissent une version en mémoire. NestJS écrit plutôt ces objets en classes, parce que son injection de dépendances les crée à partir de leur constructeur.

Pour réviser

Cette séance ne rend pas encore les réservations durables. Pour valider un vrai stockage, enregistrez une réservation, arrêtez le programme, puis retrouvez-la au redémarrage, sans que le compteur réattribue un identifiant déjà utilisé. Un Adapter peut traduire les appels vers le fournisseur de ce stockage. La définition de Martin Fowler tient en une page et complète cette séance.

Faire réagir les vues avec Observer

Après chaque confirmation ou annulation, une vue des places disponibles doit se mettre à jour. Cette vue est la partie de l’interface qui affiche les places restantes. D’autres réactions viendront ensuite, comme l’envoi d’un courriel. Quand l’utilisateur ferme la vue, elle ne doit plus rien recevoir.

Travaillez dans une copie d’ateliers.ts. Dans cette séance, un petit objet simule la vue, sans interface réelle.

Le problème

La solution directe appelle chaque réaction dans reserver, juste après l’enregistrement, puis fait de même dans annuler.

this.#notifications.push(`Confirmation ${reservation.id} pour ${adresse}`);
this.#vue.actualiser(reservation);
this.#courriel.envoyer(reservation);

Inscriptions doit alors connaître chaque réaction et la recevoir dans son constructeur. Ajouter une réaction modifie la classe à plusieurs endroits, et une vue fermée n’a aucun moyen de se retirer.

Avec Observer, Inscriptions garde une liste d’abonnés, appelés observateurs, et les prévient tous après chaque changement. Elle ne connaît d’eux que leur contrat, et chacun peut s’abonner ou se retirer à tout moment.

La refacto pas à pas

Étape 1, le contrat

Ajoutez ce type et cette interface au-dessus de la classe Inscriptions. Un événement décrit un changement qui a déjà eu lieu, et tout observateur sait le recevoir.

type Evenement = { type: "confirmation" | "annulation"; reservation: Reservation };

interface Observateur {
	recevoir(evenement: Evenement): void;
}

Étape 2, les classes qui le respectent

La vue devient un observateur. Pour la simulation, elle note le type de chaque changement reçu. Ajoutez-la sous l’interface.

class VueReservations implements Observateur {
	changements: string[] = [];

	recevoir(evenement: Evenement): void {
		this.changements.push(evenement.type);
	}
}

Étape 3, le code qui utilise le contrat

Dans la classe Inscriptions, ajoutez les lignes marquées +. abonner et desabonner gèrent la liste, #notifier prévient chaque observateur, et reserver comme annuler appellent #notifier après leur travail.

 class Inscriptions {
 	// Les champs, le constructeur et les autres méthodes ne changent pas.
+	#observateurs = new Set<Observateur>();
+
+	abonner(observateur: Observateur): void {
+		this.#observateurs.add(observateur);
+	}
+
+	desabonner(observateur: Observateur): void {
+		this.#observateurs.delete(observateur);
+	}
+
+	#notifier(type: Evenement["type"], reservation: Reservation): void {
+		const evenement = { type, reservation: { ...reservation } };
+		for (const observateur of [...this.#observateurs]) {
+			try {
+				observateur.recevoir(evenement);
+			} catch (erreur) {
+				console.error("Réaction en échec :", erreur);
+			}
+		}
+	}
 
 	reserver(atelierId: number, email: string): Reservation {
 		// Les vérifications et l'enregistrement ne changent pas.
 		this.#notifications.push(`Confirmation ${reservation.id} pour ${adresse}`);
+		this.#notifier("confirmation", reservation);
 		return { ...reservation };
 	}
 
 	annuler(reservationId: number): void {
 		// La recherche et le retrait ne changent pas.
 		this.#notifications.push(`Annulation ${reservation.id} pour ${reservation.email}`);
+		this.#notifier("annulation", reservation);
 	}
 }

La boucle parcourt une copie de la liste, si bien qu’un désabonnement pendant l’envoi ne la perturbe pas. Le try affiche l’erreur d’un observateur sans bloquer les suivants ni annuler la réservation déjà enregistrée.

Étape 4, le branchement

Le code qui crée la vue l’abonne, puis la retire quand la vue se ferme. Ajoutez ce scénario après les assertions du départ. L’atelier Photo a encore une place à cet endroit.

const vue = new VueReservations();
inscriptions.abonner(vue);
const mia = inscriptions.reserver(2, "mia@example.test");
assert.deepEqual(vue.changements, ["confirmation"]);

inscriptions.desabonner(vue);
inscriptions.annuler(mia.id);
assert.deepEqual(vue.changements, ["confirmation"]);
assert.equal(inscriptions.notifications.at(-1), `Annulation ${mia.id} pour mia@example.test`);

Le diagramme suivant montre l’ordre de ces appels. La vue ne reçoit pas l’annulation, car elle s’est désabonnée avant. Supprimer une vue du HTML ne suffirait pas, puisque #observateurs garde une référence vers elle.

sequenceDiagram
  accTitle: La vue reçoit les changements jusqu'à son désabonnement
  accDescr: La vue s'abonne auprès de l'objet inscriptions. Après l'enregistrement de la réservation, le sujet prévient la vue. Après le désabonnement, l'annulation ne la prévient plus.
  participant Vue
  participant Sujet as inscriptions
  Vue->>Sujet: abonner(vue)
  Sujet->>Sujet: reserver() enregistre la réservation
  Sujet->>Vue: recevoir(confirmation)
  Vue->>Sujet: desabonner(vue)
  Sujet->>Sujet: annuler() retire la réservation
  Note over Vue: La vue ne reçoit plus l'annulation

À vous

Ajoutez un observateur CompteurAnnulations qui compte les annulations, sans modifier la classe Inscriptions. Après une réservation puis son annulation, son compteur doit valoir 1.

La même idée avec des fonctions

Dans le code web, un observateur est le plus souvent une simple fonction. L’interface devient alors un type de fonction, et abonner peut renvoyer la fonction qui retire l’abonnement, ce qui remplace desabonner.

type Observateur = (evenement: Evenement) => void;

class Inscriptions {
	// Les autres membres ne changent pas. La méthode desabonner disparaît.

	abonner(observateur: Observateur): () => void {
		this.#observateurs.add(observateur);
		return () => {
			this.#observateurs.delete(observateur);
		};
	}
}

Dans #notifier, l’appel devient observateur(evenement). Le code qui s’abonne garde la fonction de retrait qu’il reçoit.

const changements: string[] = [];
const desabonner = inscriptions.abonner(evenement => changements.push(evenement.type));
const mia = inscriptions.reserver(2, "mia@example.test");
desabonner();
inscriptions.annuler(mia.id);
assert.deepEqual(changements, ["confirmation"]);

Les stores de Svelte, la méthode subscribe de Redux et le store de Frameworks 2 suivent cette forme. Le DOM garde l’autre forme, car removeEventListener doit recevoir la même fonction que addEventListener. On peut aussi transmettre un AbortSignal à addEventListener, puis appeler abort() sur son contrôleur.

Pour réviser

La fiche Observer résume le pattern sur un schéma, et la fiche de Refactoring.Guru le présente avec d’autres exemples. Le chapitre Frameworks 5 rattache la durée d’un abonnement à celle de la vue qui l’a créé.

Frameworks 1, qui appelle le code de l’application

L’application d’ateliers sait déjà réserver une place et refuser une demande invalide. Pour l’utiliser dans un navigateur, il reste à relier ces opérations à une interface. Qui appelle le code de réservation après un clic ? Comment le nombre de places affiché suit-il les réservations ? Que faut-il arrêter lorsqu’une vue disparaît ?

Nous allons construire un petit framework d’environ 130 lignes en sept chapitres. Chaque étape corrige une limite de la précédente à l’aide des patterns du cours. On retrouve ainsi des mécanismes présents dans React, Vue, Svelte ou Angular.

1. Dans ce chapitre, le navigateur déclenche les actions de la personne et une première fonction monter installe l’interface. On introduit ainsi l’inversion de contrôle.
2. Un état observé et un rendu naïf relie les changements de données à l’affichage avec un store fondé sur Observer. La mise à jour par innerHTML révèle ensuite trois limites.
3. Composants, fonctions ou classes sépare les parties de l’interface et compare deux façons de leur donner un cycle de vie, avec les Web Components et un rapprochement avec Template Method.
4. Des signaux qui s’abonnent seuls évite de déclarer chaque abonnement à la main. Le mécanisme observe les données lues pendant un calcul.
5. Monter et nettoyer associe les abonnements à la durée de vie de la vue afin de les retirer au bon moment.
6. Fournir les services sépare les composants du choix des objets qu’ils utilisent grâce à l’injection de dépendances.
7. Comparer avec les frameworks réels situe le DOM virtuel et la compilation par rapport aux mécanismes construits.

Les chapitres font évoluer les mêmes fichiers. Le corrigé final rassemble le framework obtenu à la fin du chapitre 6. Le dossier mini-framework contient aussi l’application complète et ses vérifications.

Ce que dit la définition

En 1988, Ralph Johnson et Brian Foote décrivent les frameworks orientés objet dans l’article Designing Reusable Classes, publié dans le Journal of Object-Oriented Programming. Ralph Johnson est aussi l’un des quatre auteurs du catalogue GoF. Voici leur définition, traduite :

Une caractéristique importante d’un framework est que les méthodes définies par l’utilisateur pour l’adapter sont souvent appelées depuis le framework lui-même, et non depuis le code de l’application. Le framework joue souvent le rôle du programme principal : il coordonne et ordonne l’activité de l’application. Cette inversion du contrôle donne aux frameworks le pouvoir de servir de squelettes extensibles.

En 2005, Martin Fowler reprend cette citation dans son article InversionOfControl. Il y écrit que l’inversion de contrôle est ce qui distingue un framework d’une bibliothèque. Il cite aussi son surnom, le « principe d’Hollywood », d’après la phrase qu’on prête aux studios : « Ne nous appelez pas, nous vous appellerons. »

En clair

Une bibliothèque fournit des fonctions que l’application appelle pour effectuer une tâche. Le code de l’application choisit quand demander cette tâche et comment utiliser son résultat. Par exemple, dans inscriptions.reserver(1, "lea@example.test"), il demande une réservation, puis poursuit son traitement. L’exemple est synchrone, et une bibliothèque peut aussi être asynchrone. La différence tient à qui décide du moment de l’appel.

Un framework organise une partie de l’exécution et appelle le code que l’application lui fournit aux moments prévus. Vous écrivez par exemple comment construire une vue, et le framework décide quand appeler cette fonction. L’inversion de contrôle, souvent abrégée IoC, désigne ce changement de responsable. Pour la partie concernée, l’application fournit une réaction au lieu de déclencher elle-même chaque appel. Elle garde toutefois la responsabilité de ses règles et des opérations qu’elle demande depuis cette réaction.

Le repérer dans le code

Suivez l’appel d’une fonction de l’application. Si votre code la transmet au navigateur ou au framework, qui la déclenche ensuite selon son propre cycle, l’appel est inversé. Ce transfert du moment de l’appel caractérise l’inversion de contrôle, même quand l’ordre des instructions reste facile à suivre.

Avant, le terminal pose les questions dans son ordre

Martin Fowler compare deux versions d’un même programme pour montrer qui pilote l’échange. On peut faire cette comparaison avec les ateliers, sans modifier les règles de réservation. Dans une copie d’ateliers.ts, remplacez l’import d’assert par celui de readline. Conservez le catalogue et la création de l’objet d’inscription, puis remplacez les assertions et les console.log de la fin par ces lignes.

import { createInterface } from "node:readline/promises";

// Les types, la classe Inscriptions et le catalogue ne changent pas.

const terminal = createInterface({ input: process.stdin, output: process.stdout });
const email = await terminal.question("Courriel : ");
const atelierId = Number(await terminal.question("Numéro d'atelier : "));
console.log(inscriptions.reserver(atelierId, email));
terminal.close();

Exécutez node ateliers.ts et répondez aux deux questions avec un courriel valide et un identifiant d’atelier. La réservation s’affiche ensuite dans le terminal. Dans cette version, le programme fixe l’ordre de l’échange. Il attend le courriel avant de demander l’atelier, puis attend l’identifiant avant de réserver. La personne ne peut pas inverser ces deux étapes sans que l’on change le programme.

sequenceDiagram
  accTitle: Le programme du terminal pilote l'échange
  accDescr: Le programme pose la question du courriel au terminal et attend la réponse. Il pose ensuite la question de l'atelier, attend la réponse, puis appelle reserver.
  participant Programme
  participant Terminal
  Programme->>Terminal: question("Courriel")
  Terminal-->>Programme: lea@example.test
  Programme->>Terminal: question("Numéro d'atelier")
  Terminal-->>Programme: 1
  Programme->>Programme: inscriptions.reserver(1, email)

Après, le navigateur appelle vos fonctions

Dans le formulaire web que l’on veut construire, les champs et les boutons restent disponibles en même temps. La personne peut saisir son courriel, choisir un atelier, puis revenir corriger l’adresse. Au lieu d’attendre chaque réponse dans une suite d’instructions, l’application enregistre une fonction à appeler lors du clic. Le navigateur la déclenche lorsque cet événement survient.

bouton.addEventListener("click", () => {
  inscriptions.reserver(atelier.id, champ.value);
});

L’appel à addEventListener illustre déjà une inversion de contrôle à petite échelle. La fonction passée en second argument n’est pas exécutée au moment de l’inscription. Le navigateur conserve l’écouteur et l’appelle lorsque le bouton reçoit un clic. L’application n’a donc pas à écrire une boucle qui surveille ce bouton. Le navigateur prend en charge le déclenchement des appels à travers sa boucle d’événements.

sequenceDiagram
  accTitle: Le navigateur pilote l'échange
  accDescr: L'application inscrit sa réaction auprès du navigateur puis rend la main. Quand la personne clique, le navigateur appelle la réaction, qui appelle reserver.
  participant Application
  participant Navigateur
  Application->>Navigateur: addEventListener("click", réaction)
  Note over Navigateur: la personne clique
  Navigateur->>Application: réaction()
  Application->>Application: inscriptions.reserver(1, email)

Notre framework appellera aussi le code de l’application pour construire l’affichage, le mettre à jour et libérer ses ressources. Le retrait d’un élément ne suffit pas à arrêter tout le code qui lui est associé.

Préparer le projet

Le premier programme web réutilise les règles du terminal, mais son point d’entrée sera une page. Comme les navigateurs n’exécutent pas directement TypeScript, Vite transforme les fichiers .ts et fournit un serveur de développement. Créez le projet dans un nouveau dossier de travail :

npm create vite@latest ateliers-ui -- --template vanilla-ts
cd ateliers-ui
npm install

Le modèle vanilla-ts crée une page index.html, qui contient un élément <div id="app"> et charge src/main.ts. Vous remplacerez ce fichier plus bas. Les autres fichiers de démonstration de src/ ne serviront pas, et vous pouvez les supprimer.

Copiez ensuite inscriptions.ts du corrigé dans src/. Il reprend les règles de réservation d’ateliers.ts, sans le catalogue ni les assertions. Il ajoute le type AtelierAvecPlaces, qui décrit un atelier accompagné de son nombre de places libres et que renvoie listerAteliers.

Ce fichier est un module. Le mot export placé devant ses types et sa classe permet aux autres fichiers de les importer. Les champs privés comme #reservations restent en revanche inaccessibles hors de la classe. L’interface passera donc par les méthodes publiques d’Inscriptions, et les règles de capacité et de doublon resteront dans la classe. Le guide des modules de MDN détaille import et export.

Écrire la première fonction du framework

Créez src/framework.ts pour y placer le code qui installe une interface, sans connaître les ateliers ni les réservations. Cette première version ne fait que construire un élément, l’ajouter à la page et fournir une façon de le retirer. Le type HTMLElement désigne l’objet JavaScript qui représente un élément HTML.

export type Composant = () => HTMLElement;

export function monter(racine: HTMLElement, composant: Composant): () => void {
  const element = composant();
  racine.append(element);
  return () => element.remove();
}

Un composant est ici une fonction qui construit un morceau d’interface et renvoie son élément HTML. La fonction monter reçoit cette fonction de construction et la racine, c’est-à-dire l’élément de la page qui accueillera son résultat. Elle appelle le composant, puis insère l’élément obtenu dans la page. Elle renvoie enfin une fonction qui pourra retirer cet élément. Cette fonction prépare le démontage, pour l’instant limité au retrait du DOM, l’arbre d’éléments qui représente la page. Le type de retour () => void indique que l’appel à la fonction de montage fournit une autre fonction, sans argument ni valeur de retour.

En recevant une fonction, monter choisit le moment de construction. Si on lui fournissait seulement un élément déjà construit, le composant se serait exécuté avant l’appel au framework. Dans cette première version, monter l’appelle immédiatement. Au chapitre 5, ce même point d’appel permettra aussi de recueillir les opérations de nettoyage créées pendant la construction.

Remplacez ensuite le contenu de src/main.ts.

import { Inscriptions } from "./inscriptions.ts";
import { monter } from "./framework.ts";

const inscriptions = new Inscriptions([
  { id: 1, titre: "Dessin", capacite: 2, prixCentimes: 2000 },
  { id: 2, titre: "Photo", capacite: 1, prixCentimes: 3000 },
]);

function PageAteliers(): HTMLElement {
  const page = document.createElement("main");
  const champ = document.createElement("input");
  champ.type = "email";
  const etiquette = document.createElement("label");
  etiquette.append("Courriel ", champ);
  const statut = document.createElement("p");
  statut.setAttribute("role", "status");
  const liste = document.createElement("ul");

  for (const atelier of inscriptions.listerAteliers()) {
    const bouton = document.createElement("button");
    bouton.textContent = "Réserver";
    bouton.addEventListener("click", () => {
      try {
        const reservation = inscriptions.reserver(atelier.id, champ.value);
        statut.textContent = `Réservation ${reservation.id} confirmée pour ${reservation.email}`;
      } catch (erreur) {
        statut.textContent = erreur instanceof Error ? erreur.message : String(erreur);
      }
    });
    const ligne = document.createElement("li");
    ligne.append(`${atelier.titre}, places libres : ${atelier.places} `, bouton);
    liste.append(ligne);
  }

  page.append(etiquette, liste, statut);
  return page;
}

monter(document.querySelector<HTMLElement>("#app")!, PageAteliers);

Les imports se terminent par .ts, comme dans le reste du cours. Vite les accepte, et Node.js pourra exécuter les mêmes fichiers dans les tests des chapitres suivants. Le nom PageAteliers commence par une majuscule, une convention des frameworks pour distinguer un composant d’une fonction ordinaire. L’attribut role="status" demande aux lecteurs d’écran d’annoncer les changements du message.

Le try regroupe l’appel à reserver et la préparation du message de confirmation. Si la réservation est refusée, le traitement passe dans le bloc d’erreur et affiche le motif, par exemple « Atelier complet ». La règle de capacité reste dans Inscriptions, tandis que l’interface traduit le résultat en message pour la personne.

Vérifier

Lancez npm run dev, puis ouvrez l’adresse affichée, en général http://localhost:5173. Saisissez lea@example.test et cliquez sur le bouton de l’atelier Dessin. Au premier essai, le message doit confirmer la réservation 1. Cliquez à nouveau avec la même adresse pour observer le refus d’une double inscription. Le message change, mais la réservation précédente reste enregistrée.

Après la première réservation, la ligne affiche pourtant toujours « places libres : 2 ». Le calcul des places est juste. Le décalage vient de PageAteliers, qui a lu les données une seule fois, au montage, puis créé un texte qui ne change plus. La réservation a modifié les données internes, sans déclencher de nouvelle lecture pour l’affichage. Il manque donc un lien entre le changement de données et la mise à jour de la vue. Le chapitre 2 construit ce lien.

Le trajet d’un clic

Le schéma suit un clic sur Réserver jusqu’au nombre de places actualisé. La réservation fonctionne déjà, mais le lien entre l’état et l’affichage reste à construire.

flowchart TB
  accTitle: Du clic au nouvel affichage
  accDescr: Le clic déclenche une action. Les règles de réservation acceptent ou refusent la demande. Le résultat met à jour l'état de l'interface, qui prévient la vue, et la vue actualise le DOM.
  Clic[Clic dans le DOM] --> Action[Action réserver]
  Action --> Regles[Règles de réservation]
  Regles -->|résultat| Etat[État de l'interface]
  Etat -->|notification| Vue[Rendu de la vue]
  Vue -->|actualise| DOM[DOM]

Chaque étape a un rôle distinct dans ce trajet.

Désactiver le bouton d’un atelier complet améliore l’interface, mais la règle de capacité reste dans Inscriptions. Un autre appelant, comme un import de fichier ou une autre page, pourrait demander une réservation sans passer par ce bouton.

Nuance, une frontière qui dépend du point de vue

La limite entre bibliothèque et framework dépend de la partie du programme que l’on observe. React se présente comme une bibliothèque, et votre code l’appelle bien pour démarrer le rendu. Pourtant, son moteur appelle ensuite vos composants pendant les phases de rendu et de commit. Pour cette partie de l’exécution, React se comporte comme un framework, tandis que d’autres choix, comme le routage, restent à votre charge.

L’application garde ses décisions, mais confie certains déclenchements au framework. Suivre l’exécution demande alors de connaître ses points d’appel. Une erreur dans un composant peut apparaître dans une pile qui traverse le framework, et l’ordre des mises à jour ne se déduit plus du seul fichier du composant.

Frameworks 2, un état observé et un rendu naïf

À la fin du chapitre 1, la réservation réussit, mais la page affiche toujours le même nombre de places libres. PageAteliers n’a lu les ateliers qu’au montage. Nous allons ajouter un objet qui conserve l’état de l’interface et prévient les vues à chaque modification, puis remplacer toute la page pour afficher ce nouvel état.

L’état de l’interface

L’état de l’interface regroupe les données dont le code a besoin pour construire l’affichage à un instant donné. Ici, il contient la liste des ateliers avec leurs places libres, le courriel en cours de saisie et le dernier message à afficher. À partir de ces valeurs, une fonction peut déterminer le texte de chaque ligne et si son bouton doit être désactivé.

Cet état ne remplace pas les données conservées par Inscriptions. La classe garde les réservations et vérifie les règles, notamment la capacité de chaque atelier. L’interface en conserve une copie préparée pour l’affichage, avec le nombre de places déjà calculé. Elle y ajoute des informations propres à l’écran, comme le texte du champ. Quand une réservation réussit, l’interface relit les ateliers auprès d’Inscriptions et remplace sa copie. Elle affiche ainsi le résultat des règles au lieu de tenir un second compte des réservations.

Un store est le sujet d’un Observer

Un store est un objet qui conserve l’état de l’application et prévient les vues de ses changements. Le terme vient de l’architecture Flux, présentée par Facebook en 2014, et la bibliothèque Redux l’a diffusé à partir de 2015. Notre exemple en garde seulement le stockage et les notifications.

Le store que l’on va écrire permet de lire l’état, de le remplacer et de s’abonner à ses changements. Il reprend l’organisation de la séance Observer. Le sujet est le store, et ses observateurs sont les fonctions qui mettent la page à jour. Au lieu de transmettre un événement comme « confirmation », chaque notification leur fournit l’état complet. Tous les abonnés le reçoivent, même si seule une donnée qui ne les concerne pas a changé.

Ajoutez ce type et cette fonction à src/framework.ts, sous monter.

export type Store<E> = {
  lire(): E;
  ecrire(suivant: E): void;
  abonner(abonne: (etat: E) => void): () => void;
};

export function creerStore<E>(initial: E): Store<E> {
  let etat = initial;
  const abonnes = new Set<(etat: E) => void>();
  return {
    lire: () => etat,
    ecrire(suivant) {
      etat = suivant;
      for (const abonne of [...abonnes]) abonne(etat);
    },
    abonner(abonne) {
      abonnes.add(abonne);
      return () => {
        abonnes.delete(abonne);
      };
    },
  };
}

Le paramètre de type E représente la forme de l’état, si bien que le framework peut conserver n’importe quelle valeur sans connaître les ateliers. creerStore est une fabrique : les méthodes renvoyées gardent accès aux variables etat et abonnes après la fin de l’appel. Cette fermeture les protège comme des champs privés. En revanche, lire renvoie l’objet lui-même, sans copie. Si un appelant le modifie directement, le store ne prévient personne, donc notre application passe toujours par ecrire.

ecrire parcourt une copie des abonnés, [...abonnes]. Ainsi, une vue abonnée pendant une notification ne reçoit pas cette même notification.

abonner ajoute une fonction à la liste des destinataires, mais ne l’appelle pas immédiatement. Il faut donc lire l’état pour afficher la vue une première fois. La fonction renvoyée par abonner permet ensuite de se désabonner. Le code qui crée la vue doit la conserver pour interrompre les notifications quand cette vue disparaît.

Pour vérifier ce comportement sans navigateur, créez tests/store.test.ts à la racine du projet, à côté de src/.

import assert from "node:assert/strict";
import { creerStore } from "../src/framework.ts";

const store = creerStore({ places: 2 });
const recues: number[] = [];
const desabonner = store.abonner(etat => recues.push(etat.places));

store.ecrire({ places: 1 });
desabonner();
store.ecrire({ places: 0 });

assert.deepEqual(recues, [1]);
assert.equal(store.lire().places, 0);
console.log("Vérifications réussies.");

Exécutez node tests/store.test.ts. Le terminal doit afficher « Vérifications réussies. ». L’abonné a reçu la valeur 1, mais pas la valeur 0 écrite après son désabonnement, que le store conserve bien. Node.js exécute ce test sans navigateur, car framework.ts ne touche à aucun élément de page au chargement.

Redessiner toute la page à chaque changement

Le rendu produit l’affichage à partir de l’état. Une fonction reçoit les données et décrit la page correspondante. Recalculer cette description après chaque écriture dans le store évite de prévoir une modification pour chaque événement possible.

La façon la plus directe d’appliquer cette idée consiste à écrire la page sous forme de texte HTML, puis à le donner à innerHTML. Ajoutez cette fonction au framework.

export function monterGabarit<E>(
  racine: HTMLElement,
  store: Store<E>,
  gabarit: (etat: E) => string,
): () => void {
  const afficher = (etat: E) => {
    racine.innerHTML = gabarit(etat);
  };
  afficher(store.lire());
  return store.abonner(afficher);
}

On appelle ici gabarit une fonction qui reçoit l’état et renvoie le texte HTML correspondant. monterGabarit affiche d’abord l’état actuel, puis abonne sa fonction d’affichage aux écritures suivantes. Votre code fournit le gabarit, mais le framework décide quand l’appeler, selon l’inversion de contrôle du chapitre 1. La fonction renvoyée interrompt cet abonnement. Contrairement au démontage du chapitre 1, elle ne retire pas les éléments déjà affichés.

Remplacez src/main.ts par cette version.

import { Inscriptions, type AtelierAvecPlaces } from "./inscriptions.ts";
import { creerStore, monterGabarit } from "./framework.ts";

const inscriptions = new Inscriptions([
  { id: 1, titre: "Dessin", capacite: 2, prixCentimes: 2000 },
  { id: 2, titre: "Photo", capacite: 1, prixCentimes: 3000 },
]);

type Etat = Readonly<{ ateliers: AtelierAvecPlaces[]; email: string; message: string }>;

const store = creerStore<Etat>({
  ateliers: inscriptions.listerAteliers(),
  email: "",
  message: "",
});

function gabarit(etat: Etat): string {
  const lignes = etat.ateliers.map(atelier => {
    const desactive = etat.email === "" || atelier.places === 0;
    return `<li>${atelier.titre}, places libres : ${atelier.places}
      <button data-atelier="${atelier.id}" ${desactive ? "disabled" : ""}>Réserver</button></li>`;
  });
  return `<main>
    <label>Courriel <input type="email" value="${etat.email}"></label>
    <ul>${lignes.join("")}</ul>
    <p role="status">${etat.message}</p>
  </main>`;
}

function reserver(atelierId: number): void {
  const etat = store.lire();
  try {
    const reservation = inscriptions.reserver(atelierId, etat.email);
    store.ecrire({
      ...etat,
      ateliers: inscriptions.listerAteliers(),
      message: `Réservation ${reservation.id} confirmée pour ${reservation.email}`,
    });
  } catch (erreur) {
    store.ecrire({ ...etat, message: erreur instanceof Error ? erreur.message : String(erreur) });
  }
}

const racine = document.querySelector<HTMLElement>("#app")!;
monterGabarit(racine, store, gabarit);

racine.addEventListener("input", evenement => {
  const champ = evenement.target as HTMLInputElement;
  store.ecrire({ ...store.lire(), email: champ.value });
});

racine.addEventListener("click", evenement => {
  const bouton = (evenement.target as Element).closest<HTMLButtonElement>("button[data-atelier]");
  if (bouton) reserver(Number(bouton.dataset.atelier));
});

Le bouton reste désactivé tant que le courriel est vide ou que l’atelier est complet. Le gabarit a donc besoin du texte saisi pour calculer son état, ce qui explique la présence d’email dans le store. Chaque frappe enregistre la valeur du champ et déclenche un nouveau rendu. Un courriel non vide n’est pas forcément valide. La vérification de sa forme reste dans les règles de réservation.

Avec Readonly, TypeScript interdit de réaffecter les propriétés de l’état. Le code construit donc un nouvel objet avec { ...etat } et le transmet au store. Cette vérification reste superficielle, car le tableau des ateliers peut encore être modifié.

Dans cet exemple, une action est une fonction qui traite une demande et reporte son résultat dans l’état de l’interface. La fonction reserver demande d’abord à la classe de créer la réservation. Si elle réussit, l’action relit les places disponibles, prépare le message de confirmation et écrit l’ensemble en une fois dans le store. Si la classe refuse la demande, l’action conserve les ateliers et le courriel, puis remplace seulement le message. Le rendu reçoit ainsi un état qui correspond au résultat de la demande.

flowchart LR
  accTitle: Le cycle du store
  accDescr: Un clic appelle l'action reserver. L'action appelle les règles d'Inscriptions, puis écrit le nouvel état dans le store. Le store prévient monterGabarit, qui appelle le gabarit et remplace le HTML de la racine.
  Clic[Clic] --> Action[reserver]
  Action --> Regles[Inscriptions]
  Action -->|ecrire| Store[Store]
  Store -->|notifie| Montage[monterGabarit]
  Montage -->|appelle| Gabarit[gabarit]
  Montage -->|innerHTML| Racine[Racine]

Relancez la page. Collez une adresse complète dans le champ, puis réservez l’atelier Dessin. Le nombre de places passe de 2 à 1. La saisie lettre par lettre révèle le premier des trois problèmes du remplacement du HTML.

Premier défaut, le champ perd le focus

Cliquez dans le champ, puis tapez une lettre. Le curseur disparaît du champ après chaque frappe, et il faut cliquer de nouveau pour taper la suivante.

La frappe déclenche l’événement input, qui écrit le courriel dans le store. Le store appelle alors afficher, qui remplace tout le HTML de la racine. Le champ dans lequel vous tapiez est retiré de la page, et un nouveau champ, créé à partir du gabarit, prend sa place. Le texte saisi réapparaît grâce à l’attribut value, mais le focus, qui désigne l’élément recevant la saisie au clavier, reste associé à l’ancien champ jusqu’à son retrait. Le nouveau champ ne le récupère pas. La position du curseur, une sélection de texte ou le défilement d’une liste peuvent aussi être perdus quand leurs éléments sont remplacés.

Deuxième défaut, les écouteurs disparaissent

Un écouteur posé sur un bouton reste attaché à ce bouton quand le rendu le retire. Lisez ce contre-exemple sans l’ajouter à votre fichier, qui traite déjà les clics sur la racine.

for (const bouton of racine.querySelectorAll<HTMLButtonElement>("button[data-atelier]")) {
  bouton.addEventListener("click", () => reserver(Number(bouton.dataset.atelier)));
}

Ces écouteurs ne concernent que les boutons présents au moment de la boucle. Au premier changement d’état, le rendu retire ces boutons et en crée de nouveaux, sans leur associer les mêmes fonctions. Les clics sur les nouveaux boutons ne déclencheraient donc plus de réservation.

Notre main.ts contourne ce problème par la délégation d’événements. Un clic sur un bouton remonte ensuite vers ses ancêtres, jusqu’à la racine : c’est la propagation des événements. Un seul écouteur posé sur la racine reçoit donc les clics de tous les boutons, y compris ceux créés plus tard. closest retrouve le bouton concerné et data-atelier indique l’atelier. React utilise le même procédé : depuis sa version 17, il pose ses écouteurs sur l’élément racine de l’application.

Troisième défaut, le texte saisi devient du HTML

Les deux premiers défauts gênent la personne, tandis que le troisième ouvre une faille de sécurité. Collez cette adresse d’un seul coup dans le champ, puis cliquez sur Réserver :

<img/src/onerror=alert(1)>@a.fr

Une fenêtre alert s’ouvre. L’adresse passe la validation d’Inscriptions, car l’expression régulière vérifie seulement l’absence d’espace et la présence d’un @ et d’un point. Le message de confirmation contient alors cette adresse, et le gabarit l’insère telle quelle dans le HTML. Le navigateur lit <img/src/onerror=alert(1)> comme une balise d’image sans source, déclenche son erreur et exécute le code de l’attribut onerror.

Cette attaque s’appelle une injection de script, ou XSS pour cross-site scripting. L’OWASP la décrit en détail. Ici, la personne s’attaque elle-même, mais le même gabarit afficherait une adresse enregistrée par quelqu’un d’autre, par exemple dans une liste de participants. Le code injecté s’exécuterait alors dans la page de chaque personne qui la consulte. La documentation d’innerHTML rappelle ce risque.

On pourrait échapper les caractères <, >, & et les guillemets pour qu’ils soient affichés au lieu d’être interprétés. Il faudrait alors adapter cette protection à chaque emplacement, notamment le texte du message et la valeur d’un attribut. Un oubli laisserait de nouveau passer du HTML. La propriété textContent répond à un besoin plus précis. Elle affecte du texte à un élément sans le faire analyser comme du HTML. Le chapitre 3 l’utilise pour afficher le message de confirmation. Cette protection de l’affichage est distincte de la validation du courriel.

Nuance, l’idée reste bonne

Décrire la page à partir de l’état rassemble les mises à jour dans le gabarit. Les trois défauts observés viennent du choix d’innerHTML, qui remplace les éléments existants et interprète la chaîne reçue comme du HTML.

On peut conserver cette description à partir de l’état sans remplacer toute la page. React recalcule une description, la compare avec la précédente, puis détermine les modifications à appliquer aux éléments existants. Le DOM virtuel, présenté au chapitre 7, repose sur cette approche. Les chapitres 3 et 4 explorent une autre solution. On crée les éléments au montage, puis on met à jour leur texte ou leurs propriétés sans les remplacer à chaque changement d’état.

Avant de passer au chapitre 3, gardez creerStore dans framework.ts. Vous pouvez supprimer monterGabarit, qui ne servira plus.

Frameworks 3, composants en fonctions ou en classes

Au chapitre 2, chaque écriture dans le store remplaçait toute la page. Ce remplacement faisait perdre le focus au champ et permettait au texte saisi d’être interprété comme du HTML. On va maintenant conserver les éléments pendant les mises à jour et modifier seulement leur contenu ou leurs propriétés.

Chaque ligne d’atelier deviendra un composant chargé de son affichage. On l’écrira comme une fonction, puis comme une classe dont le navigateur appelle les méthodes à l’insertion et au retrait. On pourra ainsi comparer le nettoyage des abonnements et retrouver l’idée des crochets de Template Method.

Un composant regroupe ce qui change ensemble

Un composant regroupe les éléments d’une partie de l’interface et le code qui les fait réagir. Dans notre page, une ligne d’atelier affiche le titre et les places libres, puis propose un bouton de réservation. Le texte dépend de l’atelier, et le bouton dépend aussi du courriel saisi. Réunir ces éléments dans un composant permet de décrire leur création et leurs mises à jour sans répéter ce code pour chaque atelier.

Ce regroupement convient aux éléments qui se répètent ou changent ensemble, comme le texte et le bouton d’une ligne. Si cette partie de la page disparaît seule, le composant permet aussi de rassembler son nettoyage.

Écrire le composant comme une fonction

Dans src/main.ts, conservez le catalogue, le type Etat, le store et l’action reserver du chapitre 2. Gardez les imports, sauf celui de monterGabarit, à remplacer par monter. Supprimez la fonction gabarit, la constante racine, l’appel à monterGabarit et les deux écouteurs posés sur la racine.

Ajoutez ce composant. La page qui l’utilise sera écrite plus bas. Pour l’instant, le fichier ne contient donc plus de code de montage.

function CarteAtelier(atelierId: number): [HTMLElement, () => void] {
  const carte = document.createElement("span");
  const texte = document.createElement("span");
  const bouton = document.createElement("button");
  bouton.textContent = "Réserver";
  bouton.addEventListener("click", () => reserver(atelierId));
  carte.append(texte, " ", bouton);

  const afficher = (etat: Etat) => {
    const atelier = etat.ateliers.find(a => a.id === atelierId)!;
    texte.textContent = `${atelier.titre}, places libres : ${atelier.places}`;
    bouton.disabled = etat.email === "" || atelier.places === 0;
  };
  afficher(store.lire());
  return [carte, store.abonner(afficher)];
}

À chaque appel, la fonction crée un conteneur, un élément pour le texte et un bouton. Elle définit ensuite afficher, qui retrouve l’atelier dans l’état et modifie seulement textContent et disabled. Les notifications suivantes ne remplacent aucun élément. Le bouton garde donc son écouteur de clic, sans qu’une délégation soit nécessaire.

L’affectation à textContent traite le titre et les places comme du texte. On appliquera la même règle au message de confirmation dans la page. Une adresse contenant <img> y restera du texte, au lieu de devenir une balise.

La fonction renvoie un tableau dont les deux positions ont un sens fixe, appelé un tuple. La première contient l’élément à insérer, la seconde la fonction de désabonnement fournie par le store. Le composant donne ainsi à son appelant les moyens de l’afficher et de cesser ses mises à jour.

La fonction ignore à quel moment son élément sera retiré de la page. Son appelant doit donc conserver le nettoyage et l’exécuter au retrait. Sinon, le store continue d’appeler afficher sur des éléments devenus invisibles. Il manque un code chargé de suivre leur durée de vie.

Le navigateur sait quand un élément est retiré

Le navigateur peut prendre en charge ces moments grâce aux éléments personnalisés, une des technologies regroupées sous le nom Web Components. On écrit une classe qui hérite de HTMLElement, puis on l’enregistre sous un nom contenant un tiret, comme carte-atelier. Le navigateur reconnaît alors certaines méthodes de la classe et les appelle pendant le cycle de vie de l’élément, c’est-à-dire lors de sa connexion au document, de son retrait ou d’autres changements.

• connectedCallback() s’exécute quand l’élément est connecté au document, directement ou avec l’un de ses ancêtres.
• disconnectedCallback() s’exécute quand il est déconnecté du document, y compris au retrait de l’un de ses ancêtres.
• attributeChangedCallback() réagit aux changements des attributs que la classe déclare observer. Notre carte n’en utilise pas.

La documentation MDN rappelle les contraintes du constructeur. Il sert à initialiser l’objet, sans supposer que ses attributs et ses enfants sont disponibles. Il ne doit pas ajouter d’enfants à l’élément. On prépare donc son contenu dans connectedCallback, quand le navigateur signale sa connexion au document. Construire un objet et l’insérer dans la page restent deux opérations distinctes.

Remplacez la fonction CarteAtelier par cette classe.

class CarteAtelier extends HTMLElement {
  #atelierId: number;
  #desabonner = () => {};

  constructor(atelierId: number) {
    super();
    this.#atelierId = atelierId;
  }

  connectedCallback(): void {
    const texte = document.createElement("span");
    const bouton = document.createElement("button");
    bouton.textContent = "Réserver";
    bouton.addEventListener("click", () => reserver(this.#atelierId));
    this.replaceChildren(texte, " ", bouton);

    const afficher = (etat: Etat) => {
      const atelier = etat.ateliers.find(a => a.id === this.#atelierId)!;
      texte.textContent = `${atelier.titre}, places libres : ${atelier.places}`;
      bouton.disabled = etat.email === "" || atelier.places === 0;
    };
    afficher(store.lire());
    this.#desabonner = store.abonner(afficher);
  }

  disconnectedCallback(): void {
    this.#desabonner();
  }
}

customElements.define("carte-atelier", CarteAtelier);

Le corps de connectedCallback reprend la création des éléments, le premier affichage et l’abonnement de la fonction. La classe conserve le désabonnement dans un champ privé, puis l’appelle dans disconnectedCallback. Le code qui crée la carte n’a donc plus à garder ce nettoyage. Il lui suffit de retirer l’élément du document pour que le navigateur déclenche disconnectedCallback.

replaceChildren remplace les enfants de la carte au lieu d’en ajouter après les précédents. Lors d’un déplacement classique qui déconnecte puis reconnecte l’élément, le navigateur appelle disconnectedCallback, puis connectedCallback. La carte se désabonne, reconstruit ses enfants et s’abonne de nouveau. Les enfants restent donc stables pendant les changements du store, pas pendant toute la vie de l’objet.

Le champ #desabonner contient d’abord une fonction vide, remplacée à la connexion. disconnectedCallback peut ainsi l’appeler sans tester si un abonnement existe.

Écrivez maintenant la page. Elle reste une fonction, que monter appelle.

function PageAteliers(): HTMLElement {
  const page = document.createElement("main");
  const champ = document.createElement("input");
  champ.type = "email";
  champ.addEventListener("input", () => store.ecrire({ ...store.lire(), email: champ.value }));
  const etiquette = document.createElement("label");
  etiquette.append("Courriel ", champ);

  const liste = document.createElement("ul");
  for (const atelier of store.lire().ateliers) {
    const ligne = document.createElement("li");
    ligne.append(new CarteAtelier(atelier.id));
    liste.append(ligne);
  }

  const statut = document.createElement("p");
  statut.setAttribute("role", "status");
  store.abonner(etat => {
    statut.textContent = etat.message;
  });

  page.append(etiquette, liste, statut);
  return page;
}

monter(document.querySelector<HTMLElement>("#app")!, PageAteliers);

Le champ est créé au montage et n’est pas remplacé pendant la saisie. Ses événements écrivent toujours le courriel dans le store, mais les abonnés ne reconstruisent plus la page. Chaque CarteAtelier est placée dans un <li>, car les entrées d’une liste <ul> doivent être des <li>. L’appel à new CarteAtelier(atelier.id) est possible parce que customElements.define a enregistré la classe avant sa construction.

La page s’abonne aussi pour écrire le message dans le paragraphe de statut. Elle utilise maintenant du texte, sans interprétation HTML. Elle ne conserve cependant pas la fonction qui permettrait de retirer cet abonnement. La classe règle le nettoyage des cartes, pas encore celui de toute la page.

Vérifier les deux versions

Relancez la page et tapez une adresse complète. Vous pouvez saisir toutes les lettres sans cliquer de nouveau dans le champ, car les notifications ne le remplacent plus. Réservez ensuite l’atelier Dessin. Le message confirme la réservation et les places diminuent.

Collez ensuite l’adresse piégée du chapitre 2, <img/src/onerror=alert(1)>@a.fr, puis réservez. Le message doit afficher la balise comme du texte, sans ouvrir de fenêtre. Le store et la classe de réservation n’ont pas changé. C’est la façon de reporter le message dans la page qui empêche son interprétation comme du HTML.

Pour observer le désabonnement, remplacez temporairement la dernière ligne de main.ts par ces deux lignes. Elles gardent la fonction de démontage et rendent demonter et store accessibles depuis la console du navigateur.

const demonter = monter(document.querySelector<HTMLElement>("#app")!, PageAteliers);
Object.assign(window, { demonter, store });

Dans la console, conservez une référence vers le texte d’une carte avant de démonter la page. Écrivez ensuite un état où chaque atelier a 9 places libres, puis inspectez le texte conservé. Cette écriture sert uniquement à observer les abonnements. Elle modifie la copie destinée à l’affichage, pas les réservations dans la classe.

const texte = document.querySelector("li span");
demonter();
const etat = store.lire();
store.ecrire({ ...etat, ateliers: etat.ateliers.map(a => ({ ...a, places: 9 })) });
texte.textContent;

Avec la classe, le texte conservé garde son ancien nombre de places. Le retrait de la page a déclenché disconnectedCallback, qui a désabonné la carte. L’état du store change toujours, mais cette carte ne reçoit plus ses notifications.

Pour comparer, remplacez la classe par la version fonction et supprimez son enregistrement. Dans la page, écrivez alors const [carte] = CarteAtelier(atelier.id), puis ligne.append(carte). Cette décomposition ignore volontairement la seconde valeur, celle qui permet de se désabonner. Rechargez la page pour repartir d’un nouveau montage et d’un nouveau contexte de console, puis rejouez les commandes. Le texte de la carte retirée affiche cette fois 9 places.

Le store conserve la fonction d’affichage, qui garde elle-même une référence vers les éléments retirés. Ceux-ci ne peuvent donc pas être libérés tant que cet abonnement subsiste. La console retient aussi la référence créée pour l’observation, mais cela ne suffit pas à expliquer la mise à jour. C’est bien l’abonnement oublié qui déclenche encore le rendu.

Template Method, le squelette et les crochets

Le catalogue GoF de 1994 décrit le pattern Template Method. Refactoring.Guru en donne cette définition : il « permet de mettre le squelette d’un algorithme dans la classe mère, mais laisse les sous-classes redéfinir certaines étapes de l’algorithme sans changer sa structure ». La classe mère fixe l’ordre des étapes, et les sous-classes remplissent certaines d’entre elles. Une étape facultative, vide ou dotée d’un comportement par défaut, s’appelle un crochet, ou hook en anglais.

Dans la forme classique du pattern, une méthode de la classe mère contient l’enchaînement des opérations. Elle appelle certaines méthodes que les sous-classes peuvent redéfinir. La sous-classe change ainsi une étape sans réécrire l’ensemble. Le GoF rattache cette organisation au principe d’Hollywood du chapitre 1. Le code qui coordonne le traitement appelle les extensions fournies par l’application.

Notre élément personnalisé illustre une inversion de contrôle comparable, mais ne reproduit pas exactement ce pattern. Le navigateur décide quand appeler les méthodes reconnues de la sous-classe de HTMLElement. CarteAtelier fournit deux de ces crochets, connectedCallback et disconnectedCallback. Elle ne définit pas attributeChangedCallback, car elle ne réagit à aucun attribut.

La différence est la place du code qui coordonne les appels. Il appartient aux algorithmes du navigateur, pas à une méthode de HTMLElement qui enchaînerait des méthodes héritées. Les connexions et les retraits peuvent d’ailleurs se répéter. Le diagramme distingue donc l’héritage de l’élément HTML et les callbacks déclarés par la carte.

classDiagram
  accTitle: CarteAtelier définit les callbacks appelés par le navigateur
  accDescr: La classe CarteAtelier hérite de HTMLElement et déclare connectedCallback et disconnectedCallback. Le navigateur appelle ces callbacks à la connexion et au retrait de l'élément.
  class HTMLElement
  class CarteAtelier {
    -atelierId : number
    -desabonner : function
    +connectedCallback() void
    +disconnectedCallback() void
  }
  HTMLElement <|-- CarteAtelier

La flèche à pointe creuse se lit « CarteAtelier hérite de HTMLElement », comme dans le chapitre UML. Les callbacks figurent sur la carte, car ils ne sont pas des méthodes définies sur HTMLElement. Lors de customElements.define, le navigateur les recherche sur le prototype de la classe enregistrée.

La fiche aide-mémoire Template Method présente la forme classique du pattern sur l’envoi d’un colis, puis montre où le reconnaître dans les frameworks.

Les classes et les fonctions dans les frameworks réels

On retrouve des cycles de vie dans les frameworks, sans que leurs mécanismes soient identiques. Les composants classes de React héritent de Component. Le framework peut appeler componentDidMount après le montage et componentWillUnmount avant le retrait. Angular utilise des classes dont les méthodes ngOnInit et ngOnDestroy correspondent à l’initialisation et à la destruction du composant. Lit construit ses composants sur les éléments personnalisés et ajoute un cycle de mise à jour à celui du navigateur.

React propose aussi les composants fonctions, avec des hooks depuis 2019. Le mot désigne ici des fonctions de son API, et non des méthodes de sous-classe. Un composant peut notamment déclarer un effet avec useEffect. La fonction passée à cet appel peut renvoyer un nettoyage que React exécutera lorsque l’effet doit être arrêté ou réexécuté. Comme dans le tuple renvoyé par notre CarteAtelier, le nettoyage est une fonction, mais c’est React qui la conserve et l’appelle.

Vue, Svelte et Solid proposent également des composants écrits sous forme de fonctions ou de fichiers compilés, sans imposer l’héritage d’une classe à l’application. Le choix de la syntaxe n’enlève pas le besoin de suivre les abonnements. Au chapitre 5, on construira le mécanisme dont notre version fonction a besoin. Le composant enregistrera son nettoyage auprès du framework au lieu de compter sur son appelant pour le conserver.

Nuance, ce que coûte chaque version

L’héritage de HTMLElement et l’enregistrement dans customElements permettent à la classe de recevoir les notifications du navigateur. Les champs privés conservent l’identifiant de l’atelier et la fonction de désabonnement entre deux appels. Cette intégration dépend cependant des API du navigateur, absentes de Node.js sans environnement DOM supplémentaire.

Notre constructeur reçoit son argument parce que l’application appelle elle-même new CarteAtelier(1). Si le navigateur crée la balise <carte-atelier> écrite dans le HTML, il appelle le constructeur sans argument. Cette classe, telle qu’elle est écrite, ne suffit donc pas pour cet usage. Il faudrait lui transmettre l’identifiant par un attribut ou une propriété et adapter son initialisation.

La fonction n’a besoin ni d’hériter d’un élément HTML ni de s’enregistrer sous un nom de balise. En revanche, quelqu’un doit conserver et exécuter son nettoyage. La classe délègue ce suivi au navigateur, alors que notre fonction attend encore cette aide du framework.

Les deux versions partagent une autre limite. Chaque carte possède une fonction afficher qui met à jour son texte et son bouton à chaque écriture dans le store. Taper une lettre recalcule donc le texte de toutes les cartes, alors que seul l’état des boutons dépend du courriel. Le chapitre 4 sépare ces mises à jour et construit les abonnements à partir des données que chacune lit.

Frameworks 4, des signaux qui s’abonnent seuls

Au chapitre 3, les composants conservaient leurs éléments au lieu de reconstruire la page. Leurs mises à jour restaient pourtant trop larges. Chaque carte s’abonnait au store entier, si bien que taper une lettre recalculait son texte alors que seul son bouton dépend du courriel.

Nous allons remplacer le store par des signaux qui déduisent les abonnements des valeurs lues par le code. Le texte d’une carte ne sera ainsi plus recalculé pendant la saisie du courriel.

Ce que dit la définition

Un signal contient une valeur et permet de suivre les fonctions qui en dépendent. La documentation de Vue décrit, dans sa page sur la réactivité en profondeur, deux opérations complémentaires. Une lecture permet d’enregistrer une dépendance, puis une modification déclenche les effets abonnés.

Un effet est une fonction que le framework exécute en surveillant les signaux qu’elle lit. Elle peut, par exemple, lire le nombre de places et écrire le texte d’une carte. Le framework enregistre alors ce signal comme une dépendance de l’effet, afin de relancer la fonction lorsque la valeur change. Une lecture ordinaire, en dehors d’un effet, renvoie la valeur sans créer d’abonnement.

L’idée est ancienne. En 2010, la bibliothèque Knockout de Steve Sanderson proposait déjà des valeurs observables qui suivaient leurs lecteurs. Solid a ensuite repris et popularisé le mot « signal ». En 2023, l’équipe de Svelte écrit dans l’annonce des runes que la réactivité de Svelte 5 repose sur des signaux, « essentiellement ce que faisait Knockout en 2010 ». Angular, Preact et Vue proposent aujourd’hui leurs propres signaux, et une proposition TC39, au stade 1, étudie leur ajout au langage JavaScript.

En clair

On retrouve le pattern Observer, mais le framework se charge de l’inscription. Avec le store, une vue appelait abonner et précisait la fonction à rappeler. Avec un signal, elle déclare un effet qui lit la valeur dont elle a besoin. Pendant cette exécution, la lecture inscrit l’effet comme abonné. Une écriture qui change la valeur relance ensuite les effets inscrits auprès de ce signal, sans relancer ceux qui n’en dépendent pas.

Prenons le bouton d’une carte. Son état dépend du courriel et des places de l’atelier. L’effet qui calcule disabled s’abonne aux signaux qu’il lit effectivement pendant ce calcul. Il peut ne lire que le courriel si celui-ci est vide, car cela suffit déjà à désactiver le bouton. En revanche, l’effet qui écrit le titre et les places ne lit jamais le courriel. Taper une lettre ne le relance donc pas.

Repérer le besoin

Notre fonction afficher met à jour plusieurs éléments à chaque changement, même ceux qui ne dépendent pas de la donnée modifiée. Séparer ces mises à jour demanderait de gérer à la main leurs abonnements et leurs désabonnements. Un oubli dans la liste des dépendances laisserait alors un élément afficher une valeur périmée.

Construire Signal et effet

Remplacez creerStore et le type Store de src/framework.ts par ce code. Gardez monter au début du fichier.

let effetCourant: Effet | null = null;

export class Signal<T> {
  #valeur: T;
  #lecteurs = new Set<Effet>();

  constructor(valeur: T) {
    this.#valeur = valeur;
  }

  lire(): T {
    effetCourant?.suivre(this.#lecteurs);
    return this.#valeur;
  }

  ecrire(valeur: T): void {
    if (Object.is(this.#valeur, valeur)) return;
    this.#valeur = valeur;
    for (const effet of [...this.#lecteurs]) effet.executer();
  }
}

class Effet {
  #fonction: () => void;
  #sources = new Set<Set<Effet>>();

  constructor(fonction: () => void) {
    this.#fonction = fonction;
  }

  suivre(lecteurs: Set<Effet>): void {
    lecteurs.add(this);
    this.#sources.add(lecteurs);
  }

  executer(): void {
    this.#oublierSources();
    const precedent = effetCourant;
    effetCourant = this;
    try {
      this.#fonction();
    } finally {
      effetCourant = precedent;
    }
  }

  #oublierSources(): void {
    for (const lecteurs of this.#sources) lecteurs.delete(this);
    this.#sources.clear();
  }
}

export function effet(fonction: () => void): void {
  new Effet(fonction).executer();
}

La variable de module effetCourant indique pour quel effet une lecture a lieu. Elle vaut null lorsqu’aucun effet ne s’exécute.

effet(fonction) crée un objet Effet et l’exécute aussitôt. Ce premier passage produit l’affichage initial et découvre les dépendances. executer place l’objet dans effetCourant avant d’appeler sa fonction, puis restaure la valeur précédente dans le bloc finally, même si la fonction lève une erreur. Cette sauvegarde permet aussi les effets imbriqués. Quand l’effet intérieur se termine, effetCourant désigne de nouveau l’effet extérieur, auquel les lectures suivantes seront rattachées.

Pendant cette exécution, chaque appel à lire() trouve l’effet dans effetCourant et appelle sa méthode suivre. Celle-ci conserve le lien dans deux ensembles. Le signal range l’effet parmi ses lecteurs, pour savoir qui prévenir lors d’une écriture. L’effet conserve l’ensemble des lecteurs du signal parmi ses sources, pour pouvoir s’en retirer plus tard. Puisque ces collections sont des ensembles, lire plusieurs fois le même signal ne crée pas plusieurs abonnements.

Une lecture faite hors d’un effet, par exemple dans un écouteur de clic, trouve effetCourant à null et ne crée aucun abonnement. Le suivi se limite donc aux lectures synchrones effectuées pendant l’appel de la fonction. Une lecture différée, après un délai ou une attente asynchrone, n’est plus rattachée à cet effet.

ecrire compare la nouvelle valeur à l’ancienne avec Object.is. Si elles sont identiques, il ne fait rien. Sinon, il remplace la valeur puis relance les lecteurs. Pour un tableau ou un objet, la comparaison porte sur son identité, pas sur son contenu. Modifier un tableau en place puis réécrire ce même tableau ne déclencherait donc pas les effets. L’application écrira de nouveaux tableaux pour signaler les changements.

La copie [...this.#lecteurs] permet de parcourir les abonnés présents au début de l’écriture. Sans elle, la boucle for...of parcourrait directement un ensemble que les effets modifient en s’exécutant. Un effet se retire de ses sources, puis s’y réinscrit quand il relit le signal. La boucle retrouverait alors cet effet à la fin de l’ensemble et le relancerait sans fin.

Avant chaque exécution, #oublierSources retire l’effet de tous les signaux lus au passage précédent. La fonction reconstruit ensuite ses abonnements à partir de ses nouvelles lectures. Les dépendances sont donc dynamiques, car elles peuvent changer avec les conditions du programme. Si une branche ne lit plus un signal, l’effet cesse de s’y abonner au lieu de conserver une dépendance devenue inutile.

La classe Signal protège sa valeur et ses lecteurs dans des champs privés, comme la classe Inscriptions protège ses réservations. Remplacer la valeur impose de passer par ecrire, qui déclenche les lecteurs. Cette protection n’empêche toutefois pas de modifier le contenu d’un objet reçu à la lecture. La classe Effet n’est pas exportée, car l’application doit seulement déclarer des effets avec la fonction effet, sans manipuler leurs abonnements.

flowchart LR
  accTitle: Les effets lisent les signaux dont ils dépendent
  accDescr: L'effet du texte lit le signal ateliers. L'effet du bouton lit les signaux email et ateliers. L'effet du message lit le signal message. Écrire dans email ne relance que l'effet du bouton.
  Ateliers((ateliers)) --> Texte[effet du texte]
  Ateliers --> Bouton[effet du bouton]
  Email((email)) --> Bouton
  Message((message)) --> Statut[effet du message]

Vérifier sans navigateur

Créez tests/signaux.test.ts et exécutez-le avec node tests/signaux.test.ts.

import assert from "node:assert/strict";
import { Signal, effet } from "../src/framework.ts";

const email = new Signal("");
const places = new Signal(2);
const etats: string[] = [];

effet(() => {
  etats.push(email.lire() === "" || places.lire() === 0 ? "désactivé" : "actif");
});
assert.deepEqual(etats, ["désactivé"]);

places.ecrire(1);
assert.deepEqual(etats, ["désactivé"]);

email.ecrire("lea@example.test");
assert.deepEqual(etats, ["désactivé", "actif"]);

email.ecrire("lea@example.test");
assert.equal(etats.length, 2);

places.ecrire(0);
assert.deepEqual(etats, ["désactivé", "actif", "désactivé"]);
console.log("Vérifications réussies.");

Au premier passage, le courriel est vide. La partie gauche de l’opérateur || suffit donc à décider que le bouton est désactivé, sans lire places. L’effet s’abonne seulement au courriel, ce qui explique la deuxième assertion. Le passage de deux places à une ne le relance pas, puisque le résultat resterait « désactivé ».

Quand le courriel est rempli, l’effet se relance et lit aussi places. Il trouve la valeur courante, une place, puis s’abonne à ce signal. Écrire deux fois la même adresse ne provoque pas de nouvelle exécution, grâce à Object.is. En revanche, le passage à zéro place relance l’effet et ajoute « désactivé » au tableau. Ce test montre que les abonnements suivent les lectures réellement exécutées, pas tous les noms de signaux présents dans la fonction.

Réécrire l’interface avec des signaux

Remplacez src/main.ts par cette version.

import { Inscriptions } from "./inscriptions.ts";
import { Signal, effet, monter } from "./framework.ts";

const inscriptions = new Inscriptions([
  { id: 1, titre: "Dessin", capacite: 2, prixCentimes: 2000 },
  { id: 2, titre: "Photo", capacite: 1, prixCentimes: 3000 },
]);

const ateliers = new Signal(inscriptions.listerAteliers());
const email = new Signal("");
const message = new Signal("");

function reserver(atelierId: number): void {
  try {
    const reservation = inscriptions.reserver(atelierId, email.lire());
    ateliers.ecrire(inscriptions.listerAteliers());
    message.ecrire(`Réservation ${reservation.id} confirmée pour ${reservation.email}`);
  } catch (erreur) {
    message.ecrire(erreur instanceof Error ? erreur.message : String(erreur));
  }
}

function LigneAtelier(atelierId: number): HTMLLIElement {
  const ligne = document.createElement("li");
  const texte = document.createElement("span");
  const bouton = document.createElement("button");
  bouton.textContent = "Réserver";
  bouton.addEventListener("click", () => reserver(atelierId));
  ligne.append(texte, " ", bouton);

  const atelier = () => ateliers.lire().find(a => a.id === atelierId)!;
  effet(() => {
    texte.textContent = `${atelier().titre}, places libres : ${atelier().places}`;
  });
  effet(() => {
    bouton.disabled = email.lire() === "" || atelier().places === 0;
  });
  return ligne;
}

function PageAteliers(): HTMLElement {
  const page = document.createElement("main");
  const champ = document.createElement("input");
  champ.type = "email";
  champ.addEventListener("input", () => email.ecrire(champ.value));
  const etiquette = document.createElement("label");
  etiquette.append("Courriel ", champ);

  const liste = document.createElement("ul");
  liste.append(...ateliers.lire().map(atelier => LigneAtelier(atelier.id)));

  const statut = document.createElement("p");
  statut.setAttribute("role", "status");
  effet(() => {
    statut.textContent = message.lire();
  });

  page.append(etiquette, liste, statut);
  return page;
}

monter(document.querySelector<HTMLElement>("#app")!, PageAteliers);

L’état unique du store devient trois signaux, un par donnée qui change indépendamment. Le type Etat et la classe CarteAtelier disparaissent. On revient à une fonction, LigneAtelier, qui crée ses éléments une seule fois et renvoie directement son <li>. Les effets déclarés dans cette fonction prennent en charge leurs mises à jour.

La fonction atelier calcule une valeur dérivée, c’est-à-dire une valeur obtenue à partir d’un autre état. Ici, elle recherche l’atelier de la ligne dans le signal ateliers, sans conserver de résultat en mémoire. Quand un effet l’appelle, l’appel à ateliers.lire() se produit toujours pendant cet effet. Le suivi traverse donc l’appel de fonction, et l’effet s’abonne au signal même s’il ne le lit pas directement dans son propre corps.

Chaque ligne crée deux effets. Le premier écrit le titre et les places, tandis que le second règle l’état du bouton. Taper une lettre ne relance que le second effet de chaque ligne. Quand une réservation réussit, reserver écrit un nouveau tableau dans ateliers. L’effet du texte se relance pour chaque ligne et, tant que le courriel n’est pas vide, celui du bouton aussi.

Le suivi est plus précis qu’avec le store entier, mais il s’arrête au niveau du signal. Toutes les lignes partagent le même tableau d’ateliers. Réserver Dessin relance donc aussi les effets abonnés à ce tableau dans la ligne Photo, même si ses places n’ont pas changé.

reserver lit email.lire() depuis un écouteur de clic. Aucun effet n’est en cours à ce moment, donc cette lecture ne crée pas d’abonnement. La réservation utilise le courriel au moment du clic, mais ne doit pas se rejouer lorsque le courriel change.

Relancez la page et vérifiez le comportement. Les boutons restent désactivés tant que le champ est vide, le focus reste dans le champ pendant la saisie, et les places diminuent après chaque réservation. Le bouton de Photo se désactive après sa réservation, puisque l’atelier n’a qu’une place.

Une fuite dans les effets imbriqués

Le framework sait retirer les dépendances devenues inutiles, mais il ne sait pas encore arrêter un effet dont l’affichage a disparu. Tant que les ateliers restent les mêmes et que la page reste montée, ce manque passe inaperçu. Il devient visible lorsqu’un effet en crée d’autres à chaque reconstruction d’une liste. Créez tests/fuite.ts pour observer leur accumulation.

import { Signal, effet } from "../src/framework.ts";

const email = new Signal("");
const reservations = new Signal([1, 2]);
let executions = 0;

effet(() => {
  for (const _ of reservations.lire()) {
    effet(() => {
      email.lire();
      executions++;
    });
  }
});

reservations.ecrire([1, 2, 3]);
executions = 0;
email.ecrire("sam@example.test");
console.log(`Effets relancés : ${executions}`);

L’effet extérieur représente une liste de réservations, et chaque effet intérieur représente une ligne qui dépend du courriel. Le premier passage crée deux effets de ligne. L’écriture d’un tableau de trois réservations relance l’effet extérieur, qui en crée trois autres sans arrêter les deux premiers.

Le compteur est ensuite remis à zéro pour mesurer seulement les exécutions provoquées par le changement de courriel. Le programme en affiche 5, alors que la nouvelle liste ne demande que trois effets. Les deux anciens sont toujours abonnés au courriel, à côté des trois nouveaux.

Dans une interface, un effet de ligne conserve les éléments qu’il doit mettre à jour. Le signal retient cet effet parmi ses lecteurs, même lorsque les éléments ont quitté la page. Il continue donc de les mettre à jour et empêche le navigateur de libérer leur mémoire. Le chapitre 5 ajoute un lien entre la durée de vie d’un effet et celle du code qui l’a créé, afin d’arrêter ces anciens effets.

Les signaux dans les frameworks réels

Solid sépare les opérations en deux API. La fonction createSignal renvoie une fonction de lecture et une fonction d’écriture, tandis que createEffect déclare l’effet. Vue nomme ref ses conteneurs de valeurs réactives et propose watchEffect pour les effets. Le pseudo-code de sa documentation utilise une variable activeEffect, qui joue le rôle de notre effetCourant. Les fonctions track et trigger correspondent respectivement à suivre et à la boucle d’ecrire.

Angular propose signal, computed et effect pour distinguer l’état modifiable, les valeurs calculées et les effets. Svelte 5 expose les runes $state et $effect plutôt que des appels explicites de lecture et d’écriture. Son compilateur ajoute les opérations nécessaires au suivi. On retrouve donc le même besoin, relier un calcul aux valeurs qu’il lit, sans retrouver nécessairement les mêmes appels dans le code de l’application.

Ryan Carniato, l’auteur de Solid, construit une bibliothèque semblable dans l’article Building a Reactive Library from Scratch, publié en 2021. Son code copie aussi les abonnés avant de les relancer et nettoie les dépendances avant chaque exécution.

Nuance, ce que notre version ne fait pas

Nos effets se relancent immédiatement, pendant chaque écriture. Quand reserver écrit dans ateliers puis dans message, un effet qui lit les deux voit d’abord les nouveaux ateliers avec l’ancien message, puis s’exécute de nouveau. La documentation de Svelte décrit un autre choix. Les nouvelles exécutions y sont groupées après la mise à jour du DOM. Le moment d’exécution varie donc selon le framework.

Les frameworks proposent aussi des valeurs calculées, comme computed dans Angular et Vue. Notre fonction atelier refait sa recherche à chaque appel, même si les données n’ont pas changé. Une valeur calculée conserve son résultat et suit les signaux nécessaires au calcul. Si aucun d’eux n’a changé, une nouvelle lecture réutilise ce résultat. Sinon, elle le recalcule à la demande. Ce mécanisme évite les recherches répétées sans maintenir manuellement une seconde copie de l’état.

Le synchronisme impose aussi des limites. Un effet qui modifie un signal qu’il vient de lire peut se rappeler lui-même sans fin. La copie des abonnés protège le parcours de l’ensemble, mais pas contre cette récursion. De même, le bloc finally restaure l’effet courant après une erreur sans la traiter. Si un effet lève une erreur, celle-ci interrompt la boucle d’écriture, et les lecteurs suivants ne sont pas exécutés.

Toute lecture faite pendant un effet crée un abonnement, y compris une lecture involontaire. Le chapitre 5 en montre un exemple, et Solid propose la fonction untrack pour lire une valeur sans s’y abonner.

Frameworks 5, monter et nettoyer

Au chapitre 4, les signaux ont permis de mettre à jour seulement les affichages qui en dépendent. Il leur manque pourtant une information. Quand une liste remplace ses lignes, les effets des anciennes lignes restent abonnés, car le framework ne sait pas qu’ils ne servent plus.

Un écouteur posé sur document, qui survit au composant, pose le même problème. Nous allons rattacher les effets et les nettoyages à une durée de vie pour les arrêter avant une reconstruction ou au démontage de la page.

Ce que dit la définition

Le cycle de vie d’un composant décrit les étapes de son existence. Après sa création, il est monté, c’est-à-dire inséré dans la page, puis son affichage se met à jour lorsque ses données changent. Il est enfin démonté quand l’application le retire. Ce retrait doit aussi arrêter les activités qui n’ont plus de raison de continuer, comme ses abonnements, ses écouteurs extérieurs ou ses minuteries. Une requête en cours peut également devoir être annulée pour ne pas agir sur un composant disparu.

Solid range ces nettoyages dans des portées. Sa documentation de onCleanup explique que cette fonction « enregistre une fonction de nettoyage dans la portée réactive courante ». La portée d’un composant est nettoyée quand le composant est démonté. La portée d’un effet est nettoyée avant chaque nouvelle exécution de cet effet.

En clair

Une portée regroupe les opérations qu’il faudra défaire ensemble. Pendant la construction de la page, le framework désigne une portée courante. Chaque effet créé et chaque nettoyage demandé s’y inscrivent, sans que les fonctions composants aient à transmettre une liste entre elles. Au démontage, il suffit de détruire cette portée pour arrêter les effets et exécuter les nettoyages enregistrés.

Un effet possède aussi sa propre portée, rattachée à celle qui était courante lors de sa création. Quand il se relance, il vide d’abord sa portée pour arrêter les effets créés au passage précédent. Les nouveaux effets s’y inscrivent ensuite. On distingue ainsi deux moments de nettoyage. Une reconstruction arrête les anciens effets enfants, tandis que le démontage arrête tous les effets de la page.

Dans notre framework, appeler une fonction composant ne crée pas de portée supplémentaire. Les composants utilisent celle dans laquelle ils sont appelés. Ce sont le montage de la page, la création explicite d’une portée et la création d’un effet qui organisent les durées de vie. L’arbre des portées suit donc les créations réactives, pas nécessairement chaque élément de l’arbre HTML.

Le repérer dans le code

Un abonnement à un signal global, à document ou à window peut survivre au composant. Il en va de même d’une minuterie lancée avec setInterval ou d’une requête encore en cours. Les effets qui créent des éléments ou d’autres effets à chaque exécution doivent aussi arrêter ceux du passage précédent.

Un écouteur posé sur un bouton du composant n’a généralement pas besoin d’être retiré séparément. Le bouton et son écouteur peuvent être libérés ensemble, dès que plus rien ne référence le bouton. Un écouteur posé sur document est différent, car document vit aussi longtemps que la page. Il conserve la fonction d’écoute et, par elle, les éléments auxquels cette fonction accède.

Une liste de réservations qui fuit

Pour observer les deux problèmes, on ajoute une liste de réservations et un raccourci clavier. Sous les ateliers, chaque réservation aura un bouton d’annulation. La liste masquera les réservations dont le courriel diffère de celui du champ, sans les supprimer de l’état. La touche / placera le curseur dans ce champ.

Ces deux composants construisent la liste. Ils seront assemblés après la correction du framework, avec l’état et l’action d’annulation dont ils ont besoin.

function LigneReservation(reservation: Reservation): HTMLLIElement {
  const ligne = document.createElement("li");
  const bouton = document.createElement("button");
  bouton.textContent = "Annuler";
  bouton.addEventListener("click", () => annuler(reservation.id));
  ligne.append(`${titres.get(reservation.atelierId)}, ${reservation.email} `, bouton);

  effet(() => {
    ligne.hidden = reservation.email !== email.lire().trim().toLowerCase();
  });
  return ligne;
}

function ListeReservations(): HTMLElement {
  const section = document.createElement("section");
  const titre = document.createElement("h2");
  titre.textContent = "Vos réservations";
  const liste = document.createElement("ul");
  effet(() => {
    liste.replaceChildren(...reservations.lire().map(r => LigneReservation(r)));
  });
  section.append(titre, liste);
  return section;
}

ListeReservations reconstruit toutes ses lignes chaque fois que le signal reservations change. Chaque ligne crée un effet qui la masque si son adresse diffère du courriel saisi. Avec le framework du chapitre 4, remplacer les éléments ne retire pas les effets des anciennes lignes. Ils restent abonnés au courriel et conservent les lignes qu’ils modifient. Après plusieurs réservations et annulations, une seule frappe peut donc relancer de nombreux effets pour des lignes qui ne sont plus affichées. Le script tests/fuite.ts du chapitre 4 reproduit cette accumulation.

Le raccourci clavier pose le second problème. Son écouteur sera inscrit sur document, qui survit à la page des ateliers. Si l’application retire cette page pour en afficher une autre, l’écouteur restera actif. Il conservera l’ancien champ et tentera encore de lui donner le focus à chaque appui sur la touche.

Construire les portées

Réorganisez src/framework.ts selon cette version, qui modifie Effet et monter et ajoute les portées. À l’emplacement indiqué, conservez la classe Signal du chapitre 4. Le commentaire abrège son corps, il ne le remplace pas.

type Portee = { parent: Portee | null; nettoyages: (() => void)[] };

let porteeCourante: Portee | null = null;
let effetCourant: Effet | null = null;

function dans<T>(portee: Portee, fonction: () => T): T {
  const precedente = porteeCourante;
  porteeCourante = portee;
  try {
    return fonction();
  } finally {
    porteeCourante = precedente;
  }
}

function detruire(portee: Portee): void {
  for (const nettoyage of portee.nettoyages.splice(0).reverse()) nettoyage();
}

export function creerPortee<T>(fonction: () => T): [T, () => void] {
  const portee: Portee = { parent: porteeCourante, nettoyages: [] };
  const detruirePortee = () => detruire(portee);
  porteeCourante?.nettoyages.push(detruirePortee);
  return [dans(portee, fonction), detruirePortee];
}

export function auNettoyage(nettoyage: () => void): void {
  if (!porteeCourante) throw new Error("auNettoyage appelé hors d'une portée");
  porteeCourante.nettoyages.push(nettoyage);
}

export type Composant = () => HTMLElement;

export function monter(racine: HTMLElement, composant: Composant): () => void {
  const [element, detruirePortee] = creerPortee(composant);
  racine.append(element);
  return () => {
    detruirePortee();
    element.remove();
  };
}

export class Signal<T> {
  // Le code du chapitre 4 ne change pas.
}

class Effet {
  #fonction: () => void;
  #sources = new Set<Set<Effet>>();
  #portee: Portee;
  #actif = true;

  constructor(fonction: () => void) {
    this.#fonction = fonction;
    this.#portee = { parent: porteeCourante, nettoyages: [] };
    porteeCourante?.nettoyages.push(() => this.#arreter());
  }

  suivre(lecteurs: Set<Effet>): void {
    lecteurs.add(this);
    this.#sources.add(lecteurs);
  }

  executer(): void {
    if (!this.#actif) return;
    this.#nettoyer();
    const precedent = effetCourant;
    effetCourant = this;
    try {
      dans(this.#portee, this.#fonction);
    } finally {
      effetCourant = precedent;
    }
  }

  #arreter(): void {
    this.#actif = false;
    this.#nettoyer();
  }

  #nettoyer(): void {
    for (const lecteurs of this.#sources) lecteurs.delete(this);
    this.#sources.clear();
    detruire(this.#portee);
  }
}

export function effet(fonction: () => void): void {
  new Effet(fonction).executer();
}

Une Portee contient une liste de fonctions de nettoyage et un lien vers sa portée parente. La variable porteeCourante désigne la portée qui reçoit les nouvelles inscriptions, comme effetCourant désigne l’effet qui reçoit les nouvelles dépendances. La fonction dans remplace cette portée le temps d’appeler une fonction, puis restaure la précédente dans son bloc finally.

Ces deux variables ont des rôles distincts. L’effet courant indique à quel calcul rattacher une lecture de signal. La portée courante indique qui devra arrêter un nouvel effet ou appeler un nettoyage. Le lien parent servira au chapitre 6 pour rechercher des valeurs fournies par un ancêtre. Ce n’est pas lui qui déclenche le nettoyage des enfants.

detruire extrait les nettoyages et vide leur liste avec splice(0), puis les appelle dans l’ordre inverse de leur inscription. Les opérations enregistrées en dernier sont ainsi défaites en premier. Comme la liste est déjà vide pendant les appels, une seconde demande de destruction ne rejoue pas les mêmes nettoyages.

creerPortee exécute une fonction dans une nouvelle portée, puis renvoie son résultat avec la fonction qui détruit cette portée. Si une portée parente est courante, elle reçoit cette fonction de destruction dans sa propre liste de nettoyages. Détruire la parente provoquera donc aussi la destruction de l’enfant. La relation de nettoyage vient de cette inscription, et non d’un parcours du lien parent.

monter utilise ce mécanisme pour construire la page dans une portée. La fonction de démontage qu’il renvoie détruit cette portée avant de retirer l’élément. Le framework ne surveille pas lui-même les retraits du DOM. Pour obtenir le nettoyage, le code appelant doit utiliser cette fonction de démontage, plutôt que retirer directement l’élément.

Les composants appellent auNettoyage pour inscrire une fonction dans la portée courante. Si aucune portée n’est active, l’appel lève une erreur au lieu d’ignorer la demande. C’est notamment le cas dans un écouteur de clic, appelé plus tard par le navigateur. La portée reste active pendant la construction synchrone du composant ou l’exécution synchrone d’un effet, pas pendant toute la durée de vie de l’élément.

Dans Effet, le constructeur crée une portée pour les ressources de l’effet, puis inscrit l’arrêt de l’effet auprès de la portée courante. La méthode executer lance ensuite la fonction dans cette portée propre, si bien que les effets enfants et les nettoyages créés pendant l’appel lui appartiennent.

Avant chaque nouvelle exécution, #nettoyer retire les abonnements et vide la portée de l’effet. Dans la liste de réservations, ce nettoyage arrête les effets des anciennes lignes avant de construire les nouvelles. Arrêter l’effet parent produit le même nettoyage et empêche toute exécution ultérieure.

Le champ #actif empêche de relancer un effet déjà arrêté. ecrire copie ses lecteurs avant de les exécuter. Si l’un d’eux en arrête un autre, ce dernier reste dans la copie, mais ignore la demande d’exécution grâce à #actif. Sans ce contrôle, il pourrait se réabonner après son arrêt. Ce cas apparaît quand un parent et ses enfants lisent le même signal. Dans notre liste, leurs dépendances sont distinctes, puisque le parent lit les réservations et les enfants le courriel.

flowchart TB
  accTitle: Les portées organisent la durée de vie des effets et des nettoyages
  accDescr: monter crée la portée racine. La page s'y exécute et y inscrit ses effets, le nettoyage du raccourci et la portée de l'effet de liste. À chaque exécution, l'effet de liste vide sa portée, ce qui arrête les effets des anciennes lignes, puis y inscrit les effets des nouvelles lignes.
  Racine[Portée de monter] --> Statut[Effet du message]
  Racine --> Raccourci[Nettoyage du raccourci]
  Racine --> Liste[Effet de la liste]
  Liste --> L1[Effet de la ligne 1]
  Liste --> L2[Effet de la ligne 2]

Réécrire l’interface

Dans src/main.ts, reprenez cette organisation en conservant la fonction LigneAtelier du chapitre 4. Ajoutez aussi les fonctions LigneReservation et ListeReservations présentées au début du chapitre, à la place des commentaires qui rappellent leur présence. La version ci-dessous ajoute le signal reservations, l’action annuler et le raccourci clavier.

import { Inscriptions, type Reservation } from "./inscriptions.ts";
import { Signal, auNettoyage, effet, monter } from "./framework.ts";

const inscriptions = new Inscriptions([
  { id: 1, titre: "Dessin", capacite: 2, prixCentimes: 2000 },
  { id: 2, titre: "Photo", capacite: 1, prixCentimes: 3000 },
]);
const titres = new Map(inscriptions.listerAteliers().map(a => [a.id, a.titre]));

const ateliers = new Signal(inscriptions.listerAteliers());
const reservations = new Signal(inscriptions.reservations);
const email = new Signal("");
const message = new Signal("");

function reserver(atelierId: number): void {
  try {
    const reservation = inscriptions.reserver(atelierId, email.lire());
    ateliers.ecrire(inscriptions.listerAteliers());
    reservations.ecrire(inscriptions.reservations);
    message.ecrire(`Réservation ${reservation.id} confirmée pour ${reservation.email}`);
  } catch (erreur) {
    message.ecrire(erreur instanceof Error ? erreur.message : String(erreur));
  }
}

function annuler(reservationId: number): void {
  inscriptions.annuler(reservationId);
  ateliers.ecrire(inscriptions.listerAteliers());
  reservations.ecrire(inscriptions.reservations);
  message.ecrire(`Réservation ${reservationId} annulée`);
}

// LigneAtelier ne change pas depuis le chapitre 4.
// LigneReservation et ListeReservations sont présentés plus haut.

function PageAteliers(): HTMLElement {
  const page = document.createElement("main");
  const champ = document.createElement("input");
  champ.type = "email";
  champ.addEventListener("input", () => email.ecrire(champ.value));
  const etiquette = document.createElement("label");
  etiquette.append("Courriel ", champ);

  const raccourci = (evenement: KeyboardEvent) => {
    if (evenement.key === "/" && document.activeElement !== champ) {
      evenement.preventDefault();
      champ.focus();
    }
  };
  document.addEventListener("keydown", raccourci);
  auNettoyage(() => document.removeEventListener("keydown", raccourci));

  const liste = document.createElement("ul");
  liste.append(...ateliers.lire().map(atelier => LigneAtelier(atelier.id)));

  const statut = document.createElement("p");
  statut.setAttribute("role", "status");
  effet(() => {
    statut.textContent = message.lire();
  });

  page.append(etiquette, liste, statut, ListeReservations());
  return page;
}

monter(document.querySelector<HTMLElement>("#app")!, PageAteliers);