Tu hot reload te está mintiendo

Hay una mentira pequeña que aceptamos todos los días: llamar "hot reload" a cualquier cosa que actualice el navegador cuando guardas un archivo. Bajo ese nombre conviven tres comportamientos que no se parecen en nada — y la diferencia entre ellos decide cuánto vale tu ciclo de trabajo.

El primero es una recarga completa disfrazada: rápida, sí, pero la página vuelve a cero. El segundo reemplaza el módulo editado pero desmonta el componente: la página sigue ahí, tu estado no. El tercero — el único que merece el nombre — aplica tu cambio y conserva el estado: el formulario a medio llenar, el contador en 3, el modal abierto en el paso cuatro del flujo que estás depurando.

La distancia entre el primero y el tercero no es comodidad. Es si puedes depurar el paso cuatro de un flujo editando, o si cada guardado te devuelve al paso uno.

Lo que el fast refresh promete de verdad

La maquinaria real — la que popularizó React con Fast Refresh — se sostiene sobre dos hilos finos de los que casi nadie habla.

El primero: la identidad de cada componente debe sobrevivir a la edición. La herramienta registra cada componente con una clave estable; cuando llega la versión nueva, empareja la vieja con la nueva y actualiza el árbol sin desmontarlo. Si algo rompe ese emparejamiento — un componente anónimo, un HOC que devuelve un componente nuevo en cada build, un archivo que exporta algo que el registro no reconoce — el estado se pierde. Sin error. Sin aviso. Solo un parpadeo y el formulario vacío.

El segundo: los hooks tienen firma. Si editas el interior de un componente, tu estado debe conservarse; si añades o quitas un useState, conservarlo corrompería la aplicación — el orden de los hooks es el contrato — así que el componente debe remontarse: desmontarse y volver a montarse desde cero. La herramienta calcula una firma de los hooks de cada componente y la compara entre versiones para decidir: conservar o remontar. Una firma mal calculada en una dirección te corrompe el estado; en la otra, te lo borra en cada edición.

Dos hilos finos, y todo tu ciclo de trabajo colgando de ellos.

Se rompe en silencio, y ahí está el problema

Lo insidioso es la forma del fallo. Cuando el hot reload funciona a medias, no hay stack trace: hay un desarrollador que sin darse cuenta aprende a rellenar el formulario otra vez, a volver a navegar hasta el paso cuatro, a guardar con miedo. He visto equipos donde "el estado se pierde a veces" era simplemente el clima — nadie lo trataba como un bug, porque ningún error lo señalaba.

Y he visto lo contrario: una edición que conservaba el estado cuando debía remontar, y una tarde entera perdida persiguiendo un "bug" que era estado corrupto del propio hot reload. De las dos mentiras, esta es peor: la primera te roba minutos, la segunda te hace dudar de tu propio código.

Cómo auditar el tuyo en cinco minutos

No hace falta leer el código de tu bundler. Tres pruebas:

1. Pon un useState, súbelo a 3 con clics, edita el JSX de ese componente. ¿Sigue en 3? Si está en 0, tienes una recarga con marketing.
2. Añade un useState nuevo y guarda. ¿El componente se remonta limpiamente, sin overlay rojo y sin recarga completa? Así se ve una firma de hooks funcionando.
3. Edita cinco veces seguidas, rápido. ¿La quinta se aplica igual que la primera, o en algún punto la página se rindió y recargó entera? La degradación silenciosa bajo ediciones consecutivas es de los fallos más comunes y de los que menos se reportan.

Si tu herramienta pasa las tres, cuídala. Si no, al menos ahora sabes qué te está costando: no segundos de recarga — contexto, el tuyo, decenas de veces al día.

La vara de medir

Un buen entorno de desarrollo no es el que recarga más rápido. Es el que te dice la verdad: conserva lo que puede conservar, remonta lo que debe remontar, y cuando no puede hacer ninguna de las dos cosas, te lo dice con un motivo — no con un parpadeo. Esa honestidad es rara. Cuando la encuentres, sabrás que alguien midió estos dos hilos en vez de limitarse a cruzar los dedos.