¿Por qué mutar directamente un objeto del estado (state.items.push(x)) rompe el planificador de React?

React se basa en comparaciones superficiales (Object.is) entre el estado anterior y el nuevo. Una mutación in-place modifica los datos internos pero preserva la misma referencia en memoria. En consecuencia, React asume que no hubo cambios y omite el renderizado necesario, quebrando el funcionamiento del scheduler y las características de Concurrent Mode.

¿Qué es una Stale Closure en hooks de React y por qué se produce?

Una Stale Closure ocurre cuando una función retiene referencias a variables del ámbito léxico de un render anterior. Sucede comúnmente al usar useCallback, useMemo o useEffect con arrays de dependencias incompletos. La función no se recrea ante cambios de estado y continúa accediendo a los valores congelados al momento de su instanciación.

¿Cómo resuelve el AbortController las condiciones de carrera en useEffect?

El efecto instancia un AbortController y suministra su signal a fetch. En la función de limpieza del efecto se invoca controller.abort(). Si las dependencias cambian con rapidez, la petición previa se interrumpe de inmediato a nivel de socket en el navegador, impidiendo que una respuesta obsoleta sobrescriba el estado más reciente.

¿Por qué React StrictMode ejecuta dos veces los renders y remonta los efectos en desarrollo?

El renderizado doble comprueba que las funciones de los componentes sean puras y carezcan de efectos secundarios. El remontaje de efectos (mount -> unmount -> mount) valida que las rutinas de limpieza funcionen correctamente, asegurando que no queden listeners, intervalos o suscripciones huérfanas.

¿Cómo se asocia una señal de cancelación directamente a addEventListener?

El método nativo addEventListener admite un objeto de opciones en su tercer argumento: target.addEventListener(type, listener, { signal: controller.signal }). Al invocar controller.abort(), el navegador desvincula el listener automáticamente sin necesidad de llamar a removeEventListener con la referencia exacta de la función.

¿Por qué se eliminó la advertencia 'Can't perform a React state update on an unmounted component' en React 18/19?

El equipo central de React la retiró porque los desarrolladores la silenciaban sistemáticamente con comprobaciones superficiales como if (!isMounted.current) return. Esto no solucionaba las fugas de memoria causadas por suscripciones persistentes o promesas no canceladas. React reorientó las buenas prácticas hacia la limpieza activa con AbortController.

¿Qué son los 'Detached DOM Elements' en el perfilador de memoria de Chrome DevTools?

Son nodos del DOM eliminados del documento HTML activo que el recolector de basura no puede liberar porque alguna referencia en JavaScript (un array global, un listener huérfano o una clausura en un hook) continúa reteniéndolos. Representan uno de los síntomas más habituales de fugas de memoria severas en frontend.

Antipatrones en React: fugas de memoria, stale closures y condiciones de carrera en efectos asíncronos — React 19 Core y Arquitectura

Por qué es importante#

En el modelo declarativo de React 19, un componente se diseña como una función pura que transforma props y estado en una representación visual. Sin embargo, al interactuar con el entorno imperativo del navegador (temporizadores setInterval, sockets persistentes, suscripciones a eventos de window, cadenas de promesas asíncronas), surgen defectos latentes capaces de degradar o cerrar la pestaña del cliente.

En aplicaciones SPA corporativas con sesiones prolongadas (paneles de control, terminales financieras, plataformas de analítica), una gestión descuidada de los efectos secundarios provoca tres anomalías críticas:

Memory Leak (Fuga de memoria) — La pestaña pasa de 80 MB a 1.5 GB en 2–3 horas de uso hasta que el navegador finaliza forzosamente el proceso por falta de memoria (Out Of Memory).
Stale Closure (Clausura obsoleta) — La función opera sobre valores desactualizados del render previo, enviando identificadores obsoletos al servidor o perdiendo eventos de usuario.
Race Condition (Condición de carrera) — Desincronización de estado: el usuario selecciona la pestaña 2, pero una respuesta tardía de la pestaña 1 sobrescribe la pantalla con datos desfasados.

Para resolver estas vulnerabilidades en React 19 se requiere una estricta disciplina de limpieza (Cleanup Phase), el uso sistemático de AbortController y el análisis de la memoria con capturas de Heap (Heap Snapshot).

Modelo mental#

Anatomía típica de una condición de carrera y fuga de recursos en efectos:

text

Render #1 (Petición A, ID=10) ──────────► [Petición de red A (lenta, 1200 ms)]
      │                                                │
      ▼                                                ▼
El usuario hace clic en Tab 2                          │
      │                                                │
      ▼                                                │
Render #2 (Petición B, ID=11) ──► [Petición B (rápida, 150 ms)]
                                       │               │
                                       ▼               │
                         UI actualizada con datos B    │
                                                       ▼
                                     ¡Petición A termina al final!
                                     stateUpdate(A) sobrescribe la UI!
                                     ──► [BUG: La UI muestra datos obsoletos del ID=10]

Si el componente se desmonta antes de que la Petición A responda:

text

[Componente Desmontado] ◄── [Clausura dentro de Promise.then()] ◄── [Macrotask]
          │
          └── ¡No puede ser liberado por el Garbage Collector (Detached DOM Element)!

Detached DOM Elements
StrictMode Double Render
AbortSignal
Heap Snapshot

Diagnóstico y resolución de fugas de memoria en Chrome DevTools

Captura de referencia inicial (Baseline Heap Snapshot)Paso 1: Snapshot 1

Abre la pestaña Memory en Chrome DevTools, fuerza la recolección de basura (icono de papelera) y toma el Heap snapshot 1.

Ciclo de estrés de montaje y desmontajePaso 2: Churn

Abre el modal o vista bajo sospecha, realiza las interacciones principales y ciérralo por completo de 5 a 10 veces.

Segunda captura de control (Target Snapshot)Paso 3: Snapshot 2

Vuelve a forzar la recolección de basura para limpiar memoria transitoria y genera el Heap snapshot 2.

Comparación de capturas en vista ComparisonPaso 4: Diffing

Selecciona el filtro 'Objects allocated between Snapshot 1 and 2'. Filtra por nombre del componente o Detached HTMLElement.

Análisis del árbol de retención (Retainer Tree)Paso 5: Retainer

En el panel inferior Retainers localiza la raíz de la fuga: un listener de window huérfano, un setInterval o una clausura de promesa.

PUNTO DE CONTROL

Comprobación de conocimientos: Stale Closures en useCallback

+15 XP

Considera este código de botón: const [count, setCount] = useState(0); const inc = useCallback(() => { setCount(count + 1); }, []);. ¿Por qué al hacer clic repetidamente el valor del contador no pasa de 1?

Aplicaciones en entornos reales#

Paneles analíticos multiinquilino: Los usuarios cambian filtros de fechas con mayor rapidez de la que el servidor puede responder. Sin cancelar peticiones con AbortController, los gráficos muestran datos desordenados y desincronizados.
SPAs corporativas de larga duración: En CRMs activos durante toda la jornada, abrir diálogos sin limpiar setInterval acumula procesos en segundo plano hasta agotar la CPU.
Autocompletado de búsqueda (Typeahead Search): Al escribir y corregir términos con rapidez, una respuesta demorada de los primeros caracteres puede sobrescribir los resultados de la consulta actual.
Feeds por WebSocket y chats en vivo: Al abandonar una pantalla con conexión en tiempo real, el socket debe cerrarse de inmediato para evitar que continúe parseando mensajes en segundo plano.

Arquitectura y análisis profundo#

1. Ciclo de vida de un efecto asíncrono blindado con cancelación#

Canalización de arquitectura

Ciclo de vida de un efecto asíncrono blindado con cancelación

4 etapas

1. Montaje del efecto

useEffect InitNúcleo / Sistema

Instanciación de un nuevo objeto AbortController() y extracción de su AbortSignal.

Artefactos:AbortControllerAbortSignal

2. Envío de la operación de red

fetch(url, { signal })Núcleo / Sistema

Envío de la petición HTTP asociando la señal de cancelación al socket del navegador.

Artefactos:HTTP RequestSocket Connection

3. Cambio de dependencias o desmontaje

Trigger CleanupPlantilla / UI

El usuario cambia de entidad o navega a otra ruta. React invoca la función de retorno de cleanup.

Artefactos:Component UnmountDependency Change

4. Cancelación física de la conexión

controller.abort()Núcleo / Sistema

El navegador interrumpe la conexión (DOMException: AbortError), liberando la memoria en V8.

Artefactos:Abort NotificationGC Reclaim

2. Mutación de estado y props durante la fase de render#

React exige que el cuerpo del componente sea idempotente (una función pura). Cualquier mutación directa sobre las props o estructuras globales durante el cálculo del JSX rompe el algoritmo de reconciliación:

tsx

// ❌ Antipatrón severo: mutar las props directamente durante el cálculo del JSX
export function UserList({ users }: { users: string[] }) {
  // sort() muta el array original in-place, alterando referencias y rompiendo la memoización del padre
  const sortedUsers = users.sort();

  return (
    <ul>
      {sortedUsers.map((u) => (
        <li key={u}>{u}</li>
      ))}
    </ul>
  );
}

// ✅ Solución correcta: copia inmutable o useMemo
export function UserListFixed({ users }: { users: string[] }) {
  const sortedUsers = useMemo(() => {
    return [...users].sort();
  }, [users]);

  return (
    <ul>
      {sortedUsers.map((u) => (
        <li key={u}>{u}</li>
      ))}
    </ul>
  );
}

Bajo <React.StrictMode>, React invoca los renders dos veces (Double Render) en desarrollo para poner en evidencia mutaciones indebidas y efectos secundarios.

Comparativa de enfoques asíncronos#

Antipatrones asíncronos frente a estándares arquitectónicos de producción

Критерий	Antipatrón / Código vulnerable	Solución de producción en React 19
Peticiones asíncronas en efectos	Llamada directa a fetch() sin cancelación al cambiar dependencias	AbortController transmitiendo el signal a fetch
Condiciones de carrera (Race Condition)	La promesa que tarda más sobrescribe ciegamente el estado	Cancelación activa de peticiones obsoletas con controller.abort()
Suscripciones globales (window)	addEventListener sin removeEventListener en el cleanup	Paso de { signal } a addEventListener o limpieza explícita
Clausuras obsoletas (Stale Closures)	Lectura directa de variables de estado desde useCallback([])	setState funcional (prev => ...) o dependencias exhaustivas

PUNTO DE CONTROL

Comprobación de conocimientos: AbortController frente a bandera isMounted

+15 XP

¿Por qué el patrón con la bandera isMounted (let isMounted = true; ... if (isMounted) setState(...); return () => { isMounted = false; }) se considera una mala práctica en comparación con AbortController?

Artefacto de producción: Hook para peticiones asíncronas seguras#

A continuación se muestra el hook de producción useSafeAsync, con tipado estricto en TypeScript, cancelación garantizada mediante AbortController, protección contra condiciones de carrera y limpieza determinista:

Production Artifactsrc/shared/hooks/useSafeAsync.ts

Hook para la obtención de datos con cancelación automática vía AbortController, prevención de race conditions y tipado estricto sin any.

typescript

import { useState, useEffect, useRef, type DependencyList } from 'react';

export interface AsyncState<T> {
  data: T | null;
  error: Error | null;
  isLoading: boolean;
}

export type AsyncFn<T> = (signal: AbortSignal) => Promise<T>;

export function useSafeAsync<T>(
  asyncFn: AsyncFn<T>,
  deps: DependencyList
): AsyncState<T> {
  const [state, setState] = useState<AsyncState<T>>({
    data: null,
    error: null,
    isLoading: true,
  });

  // Contador de peticiones para garantizar inmunidad frente a condiciones de carrera
  const requestCounterRef = useRef<number>(0);

  useEffect(() => {
    const currentRequestId = ++requestCounterRef.current;
    const controller = new AbortController();

    // Establecer estado de carga
    setState((prev) => ({ ...prev, isLoading: true, error: null }));

    async function execute() {
      try {
        const result = await asyncFn(controller.signal);

        // Verificar que la respuesta corresponda a la petición más reciente
        if (currentRequestId === requestCounterRef.current) {
          setState({
            data: result,
            error: null,
            isLoading: false,
          });
        }
      } catch (err: unknown) {
        // Ignorar el error estándar de cancelación (AbortError)
        if (err instanceof Error && err.name === 'AbortError') {
          return;
        }

        if (currentRequestId === requestCounterRef.current) {
          const formattedError =
            err instanceof Error ? err : new Error('Error desconocido en la carga de datos');

          setState({
            data: null,
            error: formattedError,
            isLoading: false,
          });
        }
      }
    }

    void execute();

    // Fase de limpieza: abortar la petición activa al desmontar o cambiar dependencias
    return () => {
      controller.abort();
    };
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, deps);

  return state;
}

Errores comunes (Pitfalls)#

Ошибка: Omitir la limpieza de listeners de eventos globales o temporizadores

Suscribirse a eventos de ventana (window.addEventListener('resize', ...)) o iniciar intervalos sin retornar la función de limpieza acumula manejadores y provoca fugas de memoria.

tsx

// ❌ Antipatrón: en cada montaje se crea un listener que nunca se elimina
useEffect(() => {
  window.addEventListener('resize', handleResize);
}, []); // ¡Fuga de memoria al desmontar el componente!

// ✅ Solución correcta: limpieza explícita en return o uso de AbortSignal
useEffect(() => {
  const controller = new AbortController();

  // ¡Los navegadores admiten la opción signal en addEventListener!
  window.addEventListener('resize', handleResize, { signal: controller.signal });

  return () => {
    controller.abort(); // Elimina automáticamente el listener de la memoria
  };
}, []);

Ошибка: Utilizar banderas isMounted en lugar de cancelar la operación de red

Filtros tipo if (isMounted.current) setState(...) no detienen la promesa ni la conexión de red en segundo plano, consumiendo ancho de banda y memoria.

tsx

// ❌ Antipatrón: el parche con isMounted maquilla la fuga de recursos
useEffect(() => {
  let isMounted = true;
  fetchData().then((data) => {
    if (isMounted) setState(data); // ¡La respuesta se descarga entera de todas formas!
  });
  return () => {
    isMounted = false;
  };
}, []);

// ✅ Solución correcta: cancelación física mediante AbortController
useEffect(() => {
  const controller = new AbortController();
  fetchData({ signal: controller.signal })
    .then((data) => setState(data))
    .catch((err: unknown) => {
      if (err instanceof Error && err.name === 'AbortError') return;
      console.error(err);
    });

  return () => controller.abort();
}, []);

Ошибка: Crear objetos dentro del render y pasarlos como dependencias de useEffect

Definir objetos de configuración dentro del cuerpo del componente y pasarlos al array de dependencias desencadena un bucle infinito de renders.

tsx

// ❌ Antipatrón: options se recrea en cada render -> bucle infinito
function Widget({ query }: { query: string }) {
  const options = { filter: query, page: 1 }; // ¡Nueva referencia en memoria cada vez!

  useEffect(() => {
    fetchItems(options);
  }, [options]); // ¡Bucle infinito!
}

// ✅ Solución correcta: dependencias primitivas o useMemo estable
function WidgetFixed({ query }: { query: string }) {
  useEffect(() => {
    fetchItems({ filter: query, page: 1 });
  }, [query]); // query es un string primitivo estable
}

Preguntas de entrevista#

Preguntas de entrevista7 preguntas

Temas relacionados

Perfilado en React: React DevTools Flamegraph y depuración de INP— Herramientas para aislar cuellos de botella de render y Long Tasks.Virtualización de listas: TanStack Virtual— Prevención de saturación de memoria en listas masivas.Pruebas de componentes con Vitest y RTL— Aserciones automatizadas de estados asíncronos y condiciones de carrera.