- Closures et scope en JavaScript : maîtriser la portée

Pourquoi maîtriser closures et scope ?

Closures et scope sont les deux concepts que tout développeur JavaScript croise dès la deuxième semaine d'apprentissage, et qui continuent à surprendre les seniors quinze ans plus tard. La quasi-totalité des bugs étranges en JavaScript (« pourquoi mon i vaut toujours 3 ? », « pourquoi ce listener garde une référence à mon composant ? », « pourquoi this change ici ? ») se ramène à une mauvaise lecture du scope ou d'une closure sous-jacente.

Pourtant, le mécanisme est rigoureux et limité à quelques règles. Une fois ces règles intériorisées, vous lisez le code comme le moteur le lit — vous voyez où vit chaque variable, qui la capture, et combien de temps elle survit en mémoire. Cet article propose un parcours complet : du moteur JavaScript jusqu'aux patterns modernes (hooks React, opérateurs RxJS, factories, memoization), avec les pièges qui ruinent encore des heures de debug en équipe.

Ce que vous saurez à la fin

• Comment le moteur construit la scope chain au moment du parsing.
• Pourquoi let et const ne sont pas seulement « plus propres » que var.
• Comment écrire une closure consciente, et quand elle vous fait perdre de la mémoire.
• Les patterns à connaître : module, currying, debounce, memoize, partial application.
• Comment les closures pilotent les hooks React, RxJS et l'async JavaScript moderne.

L'article s'adresse aussi bien à un développeur intermédiaire qui veut consolider ses bases qu'à un senior qui souhaite raffraîchir sa compréhension du Lexical Environment et de la chaîne de portée. Tous les exemples sont écrits en JavaScript ES2022, exécutables tels quels dans une console moderne ou un fichier Node récent — vous pouvez les coller au fur et à mesure pour valider chaque concept au moment où il est introduit.

Comment le moteur JS crée les scopes

Quand V8 (Chrome, Node) ou SpiderMonkey (Firefox) compile votre code, il associe à chaque fonction et chaque bloc un Lexical Environment. C'est un objet interne (vous ne pouvez pas y accéder directement) qui stocke deux choses : les bindings (variables déclarées dans cette portée) et une référence à l'environnement parent. Cette chaîne de références est la fondation de tout.

Schéma mental — l'Execution Context

// fichier app.js
const app = 'App';

function outer() {
  const a = 1;

  function inner() {
    const b = 2;
    console.log(app, a, b); // accès aux 3 niveaux
  }

  inner();
}

outer();

Au moment de l'exécution de inner(), le moteur a en mémoire trois environnements liés : celui de inner (qui contient b), celui de outer (qui contient a), et l'environnement global (qui contient app). La résolution d'une variable consiste à remonter cette chaîne jusqu'à trouver le binding ou échouer avec une ReferenceError.

Conséquence pratique

Cette structure est figée à la compilation — d'où le terme lexical. Renommer une fonction, la déplacer dans un autre fichier, l'appeler depuis n'importe où : son environnement lexical reste celui de son lieu de déclaration. C'est exactement ce qui rend les closures possibles : la fonction interne emporte avec elle la référence à l'environnement parent, même quand celui-ci a quitté la pile d'appels.

Deux phases d'exécution — Création puis Exécution

Chaque contexte d'exécution (global ou fonction) traverse deux phases. En phase de création, le moteur scanne le code et inscrit les déclarations dans l'environnement : c'est le hoisting des function complets, des var initialisées à undefined, et des let/const placées en Temporal Dead Zone. En phase d'exécution, les lignes sont parcourues une à une, les variables prennent leurs valeurs, et les fonctions sont éventuellement appelées. Cette séparation explique pourquoi vous pouvez appeler une fonction function déclarée plus bas dans le fichier, mais pas accéder à une const avant sa ligne.

Les trois types de scope : global, fonction, bloc

Chaque déclaration en JavaScript appartient à l'un de ces trois niveaux. Connaître la table de correspondance évite 90 % des bugs liés à la portée.

1. Global — visible partout

// En navigateur : attaché à window (sauf modules ES)
// En Node : attaché à globalThis
const APP_VERSION = '1.0.0';

function showVersion() {
  console.log(APP_VERSION); // accessible
}

Dans un module ES (<script type="module"> ou import/export), les déclarations au top-level ne sont pas globales — elles sont locales au module. C'est une excellente nouvelle pour éviter les collisions, mais surprend ceux qui viennent du JS classique.

2. Fonction — visible dans toute la fonction

function fetchUser() {
  var url = '/api/me'; // visible dans toute la fonction
  if (true) {
    var url = '/api/admin'; // ré-assigne le même binding !
  }
  console.log(url); // '/api/admin' — pas de scope de bloc avec var
}

3. Bloc — visible entre accolades (let/const)

function fetchUser() {
  const url = '/api/me';
  if (true) {
    const url = '/api/admin'; // nouvelle variable, scope du if
    console.log(url); // '/api/admin'
  }
  console.log(url); // '/api/me' — la variable du if a disparu
}

var, let, const — hoisting et Temporal Dead Zone

Le choix du mot-clé influence trois choses : la portée, le hoisting, et la possibilité de réassignation. Tableau récapitulatif d'abord, explications ensuite.

Hoisting de var — la surprise classique

console.log(name); // undefined — pas une ReferenceError !
var name = 'Alice';
// Le moteur lit comme :
// var name;          // hoisté en haut de la fonction, init undefined
// console.log(name); // undefined
// name = 'Alice';

Temporal Dead Zone avec let/const

console.log(name); // ❌ ReferenceError: Cannot access 'name' before initialization
let name = 'Alice';
// La déclaration est connue par le moteur, mais l'accès avant la ligne
// est interdit — c'est la TDZ, une protection contre les bugs sournois.

const ne fige PAS le contenu d'un objet

const user = { name: 'Alice' };
user.name = 'Bob';     // OK — on mute la propriété, pas la référence
user = { name: 'X' };  // ❌ TypeError — réassignation interdite

// Pour figer le contenu, utilisez Object.freeze() :
const config = Object.freeze({ apiUrl: '/api' });
config.apiUrl = 'X'; // silencieux en mode non-strict, échoue en strict

La scope chain et la résolution des variables

Quand le moteur rencontre une référence à x, il regarde le scope local. Pas trouvé ? Il remonte au parent. Pas trouvé ? Il remonte encore. Si la chaîne s'achève sans match, c'est une ReferenceError. Cette résolution est appelée la scope chain ou variable lookup.

Exemple multi-niveaux

const root = 'Root';

function level1() {
  const a = 'A1';

  function level2() {
    const b = 'B2';

    function level3() {
      const c = 'C3';
      // Le moteur cherche dans cet ordre :
      console.log(c);    // 1. local — trouvé
      console.log(b);    // 2. local non, parent level2 — trouvé
      console.log(a);    // 3. local, level2, level1 — trouvé
      console.log(root); // 4. local, level2, level1, global — trouvé
      // console.log(z); // ReferenceError — bout de chaîne
    }
    level3();
  }
  level2();
}
level1();

Shadowing — quand un nom existe à plusieurs niveaux

const x = 'global';

function showX() {
  const x = 'local';  // shadow — masque la version globale
  console.log(x);     // 'local' — la version la plus proche gagne
}

showX();
console.log(x); // 'global' — intact

Le shadowing est utile mais piégeux : il rend le code difficile à scanner visuellement. Les linters proposent une règle no-shadow pour bannir ce pattern en équipe. À utiliser avec parcimonie, jamais sur des noms ambigus comme data, value ou i.

Closures — la définition technique

Définition officielle (ECMAScript) : une closure est une fonction associée à l'environnement lexical dans lequel elle a été créée. Définition pragmatique : une fonction qui se souvient des variables d'où elle vient, même quand son scope parent a disparu.

L'exemple minimal qui illustre tout

function createCounter() {
  let count = 0;                      // variable du scope parent
  return function increment() {       // fonction retournée
    count++;                          // capture "count" par référence
    return count;
  };
}

const counter = createCounter();
counter(); // 1
counter(); // 2
counter(); // 3
// La fonction createCounter() s'est terminée bien avant les appels —
// pourtant count survit, parce qu'increment garde une référence vivante.

Deux compteurs indépendants — preuve d'encapsulation

const a = createCounter();
const b = createCounter();
a(); a(); a(); // a a son propre count = 3
b();           // b a son propre count = 1
// Chaque appel à createCounter() produit un NOUVEL environnement,
// donc un nouveau count, capturé par sa propre closure.

Cas d'usage fondamentaux

1. État privé — l'alternative à la classe

function createBankAccount(initialBalance) {
  let balance = initialBalance; // variable privée — invisible de l'extérieur

  return {
    deposit(amount) {
      if (amount <= 0) throw new Error('Montant invalide');
      balance += amount;
      return balance;
    },
    withdraw(amount) {
      if (amount > balance) throw new Error('Solde insuffisant');
      balance -= amount;
      return balance;
    },
    getBalance: () => balance,
  };
}

const acc = createBankAccount(100);
acc.deposit(50);   // 150
acc.withdraw(30);  // 120
acc.balance;       // undefined — impossible d'accéder directement
// La seule façon de lire ou modifier balance est via les méthodes exposées.

2. Factory de fonctions configurées

// Génère une fonction d'assertion personnalisée
function createLogger(prefix) {
  return function log(message) {
    console.log(`[${prefix}]`, message);
  };
}

const authLog = createLogger('AUTH');
const apiLog  = createLogger('API');

authLog('Login attempt'); // [AUTH] Login attempt
apiLog('GET /users');     // [API] GET /users

3. Callback qui capture le moment de sa création

function scheduleNotifications(messages) {
  messages.forEach((msg, i) => {
    // Chaque callback capture sa propre valeur de msg grâce au scope de bloc
    setTimeout(() => {
      console.log(`Notif ${i + 1} :`, msg);
    }, i * 1000);
  });
}

scheduleNotifications(['Bienvenue', 'Mise à jour', 'Au revoir']);
// Affiche les 3 messages à 1s d'intervalle, chacun avec son propre i.

Patterns avancés : module, debounce, memoize, currying

1. Pattern Module (style IIFE — legacy)

const calculator = (function() {
  const PI = 3.14159; // privé

  function circleArea(r)   { return PI * r * r; }
  function circumference(r) { return 2 * PI * r; }

  return { circleArea, circumference };
})();

calculator.circleArea(5);     // 78.539...
calculator.PI;                // undefined — bien protégé

Aujourd'hui ce pattern est largement remplacé par les modules ES (export/import), qui offrent la même encapsulation avec un meilleur outillage (tree-shaking, types, devtools). Connaître le pattern IIFE reste utile pour lire du code legacy.

2. Currying — décomposer un appel multi-arguments

// Conversion d'une fonction (a, b, c) en (a)(b)(c)
const add = a => b => c => a + b + c;
add(1)(2)(3); // 6

// Cas pratique : créer des fonctions spécialisées à partir d'une plus générale
const fetchAt = baseUrl => endpoint => (params) =>
  fetch(`${baseUrl}${endpoint}?${new URLSearchParams(params)}`);

const fetchGithub = fetchAt('https://api.github.com');
const fetchRepos  = fetchGithub('/users/torvalds/repos');
fetchRepos({ per_page: 10 });

3. Debounce — closure sur un timer

function debounce(fn, delay) {
  let timerId; // privé à la closure renvoyée

  return function(...args) {
    clearTimeout(timerId);
    timerId = setTimeout(() => fn.apply(this, args), delay);
  };
}

const search = debounce((query) => {
  console.log('Recherche :', query);
}, 300);

// 5 frappes rapides → un seul appel après 300ms
search('a'); search('ab'); search('abc'); search('abcd'); search('abcde');

4. Memoize — closure sur un cache

function memoize(fn) {
  const cache = new Map(); // privé, vivant tant que la closure existe

  return function(...args) {
    const key = JSON.stringify(args);
    if (cache.has(key)) return cache.get(key);
    const result = fn.apply(this, args);
    cache.set(key, result);
    return result;
  };
}

const slowFib = (n) => n < 2 ? n : slowFib(n - 1) + slowFib(n - 2);
const fastFib = memoize(slowFib);
fastFib(35); // calcul lent une fois, puis instantané pour les mêmes args

5. Partial application — figer les premiers arguments

const partial = (fn, ...preset) => (...rest) => fn(...preset, ...rest);

const log = (level, message) => console.log(`[${level}] ${message}`);
const warn = partial(log, 'WARN');
warn('Latence élevée'); // [WARN] Latence élevée
warn('Stock faible');   // [WARN] Stock faible

Closures dans le JS moderne (React, RxJS, async)

Si vous écrivez du React, du RxJS, du NestJS ou du code Node moderne, vous écrivez des closures en permanence — souvent sans en avoir conscience. En voici trois exemples concrets.

React — useState et la closure stale

function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const id = setInterval(() => {
      // ❌ closure stale — capture count = 0 au montage
      // setCount(count + 1);
      // ✅ utiliser la forme fonction qui reçoit la valeur courante
      setCount(c => c + 1);
    }, 1000);
    return () => clearInterval(id);
  }, []); // [] = effect créé une seule fois → closure figée
}

Ce bug est l'un des plus fréquents en code React. La fonction passée à useEffect est créée une fois ; elle capture count = 0 et ne le verra jamais changer. La forme setCount(c => c + 1) évite la capture en demandant la valeur courante au moment de la mise à jour.

RxJS — chaque opérateur est une closure

import { fromEvent, map, filter, debounceTime } from 'rxjs';

const minLength = 3;

fromEvent<KeyboardEvent>(input, 'input')
  .pipe(
    map((e) => (e.target as HTMLInputElement).value), // ferme sur e
    filter((q) => q.length >= minLength),             // ferme sur minLength
    debounceTime(300),
  )
  .subscribe((q) => console.log('Recherche :', q));

Chaque opérateur map/filter/debounceTime renvoie un Observable qui encapsule une closure sur sa fonction-paramètre et les variables environnantes. Comprendre ce mécanisme permet de débuguer pourquoi un filter(q => q.length >= minLength) ne « voit » pas la nouvelle valeur de minLength changée plus tard — la closure capture la référence au moment du pipe().

async/await — closures qui survivent à await

async function processOrders(orders) {
  const results = [];

  for (const order of orders) {
    // La closure capture order, results, et les await sont des points de pause.
    const data = await fetch(`/api/orders/${order.id}`);
    results.push(await data.json());
  }

  return results; // results reste accessible — closure intacte
}

Entre deux await, l'environnement lexical entier est préservé par le moteur. C'est la raison pour laquelle async/await ressemble tant à du code synchrone : techniquement, c'est une suite de closures restaurées par le runtime à chaque reprise.

Pièges classiques et anti-patterns

Piège 1 — var dans une boucle (le bug légendaire)

// ❌ Avec var — toutes les closures partagent le MÊME i
const funcs = [];
for (var i = 0; i < 3; i++) {
  funcs.push(() => console.log(i));
}
funcs[0](); // 3
funcs[1](); // 3
funcs[2](); // 3
// Quand on appelle funcs[0], la boucle est terminée → i vaut 3 partout.

// ✅ Avec let — chaque itération crée une nouvelle variable de bloc
const funcs = [];
for (let i = 0; i < 3; i++) {
  funcs.push(() => console.log(i));
}
funcs[0](); // 0
funcs[1](); // 1
funcs[2](); // 2

Piège 2 — fuite mémoire via event listeners

// ❌ La closure du listener garde largeData en mémoire pour toujours
function attachListener(id) {
  const largeData = new Array(1_000_000).fill({}); // 100Mo
  const el = document.getElementById(id);
  el.addEventListener('click', () => {
    console.log('Clicked!', largeData.length);
  });
}

// ✅ Solution 1 — ne capture pas ce qu'il ne faut pas
function attachListener(id) {
  const el = document.getElementById(id);
  el.addEventListener('click', () => console.log('Clicked!'));
}

// ✅ Solution 2 — listener détachable via AbortController
function attachListener(id, signal) {
  const el = document.getElementById(id);
  el.addEventListener('click', handleClick, { signal });
}
const ctrl = new AbortController();
attachListener('btn', ctrl.signal);
// Plus tard, pour tout nettoyer en une ligne :
ctrl.abort();

Piège 3 — closure stale dans un setTimeout/setInterval

// ❌ Capture une référence figée
function startCountdown(seconds) {
  let remaining = seconds;
  const interval = setInterval(() => {
    console.log(remaining);
    if (--remaining < 0) clearInterval(interval);
  }, 1000);
}
// Ici la closure marche bien car remaining est modifié au bon endroit.

// ❌ Mauvais usage — remaining n'est pas dans la closure
function startCountdown(seconds) {
  setInterval(() => console.log(seconds--), 1000);
  // seconds est un paramètre — mais on attendrait que la valeur
  // décrémente APRÈS l'affichage : off-by-one classique.
}

Piège 4 — this perdu dans une callback

class Counter {
  count = 0;

  start() {
    // ❌ Arrow function capture this lexicalement — OK
    setInterval(() => this.count++, 1000);

    // ❌ Fonction normale — this n'est PAS la classe
    // setInterval(function() { this.count++; }, 1000);

    // ✅ Si on doit utiliser une function classique, bind :
    // setInterval(function() { this.count++; }.bind(this), 1000);
  }
}

Note : this n'est pas capturé par une closure normale — il est résolu dynamiquement à l'appel, sauf pour les arrow functions qui le capturent lexicalement. C'est pourquoi les arrow functions sont devenues le défaut dans les callbacks de classe.

Performance, mémoire et garbage collection

Une closure n'est ni gratuite ni catastrophique. Comprendre son coût réel évite à la fois la paranoia (« supprimons toutes les closures ! ») et l'aveuglement (« utilisons des closures partout ! »).

Comment le GC raisonne

• Le moteur retient une variable tant qu'au moins une référence vivante existe vers elle.
• Une closure qui n'utilise pas une variable parente n'empêche pas le GC de la libérer. Les moteurs modernes (V8, SpiderMonkey) optimisent en ne capturant que les variables effectivement référencées.
• Une closure abandonnée (plus de référence externe) est elle-même éligible au GC, libérant toutes ses captures.

Erreurs qui freinent l'optimisation V8

// ❌ "Mega-closure" — l'arrow function capture TOUT le scope parent même
// si elle n'en utilise qu'un bout. Évitez les fonctions énormes qui retournent
// des callbacks utilisant un seul champ.
function bigContext(huge1, huge2, huge3) {
  // 200 lignes de code…
  return () => huge3.id; // V8 garde huge1 et huge2 en mémoire si conservatif
}

// ✅ Découper en sortant les variables strictement nécessaires
function smallContext(id) {
  return () => id;
}

Mesurer une fuite

• Chrome DevTools → onglet Memory → Heap Snapshot. Cherchez vos closures par classe (« Closure »).
• L'option Comparison entre deux snapshots montre les objets ajoutés non libérés — souvent des listeners non détachés.
• Utilisez WeakMap et WeakRef quand vous voulez associer des métadonnées à des objets sans empêcher leur GC.

Closure vs classe — quand choisir quoi

Une closure factory et une classe ES2015 résolvent souvent le même problème : encapsuler un état et exposer des méthodes pour le manipuler. Le choix dépend de trois critères. Lisibilité : sur un cas simple (compteur, debounce, factory de logger), la closure tient en cinq lignes. Une classe demande plus de boilerplate. Héritage et polymorphisme : si vous avez plusieurs variantes qui partagent du comportement, une classe avec extends structure mieux le code. Privé strict : les champs #private d'ES2022 offrent une privacy aussi forte que celle d'une closure, et restent plus performants quand on instancie des milliers d'objets — chaque closure recrée ses méthodes, là où une classe les partage via le prototype.

Mini-projet appliqué — store réactif via closures

Pour ancrer les patterns vus dans un cas concret, voici un mini store réactif (style Signal/Pinia/Zustand) écrit uniquement avec des closures. Aucune classe, aucun framework — juste des fonctions imbriquées qui exploitent le scope lexical pour encapsuler l'état, gérer les subscribers, et exposer une API publique propre. C'est le pattern qui propulse les Signals Angular, les stores Zustand, et les hooks React.

1. Factory createStore — état privé via closure

function createStore(initialValue) {
    // État PRIVÉ — inaccessible depuis l'extérieur grâce à la closure
    let value = initialValue;
    const subscribers = new Set();

    // API PUBLIQUE — chaque méthode est une closure sur value + subscribers
    return {
        get() {
            return value;
        },
        set(newValue) {
            if (Object.is(value, newValue)) return; // skip notif identique
            value = newValue;
            subscribers.forEach(fn => fn(value));
        },
        update(updater) {
            this.set(updater(value));
        },
        subscribe(fn) {
            subscribers.add(fn);
            // Retourner une closure de nettoyage
            return () => subscribers.delete(fn);
        },
    };
}

// Usage
const counter = createStore(0);
const unsub = counter.subscribe(v => console.log('count =', v));

counter.set(1);          // → "count = 1"
counter.update(v => v + 1); // → "count = 2"
counter.set(2);          // (rien — Object.is égal)

unsub();                 // se désinscrit, la closure se libère

2. computed — dérivation paresseuse via closure

Pour comparer ce pattern à un système réactif complet, voir le guide Angular Signals guide complet.

function createComputed(deps, computeFn) {
    // Cache du dernier résultat — privé via closure
    let cachedValue;
    let dirty = true;
    const subscribers = new Set();

    // Recalcul on-demand
    function recompute() {
        if (!dirty) return cachedValue;
        cachedValue = computeFn(...deps.map(d => d.get()));
        dirty = false;
        return cachedValue;
    }

    // Marquer dirty quand une dépendance change
    deps.forEach(dep => {
        dep.subscribe(() => {
            dirty = true;
            // Propager aux subscribers du computed
            const newValue = recompute();
            subscribers.forEach(fn => fn(newValue));
        });
    });

    return {
        get: recompute,
        subscribe(fn) {
            subscribers.add(fn);
            return () => subscribers.delete(fn);
        },
    };
}

// Usage : computed dérivé de 2 stores
const firstName = createStore('Alice');
const lastName = createStore('Dupont');
const fullName = createComputed([firstName, lastName], (f, l) => `${f} ${l}`);

console.log(fullName.get()); // "Alice Dupont"
firstName.set('Bob');
console.log(fullName.get()); // "Bob Dupont" — recalculé paresseusement

3. persistedStore — composition de closures avec localStorage

Pour le détail du choix entre localStorage, sessionStorage et cookies, voir le comparatif complet.

function createPersistedStore(key, initialValue) {
    // Lecture initiale depuis localStorage si présent
    const stored = localStorage.getItem(key);
    const start = stored !== null ? JSON.parse(stored) : initialValue;

    const inner = createStore(start);

    // Wrap set/update pour persister à chaque écriture
    const originalSet = inner.set;
    inner.set = function (newValue) {
        originalSet.call(inner, newValue);
        localStorage.setItem(key, JSON.stringify(newValue));
    };

    return inner;
}

// Usage : préférences utilisateur persistantes
const theme = createPersistedStore('app:theme', 'light');
theme.subscribe(v => document.documentElement.dataset.theme = v);

theme.set('dark'); // → écrit dans localStorage + notifie le subscriber

4. createDebounced — fonction utilitaire avec état privé

Pour le pattern debounce complet, voir l'article dédié sur debounce et throttle.

function createDebounced(fn, delay) {
    // timer est une variable privée capturée par closure
    let timer = null;

    // La fonction retournée est une closure sur timer + fn + delay
    return function (...args) {
        clearTimeout(timer);
        timer = setTimeout(() => fn(...args), delay);
    };
}

// Usage : recherche débouncée avec store réactif
const searchQuery = createStore('');
const debouncedSearch = createDebounced((q) => {
    fetch(`/api/search?q=${encodeURIComponent(q)}`)
        .then(r => r.json())
        .then(results => console.log('Results:', results));
}, 300);

// Composition : store + debounce
searchQuery.subscribe(debouncedSearch);

// Simuler frappe utilisateur
['a', 'an', 'ang', 'angu', 'angul'].forEach(q => searchQuery.set(q));
// Une seule requête déclenchée 300ms après le dernier set

5. Pattern Module ES — l'évolution moderne des closures

Le pattern module via IIFE (Immediately Invoked Function Expression) était la norme avant ES6. Aujourd'hui, les modules ES remplacent cette pratique avec une syntaxe plus claire mais le même principe : encapsulation via scope.

// store.js — module ES moderne
// Les variables top-level d'un module sont PRIVÉES (pas globales)
let value = 0;
const subscribers = new Set();

export function get() { return value; }
export function set(v) {
    value = v;
    subscribers.forEach(fn => fn(value));
}
export function subscribe(fn) {
    subscribers.add(fn);
    return () => subscribers.delete(fn);
}

// app.js — consommateur
import { get, set, subscribe } from './store.js';
// `value` et `subscribers` sont inaccessibles depuis ici — encapsulation native

Ce que ce mini-projet démontre

• Les closures = encapsulation native : value et subscribers n'existent QUE dans le scope de createStore — impossible d'y accéder par accident.
• Une closure est une fonction + son environnement — chaque appel à createStore produit un nouvel environnement isolé.
• L'inscription/désinscription retourne une closure de nettoyage — pattern essentiel pour éviter les fuites mémoire.
• Composition fonctionnelle — createPersistedStore wrap createStore sans aucun héritage de classe.
• Les modules ES sont l'évolution moderne — même principe d'encapsulation, syntaxe plus claire, support natif du tree-shaking et du lazy loading. Pour structurer un gros projet, lire le guide modules + barrel exports + path aliasing.

Pour pousser ce pattern à l'échelle d'une appli complète, lire également le guide du destructuring pour exposer proprement une API publique multi-méthodes.

Conclusion

Scope et closures sont la mécanique cachée derrière chaque ligne de JavaScript que vous écrivez. Le scope est lexical — déterminé par la position du code dans le fichier — et la closure n'est que la conséquence naturelle de ce choix de conception : une fonction emporte avec elle une référence à son environnement de naissance, et reste capable de l'utiliser bien après que son créateur ait disparu.

En adoptant const par défaut, en réservant let aux compteurs explicites, et en bannissant var du code moderne, vous éliminez d'entrée 80 % des bugs de portée. En reconnaissant les closures dans les hooks React, les opérateurs RxJS et les callbacks async, vous comprenez pourquoi votre useEffect capture une valeur figée — et comment y remédier sans hack. Ces concepts vous suivront tout au long de votre carrière JavaScript : ils sont stables, transverses, et fondent tous les frameworks que vous utiliserez demain.