Dominando el Estado de Módulos en JavaScript: Una Inmersión Profunda en Patrones de Gestión de Comportamiento

En el mundo del desarrollo de software moderno, el 'estado' es el fantasma en la máquina. Son los datos que describen la condición actual de nuestra aplicación: quién ha iniciado sesión, qué hay en el carrito de compras, qué tema está activo. Gestionar este estado de manera efectiva es uno de los desafíos más críticos que enfrentamos como desarrolladores. Cuando se maneja mal, conduce a comportamientos impredecibles, errores frustrantes y bases de código que aterroriza modificar. Cuando se maneja bien, resulta en aplicaciones robustas, predecibles y un placer de mantener.

JavaScript, con sus potentes sistemas de módulos, nos da las herramientas para construir aplicaciones complejas basadas en componentes. Sin embargo, estos mismos sistemas de módulos tienen implicaciones sutiles pero profundas en cómo se comparte —o se aísla— el estado a través de nuestro código. Entender los patrones de gestión de estado inherentes a los módulos de JavaScript no es solo un ejercicio académico; es una habilidad fundamental para construir aplicaciones profesionales y escalables. Esta guía te llevará a una inmersión profunda en estos patrones, pasando del comportamiento por defecto, implícito y a menudo peligroso, a patrones intencionales y robustos que te dan control total sobre el estado y el comportamiento de tu aplicación.

El Desafío Central: La Imprevisibilidad del Estado Compartido

Antes de explorar los patrones, primero debemos entender al enemigo: el estado mutable compartido. Esto ocurre cuando dos o más partes de tu aplicación tienen la capacidad de leer y escribir en la misma pieza de datos. Aunque suena eficiente, es una fuente principal de complejidad y errores.

Imagina un módulo simple responsable de rastrear la sesión de un usuario:

            // session.js
let sessionData = {};

export function setSessionUser(user) {
  sessionData.user = user;
  sessionData.loginTime = new Date();
}

export function getSessionUser() {
  return sessionData.user;
}

export function clearSession() {
  sessionData = {};
}
            

              
                Copy
              
            
          

Ahora, considera dos partes diferentes de tu aplicación que usan este módulo:

            // UserProfile.js
import { setSessionUser, getSessionUser } from './session.js';

export function displayProfile() {
  console.log(`Displaying profile for: ${getSessionUser().name}`);
}

// AdminDashboard.js
import { setSessionUser, clearSession } from './session.js';

export function impersonateUser(newUser) {
  console.log("Admin is impersonating a different user.");
  setSessionUser(newUser);
}

export function adminLogout() {
  clearSession();
}
            

              
                Copy
              
            
          

Si un administrador usa `impersonateUser`, el estado cambia para cada una de las partes de la aplicación que importa `session.js`. El componente `UserProfile` de repente mostrará información del usuario incorrecto, sin ninguna acción directa por su parte. Este es un ejemplo simple, pero en una aplicación grande con docenas de módulos interactuando con este estado compartido, la depuración se convierte en una pesadilla. Te quedas preguntando: "¿Quién cambió este valor y cuándo?".

Una Introducción a los Módulos de JavaScript y el Estado

Para entender los patrones, necesitamos abordar brevemente cómo funcionan los módulos de JavaScript. El estándar moderno, los Módulos ES (ESM), que utiliza la sintaxis `import` y `export`, tiene un comportamiento específico y crucial con respecto a las instancias de los módulos.

La Caché de Módulos ES: Un Singleton por Defecto

Cuando `importas` un módulo por primera vez en tu aplicación, el motor de JavaScript realiza varios pasos:

1. Resolución: Encuentra el archivo del módulo.
2. Análisis (Parsing): Lee el archivo y comprueba si hay errores de sintaxis.
3. Instanciación: Asigna memoria para todas las variables de nivel superior del módulo.
4. Evaluación: Ejecuta el código en el nivel superior del módulo.

La conclusión clave es esta: un módulo se evalúa solo una vez. El resultado de esta evaluación —los enlaces en vivo a sus exportaciones— se almacena en un mapa de módulos global (o caché). Cada vez que `importas` ese mismo módulo en cualquier otro lugar de tu aplicación, JavaScript no vuelve a ejecutar el código. En su lugar, simplemente te entrega una referencia a la instancia del módulo ya existente desde la caché. Este comportamiento convierte a cada módulo ES en un singleton por defecto.

Patrón 1: El Singleton Implícito - El Comportamiento por Defecto y sus Peligros

Como acabamos de establecer, el comportamiento por defecto de los Módulos ES crea un patrón singleton. El módulo `session.js` de nuestro ejemplo anterior es una ilustración perfecta de esto. El objeto `sessionData` se crea solo una vez, y cada parte de la aplicación que importa desde `session.js` obtiene funciones que manipulan ese único objeto compartido.

¿Cuándo es un Singleton la Elección Correcta?

Este comportamiento por defecto no es intrínsecamente malo. De hecho, es increíblemente útil para ciertos tipos de servicios a nivel de aplicación donde realmente quieres una única fuente de verdad:

• Gestión de Configuración: Un módulo que carga variables de entorno o configuraciones de la aplicación una vez al inicio y las proporciona al resto de la app.
• Servicio de Logging: Una única instancia de logger que se puede configurar (p. ej., nivel de log) y usar en todas partes para garantizar un registro consistente.
• Conexiones a Servicios: Un módulo que gestiona una única conexión a una base de datos o un WebSocket, evitando múltiples conexiones innecesarias.

            // config.js
const config = {
  apiKey: process.env.API_KEY,
  apiUrl: 'https://api.example.com',
  environment: 'production'
};

// Congelamos el objeto para evitar que otros módulos lo modifiquen.
Object.freeze(config);

export default config;
            

              
                Copy
              
            
          

En este caso, el comportamiento de singleton es exactamente lo que queremos. Necesitamos una única fuente inmutable de datos de configuración.

Las Trampas de los Singletons Implícitos

El peligro surge cuando este patrón singleton se utiliza involuntariamente para un estado que no debería compartirse globalmente. Los problemas incluyen:

• Acoplamiento Fuerte: Los módulos se vuelven implícitamente dependientes del estado compartido de otro módulo, lo que los hace difíciles de razonar de forma aislada.
• Pruebas Difíciles: Probar un módulo que importa un singleton con estado es una pesadilla. El estado de una prueba puede filtrarse a la siguiente, causando pruebas intermitentes o dependientes del orden. No puedes crear fácilmente una instancia nueva y limpia para cada caso de prueba.
• Dependencias Ocultas: El comportamiento de una función puede cambiar según cómo otro módulo, completamente no relacionado, haya interactuado con el estado compartido. Esto viola el principio de menor sorpresa y hace que el código sea extremadamente difícil de depurar.

Patrón 2: El Patrón Factory - Creando Estado Predecible y Aislado

La solución al problema del estado compartido no deseado es obtener un control explícito sobre la creación de instancias. El Patrón Factory es un patrón de diseño clásico que resuelve perfectamente este problema en el contexto de los módulos de JavaScript. En lugar de exportar la lógica con estado directamente, exportas una función que crea y devuelve una instancia nueva e independiente de esa lógica.

Refactorizando a un Factory

Refactoricemos un módulo de contador con estado. Primero, la versión singleton problemática:

            // counterSingleton.js
let count = 0;

export function increment() {
  count++;
}

export function getCount() {
  return count;
}
            

              
                Copy
              
            
          

Si `moduleA.js` llama a `increment()`, `moduleB.js` verá el valor actualizado cuando llame a `getCount()`. Ahora, convirtámoslo a un factory:

            // counterFactory.js
export function createCounter() {
  // El estado ahora está encapsulado dentro del ámbito de la función factory.
  let count = 0;

  // Se crea y devuelve un objeto que contiene los métodos.
  const counterInstance = {
    increment() {
      count++;
    },
    decrement() {
      count--;
    },
    getCount() {
      return count;
    }
  };

  return counterInstance;
}
            

              
                Copy
              
            
          

Cómo Usar el Factory

El consumidor del módulo ahora está explícitamente a cargo de crear y gestionar su propio estado. Dos módulos diferentes pueden obtener sus propios contadores independientes:

            // componentA.js
import { createCounter } from './counterFactory.js';

const myCounter = createCounter(); // Crear una nueva instancia
myCounter.increment();
myCounter.increment();
console.log(`Component A counter: ${myCounter.getCount()}`); // Salida: 2

// componentB.js
import { createCounter } from './counterFactory.js';

const anotherCounter = createCounter(); // Crear una instancia completamente separada
anotherCounter.increment();
console.log(`Component B counter: ${anotherCounter.getCount()}`); // Salida: 1

// El estado del contador del componente A permanece sin cambios.
console.log(`Component A counter is still: ${myCounter.getCount()}`); // Salida: 2
            

              
                Copy
              
            
          

Por Qué los Factories Sobresalen

• Aislamiento de Estado: Cada llamada a la función factory crea un nuevo closure, dando a cada instancia su propio estado privado. No hay riesgo de que una instancia interfiera con otra.
• Excelente Testeabilidad: En tus pruebas, puedes simplemente llamar a `createCounter()` en tu bloque `beforeEach` para asegurar que cada caso de prueba comience con una instancia nueva y limpia.
• Dependencias Explícitas: La creación de objetos con estado ahora es explícita en el código (`const myCounter = createCounter()`). Está claro de dónde viene el estado, lo que hace que el código sea más fácil de seguir.
• Configuración: Puedes pasar argumentos a tu factory para configurar la instancia creada, haciéndolo increíblemente flexible.

Patrón 3: El Patrón Basado en Constructor/Clase - Formalizando la Encapsulación del Estado

El patrón basado en Clases logra el mismo objetivo de aislamiento de estado que el patrón factory, pero utiliza la sintaxis `class` de JavaScript. A menudo es preferido por desarrolladores que vienen de entornos orientados a objetos y puede ofrecer una estructura más formal para objetos complejos.

Construyendo con Clases

Aquí está nuestro ejemplo de contador, reescrito como una clase. Por convención, el nombre del archivo y el nombre de la clase usan PascalCase.

            // Counter.js
export class Counter {
  // Usando un campo de clase privado para una verdadera encapsulación
  #count = 0;

  constructor(initialValue = 0) {
    this.#count = initialValue;
  }

  increment() {
    this.#count++;
  }

  decrement() {
    this.#count--;
  }

  getCount() {
    return this.#count;
  }
}

            

              
                Copy
              
            
          

Cómo Usar la Clase

El consumidor usa la palabra clave `new` para crear una instancia, lo cual es semánticamente muy claro.

            // componentA.js
import { Counter } from './Counter.js';

const myCounter = new Counter(10); // Crear una instancia comenzando en 10
myCounter.increment();
console.log(`Component A counter: ${myCounter.getCount()}`); // Salida: 11

// componentB.js
import { Counter } from './Counter.js';

const anotherCounter = new Counter(); // Crear una instancia separada comenzando en 0
anotherCounter.increment();
console.log(`Component B counter: ${anotherCounter.getCount()}`); // Salida: 1
            

              
                Copy
              
            
          

Comparando Clases y Factories

Para muchos casos de uso, la elección entre un factory y una clase es una cuestión de preferencia estilística. Sin embargo, hay algunas diferencias a considerar:

• Sintaxis: Las clases proporcionan una sintaxis más estructurada y familiar para los desarrolladores cómodos con la POO (Programación Orientada a Objetos).
• Palabra clave `this`: Las clases dependen de la palabra clave `this`, que puede ser una fuente de confusión si no se maneja correctamente (p. ej., al pasar métodos como callbacks). Los factories, usando closures, evitan `this` por completo.
• Herencia: Las clases son la opción clara si necesitas usar herencia (`extends`).
• `instanceof`: Puedes verificar el tipo de un objeto creado a partir de una clase usando `instanceof`, lo cual no es posible con objetos simples devueltos por factories.

Toma de Decisiones Estratégica: Eligiendo el Patrón Correcto

La clave para una gestión de comportamiento efectiva no es usar siempre un único patrón, sino entender las concesiones y elegir la herramienta adecuada para el trabajo. Consideremos algunos escenarios.

Escenario 1: Un Gestor de Feature Flags para toda la Aplicación

Necesitas una única fuente de verdad para los feature flags que se cargan una vez cuando la aplicación se inicia. Cualquier parte de la app debería poder comprobar si una función está habilitada.
Veredicto: El Singleton Implícito es perfecto aquí. Quieres un conjunto de flags único y consistente para todos los usuarios en una sola sesión.

Escenario 2: Un Componente de UI para un Diálogo Modal

Necesitas poder mostrar múltiples diálogos modales independientes en la pantalla al mismo tiempo. Cada modal tiene su propio estado (p. ej., abierto/cerrado, contenido, título).
Veredicto: Un Factory o una Clase es esencial. Usar un singleton significaría que solo podrías tener el estado de un modal activo en toda la aplicación a la vez. Un factory `createModal()` o `new Modal()` te permitiría gestionar cada uno de forma independiente.

Escenario 3: Una Colección de Funciones de Utilidad Matemática

Tienes un módulo con funciones como `sum(a, b)`, `calculateTax(amount, rate)` y `formatCurrency(value, currencyCode)`.
Veredicto: Esto requiere un Módulo sin Estado. Ninguna de estas funciones depende de o modifica ningún estado interno dentro del módulo. Son funciones puras cuya salida depende únicamente de sus entradas. Este es el patrón más simple y predecible de todos.

Consideraciones Avanzadas y Mejores Prácticas

Inyección de Dependencias para una Flexibilidad Máxima

Los factories y las clases facilitan la implementación de una técnica poderosa llamada Inyección de Dependencias. En lugar de que un módulo cree sus propias dependencias (como un cliente de API o un logger), se las pasas como argumentos. Esto desacopla tus módulos y los hace increíblemente fáciles de probar, ya que puedes pasar dependencias simuladas (mock).

            // createApiClient.js (Factory con Inyección de Dependencias)

// El factory toma un `fetcher` y un `logger` como dependencias.
export function createApiClient(config) {
  const { fetcher, logger, baseUrl } = config;

  return {
    async getUsers() {
      try {
        logger.log(`Fetching users from ${baseUrl}/users`);
        const response = await fetcher(`${baseUrl}/users`);
        return await response.json();
      } catch (error) {
        logger.error('Failed to fetch users', error);
        throw error;
      }
    }
  }
}

// En tu archivo principal de la aplicación:
import { createApiClient } from './createApiClient.js';
import { appLogger } from './logger.js';

const productionApi = createApiClient({ 
  fetcher: window.fetch, 
  logger: appLogger, 
  baseUrl: 'https://api.production.com'
});

// En tu archivo de prueba:
const mockFetcher = () => Promise.resolve({ json: () => Promise.resolve([{id: 1, name: 'test'}]) });
const mockLogger = { log: () => {}, error: () => {} };

const testApi = createApiClient({ 
  fetcher: mockFetcher, 
  logger: mockLogger, 
  baseUrl: 'https://api.test.com'
});
            

              
                Copy
              
            
          

El Papel de las Librerías de Gestión de Estado

Para aplicaciones complejas, podrías recurrir a una librería dedicada a la gestión de estado como Redux, Zustand o Pinia. Es importante reconocer que estas librerías no reemplazan los patrones que hemos discutido; se basan en ellos. La mayoría de las librerías de gestión de estado proporcionan un store singleton altamente estructurado para toda la aplicación. Resuelven el problema de los cambios impredecibles en el estado compartido no eliminando el singleton, sino aplicando reglas estrictas sobre cómo se puede modificar (p. ej., a través de acciones y reductores). Seguirás usando factories, clases y módulos sin estado para la lógica a nivel de componente y los servicios que interactúan con este store central.

Conclusión: Del Caos Implícito al Diseño Intencional

Gestionar el estado en JavaScript es un viaje de lo implícito a lo explícito. Por defecto, los módulos ES nos entregan una herramienta poderosa pero potencialmente peligrosa: el singleton. Confiar en este comportamiento por defecto para toda la lógica con estado conduce a un código fuertemente acoplado, no testeable y difícil de razonar.

Al elegir conscientemente el patrón adecuado para la tarea, transformamos nuestro código. Pasamos del caos al control.

• Usa el patrón Singleton deliberadamente para verdaderos servicios a nivel de aplicación como la configuración o el logging.
• Adopta los patrones Factory y de Clase para crear instancias de comportamiento aisladas e independientes, lo que lleva a componentes predecibles, desacoplados y altamente testeables.
• Aspira a tener módulos sin estado siempre que sea posible, ya que representan el pináculo de la simplicidad y la reutilización.

Dominar estos patrones de estado de módulo es un paso crucial para subir de nivel como desarrollador de JavaScript. Te permite arquitectar aplicaciones que no solo son funcionales hoy, sino que también son escalables, mantenibles y resistentes al cambio en los años venideros.