Un rapport de bug est arrivé, défiant tous les instincts de débogage. Les utilisateurs de téléphones Android d'entrée de gamme affirmaient que l'application disparaissait tout simplement.

Un rapport de bug est arrivé, défiant tous les instincts de débogage. Les utilisateurs de téléphones Android d'entrée de gamme affirmaient que l'application disparaissait tout simplement. Pas au lancement. Pas lors d'un appui ou d'un balayage spécifique. Environ vingt minutes après le début d'une session, l'écran se figeait et le processus s'arrêtait. Les logs étaient impeccables. La QA ne parvenait pas à le reproduire sur son matériel haut de gamme. Il n'y avait aucune étape à suivre. Après trois heures de profilage de la mémoire, la situation s'est enfin éclaircie. Un simple écouteur d'événements (event listener) se trouvait à l'intérieur d'un hook React. Cet écouteur avait capturé un large jeu de données. Le composant s'est démonté. L'écouteur est resté. Le jeu de données est resté en mémoire. Sur un appareil doté de 2 Go de RAM, cette accumulation a épuisé le heap et le système d'exploitation a tué l'application. Il ne s'agissait pas d'une erreur de syntaxe ou d'un défaut de logique. C'était un bug de portée (scope), et il était fatal.

Comment une closure devient une fuite

La plupart des tutoriels enseignent la portée (scope) comme une énigme académique sur la visibilité d'une variable. En production, la portée est un contrat concernant la durée de vie en mémoire. Lorsqu'une fonction JavaScript capture une variable, le moteur maintient cette variable en vie tant que la closure elle-même est accessible. Dans un composant React, cela signifie que vos données survivent longtemps après que l'utilisateur a navigué ailleurs et que le nœud de l'interface utilisateur a disparu.

Considérez un hook qui enregistre un écouteur sur l'objet window. Le composant est rendu, attache l'écouteur, puis se démonte plus tard. Si la phase de nettoyage (cleanup) est manquante ou mal exécutée, l'écouteur subsiste. Chaque nouveau montage ajoute une autre copie fantôme des données piégées dans la RAM. Sur une station de travail de développeur disposant d'une mémoire abondante, vous pourriez ne jamais remarquer l'inflation. Sur un téléphone d'entrée de gamme fonctionnant sous Android Go, vingt minutes d'utilisation normale suffisent à épuiser le heap disponible. Le système d'exploitation intervient et interrompt le processus. Il n'y a aucune exception à consigner. Le système coupe simplement le contact.

C'est pourquoi la portée est une question de gestion de la mémoire. L'environnement lexical n'est pas une frontière philosophique. C'est un graphe de rétention. Chaque variable que vous laissez à l'intérieur d'une closure non collectée est une brique dans un mur qui finira par enfermer votre application.

Trois façons dont la portée tue les applications en production

Les problèmes de portée ne se ressemblent pas tous. Certains drainent la mémoire lentement. D'autres explosent instantanément. Voici les schémas qui font systématiquement planter les applications.

Pollution de la portée globale

Les architectures micro-frontend permettent aux équipes de déployer de manière indépendante, mais elles partagent toutes le même objet window. Lorsqu'une application définit une variable globale comme window.config ou applique un patch sur une utilité partagée via window, elle ne vit pas de manière isolée. L'application d'une autre équipe pourrait dépendre d'une structure différente pour ce même objet global, ou l'écraser lors de son propre démarrage (bootstrap). Le résultat est un conflit de fonctionnalités qui s'amplifie avec la taille de votre organisation. Un développeur dans un dépôt n'a aucune idée que son raccourci constitue un breaking change pour une autre équipe. À mesure que la surface d'exposition augmente, ces variables globales deviennent des mines antipersonnel enfouies dans un terrain partagé.

Fuites de mémoire par closure

Les applications monopages (SPA) sont conçues pour fonctionner pendant des heures. Cette durabilité est précisément la raison pour laquelle les fuites de closures deviennent toxiques. Le schéma est trompeusement courant : un useEffect enregistre un callback auprès d'un bus d'événements global, d'un gestionnaire WebSocket ou du DOM lui-même. Si le tableau de dépendances est instable ou omis, le nettoyage ne correspond jamais à l'abonnement original. La closure capture tout ce qui se trouve dans son environnement lexical, ce qui peut inclure de massifs tableaux analysés, des blocs JSON récupérés ou des références à des arbres DOM. Chaque navigation ajoute du poids. L'utilisateur ne sait pas pourquoi son onglet de navigateur atteint les 800 Mo. Il sait seulement que l'application devient lente et finit par mourir.

C'est particulièrement dangereux lorsque les tableaux de dépendances changent à chaque rendu. Une nouvelle référence de fonction naît à chaque cycle, est enregistrée auprès d'un écouteur, et l'ancienne n'est jamais libérée. Le résultat est un musée de closures mortes, chacune thésaurisant les données avec lesquelles elle est née.

Erreurs TDZ dans les modules dynamiques

La Temporal Dead Zone n'est pas un simple cas limite théorique. Lorsque vous accédez à un let ou un const avant l'exécution de sa déclaration, le moteur lève une ReferenceError. Dans les grands monorepos avec des dépendances circulaires et des imports dynamiques, l'ordre d'exécution exact est souvent implicite. Le module A importe le module B, qui importe dynamiquement un chunk dépendant à son tour du module A. Si une branche touche une variable qui n'a pas fini de s'initialiser, l'application plante lors du chargement. Ces échecs sont exaspérants car ils dépendent du timing. Un léger changement dans les points de fractionnement du bundler, un délai réseau lors du chargement du code ou un décalage dans la mise en cache des chunks peut modifier l'ordre juste assez pour déclencher la TDZ. Le plantage est imprévisible, et la stack trace pointe généralement vers une ligne de code parfaitement innocente.

Tactiques défensives

Vous ne pouvez pas compter sur les stack traces pour vous sauver des bugs de scope. Vous avez besoin de prévention et de détection.

Commencez par l'analyse statique. Configurez ESLint pour imposer des limites strictes. Des règles comme no-implicit-globals et no-shadow permettent de détecter les fautes les plus évidentes. Le shadowing est particulièrement traître car il vous laisse croire que vous modifiez une variable locale alors que vous créez en réalité une closure sur une variable externe, ou que vous créez un doublon accidentel. Ces règles imposent une intention explicite et éliminent les collisions silencieuses.

Profilez votre mémoire avec la même discipline que celle que vous appliquez à vos tests unitaires. Ouvrez Chrome DevTools, prenez un heap snapshot sur votre route de départ, naviguez dans votre application pendant cinq minutes, puis prenez-en un autre. Comparez les deux. Filtrez par « Closure » et cherchez les compteurs qui augmentent sans limite. Recherchez les nœuds DOM détachés qui conservent encore des event listeners. Si le second snapshot affiche des milliers de nouvelles entrées « Closure » alors que votre nombre d'utilisateurs est resté stable, vous avez des fonctions piégées qui retiennent des données piégées. C'est là que se trouve votre fuite.

Sur le plan architectural, arrêtez de piocher dans l'objet global window pour la configuration. Passez les paramètres via des props ou à travers un contexte typé. L'injection de dépendances n'est pas ici un mot à la mode du monde de l'entreprise ; c'est la pratique consistant à donner à une fonction tout ce dont elle a besoin via des arguments plutôt que de la laisser fouiller dans le scope global. Le résultat est un code que vous pouvez tester sans shims de navigateur, et des modules qui n'entrent pas en collision lorsque plusieurs applications sont montées à l'intérieur d'un même shell.

Enfin, respectez la phase de nettoyage sans pitié. Chaque addEventListener nécessite un removeEventListener correspondant à l'intérieur du nettoyage de l'effet (effect cleanup). Pour le travail asynchrone, utilisez un AbortController et passez son signal à fetch afin que les requêtes en cours soient annulées lorsque le composant est détruit. Ces habitudes contrôlent directement la durée de vie d'un scope. Ce n'est pas du boilerplate. C'est de la gestion de mémoire.

Ce que cela signifie pour votre équipe

Le scope n'est pas un tour de passe-passe pour piéger les candidats lors des entretiens. En production, le scope est de la gestion de mémoire. Chaque variable que vous déclarez est un otage potentiel. Chaque closure est une promesse que le moteur tiendra. Lorsque vous oubliez de libérer un écouteur, vous ne laissez pas simplement une lumière allumée. Vous attachez un poids à votre application et vous le jetez dans l'océan. Sur un matériel puissant, l'application nage quand même. Pour les utilisateurs d'appareils d'entrée de gamme, elle coule. Commencez à traiter le scope comme la ressource finie qu'il est. Vos utilisateurs, ainsi que vos sessions de débogage de trois heures, vous en remercieront.