Mini-framework réactifReactive mini-framework

01 · Contexte & objectif

Écrire un mini-framework web réactif en TypeScript, en n’utilisant aucune bibliothèque externe — Vite servait uniquement au bundling. React, Vue, Svelte, jQuery, Lodash : tous interdits. Il ne restait que l’API DOM native.

L’énoncé demandait d’y faire vivre les patrons de conception vus en cours, et d’aller jusqu’aux Observables. Le barème, sur 20 points, était très inégalement réparti : Strategy pesait 5 points à lui seul, Observer 2, et chacun des autres patterns 1. Ce déséquilibre disait où était le vrai sujet — et ce n’était pas d’aligner des patterns pour la forme.

Dix jours, à trois. Je me suis chargé du cœur du framework : les cinq patterns, l’infrastructure Docker et les tests unitaires.

02 · Le point dur : Strategy sur trois backends de stockage

Le store devait pouvoir persister son état en mémoire, dans le localStorage, ou dans IndexedDB — et changer de backend à l’exécution, sans que le store lui-même ne soit modifié.

Le piège est dans la nature des trois API. Map et localStorage sont synchrones : la valeur est là, tout de suite. IndexedDB est asynchrone : ouverture de base, transaction, événements onsuccess / onerror. Un contrat commun naïf — get(key): T — exclut donc IndexedDB d’entrée. Et un contrat qui l’accepterait par un détour quelconque forcerait l’appelant à savoir quel backend est branché, ce qui annule tout l’intérêt du pattern.

La seule interface qui tienne les trois est celle qui s’aligne sur le plus contraignant : tout retourne une Promise, y compris les backends synchrones, qui se contentent d’un Promise.resolve(). Le code appelant écrit await sans jamais savoir ce qu’il y a derrière, et setStrategy() peut permuter les implémentations à chaud.

Détail ajouté au-delà de l’énoncé : LocalStorageAdapter préfixe ses clés. Sans ça, son clear() viderait tout le localStorage du domaine, y compris ce qui ne lui appartient pas — un effet de bord invisible en développement, et pénible en production.

03 · Les autres patterns

Factory sans if ni switch. L’énoncé l’exigeait explicitement. Les huit types d’éléments (button, div, image, hr, input, heading, span, paragraph) sont enregistrés dans un Record<ElementType, TagConstructor> : ajouter un type consiste à ajouter une entrée, jamais à rallonger un branchement. Une classe abstraite partagée applique la configuration commune, chaque tag concret ne fournit que son nom de balise.

Builder à interface fluide. Des méthodes with* qui retournent this, et leurs symétriques without*. Il complète la Factory plutôt qu’il ne la double : la Factory pour créer vite un élément simple, le Builder pour composer des arbres imbriqués.

Observable. Le socle de toute la réactivité — le binding DOM, le store et le routeur sont tous construits dessus. Deux choix qui ne sont pas dans l’énoncé mais qui changent l’usage : subscribe() émet immédiatement la valeur courante — sinon un composant qui s’abonne après une émission reste vide jusqu’au prochain changement — et les abonnés sont stockés dans un Set, ce qui rend l’abonnement idempotent. Le désabonnement est retourné par subscribe(), pour éviter les fuites mémoire à la destruction d’un composant.

Singleton. AppConfig et AppStore, constructeur privé, getInstance(). AppStore reçoit une StorageStrategy : le Singleton porte l’état, la Strategy décide où il est persisté.

04 · Ce que j’ai ajouté ensuite

Le client HTTP renvoie un Result<T, HttpError> plutôt que de lever une exception : une erreur réseau devient une valeur qu’on traite, pas un flux de contrôle parallèle qu’on peut oublier d’attraper.

J’y ai greffé des interceptors, encore par Strategy — un AuthInterceptor qui ajoute un jeton porteur quand il y en a un, un LoggingInterceptor qui trace requête et réponse. Ils étaient optionnels au barème ; c’était l’endroit le plus naturel pour réutiliser le pattern hors du stockage.

05 · Un piège qui m’a coûté du temps

Les tests de LocalStorageAdapter passaient — mais ne testaient rien.

Node 22 embarque une implémentation expérimentale et native de localStorage. Sous Vitest, elle prenait le pas sur celle de jsdom : la suite exerçait le localStorage de Node, pas celui du navigateur qu’on prétendait vérifier. Un test vert qui ne prouve rien est pire qu’un test rouge, parce qu’il ferme la question.

Correctif : lancer Vitest avec NODE_OPTIONS=--no-experimental-webstorage, pour que jsdom reprenne la main.

06 · Qualité et livraison

86 tests Vitest, un fichier par brique. strict: true, plus noUnusedLocals et noUnusedParameters — et zéro any dans les sources. JSDoc sur les classes, interfaces et méthodes publiques.

Livraison en image Docker multi-étages : Node compile, Nginx sert le dist/ statique avec un repli SPA pour que le routeur côté client fonctionne sur un rechargement en profondeur.

07 · Ce que j’en retire

Un projet « appliquer les design patterns » invite à les plaquer : on écrit une Factory parce qu’il faut une Factory, et elle ne résout rien. Le barème d’ici protégeait contre ça en mettant cinq points sur le seul pattern qui posait une vraie question — faire cohabiter trois API dont l’une est asynchrone.

Ce que j’en garde n’est pas la mécanique des patterns, elle s’oublie et se relit. C’est le réflexe de chercher la contrainte la plus forte avant de définir une interface. En raisonnant depuis Map, on obtient un contrat synchrone élégant qu’IndexedDB fait exploser une semaine plus tard. En raisonnant depuis IndexedDB, on obtient un contrat que les trois honorent — un peu plus lourd pour les cas simples, mais qui n’a jamais eu besoin d’être retouché.