El módulo anterior terminó montando el mapa de los hooks; ahora empieza el recorrido por el territorio, y el primer punto del mapa es el que ya usas desde 02-04: useState. Allí aprendiste lo esencial —declarar estado, actualizarlo, no mutarlo— y con eso el catálogo de CicloUrbano funciona. Pero useState esconde un comportamiento que sorprende a casi todo el mundo la primera vez que lo encuentra: durante un render, la variable de estado no cambia nunca, por muchas veces que llames al actualizador. Quien no entiende esto acaba escribiendo código que «pierde» actualizaciones sin saber por qué, y desconfiando de React. En esta lección vas a entender el mecanismo real: el estado como instantánea, la cola de actualizaciones, la agrupación de cambios, la inicialización perezosa, un recetario completo de actualización inmutable aplicado a las reservas de CicloUrbano, cinco principios para estructurar bien el estado y el truco de reiniciarlo con la prop key.

1. La firma de useState y el par que devuelve
2. Por qué el actualizador es estable entre renders
3. El estado es una instantánea del render
4. Tres setContador(contador + 1) que suman uno solo
5. La forma funcional y la cola de actualizaciones
6. Agrupación de actualizaciones (batching)
7. Inicialización perezosa y la trampa del cálculo directo
8. Objetos y arrays: recetario de actualización inmutable
9. Estructurar bien el estado: cinco principios
10. Reiniciar el estado de un componente con la prop key
11. Valor directo o función actualizadora: tabla de decisión

useState recibe un argumento —el valor inicial— y siempre devuelve un array de exactamente dos posiciones:

Que devuelva un array y no un objeto no es un capricho: al desestructurar un array eliges tú los nombres, posición a posición. Si devolviera { valor, establecerValor } tendrías que renombrar en cada llamada, y con tres estados en el mismo componente el código sería ilegible.

La convención universal en el ecosistema es [algo, setAlgo]. En este curso la respetamos para el actualizador aunque el resto de nombres esté en español, porque set forma parte del idioma de React tanto como useState.

El argumento solo se usa en el primer render. A partir de ahí React ignora lo que le pases: el valor inicial es exactamente eso, inicial. Esta línea no «reinicia» nada en el render número 40:

Esta es una propiedad que se enuncia poco y que resulta muy útil:

React garantiza que la función actualizadora que devuelve useState es la misma referencia en todos los renders del componente. No se recrea nunca.

Compruébalo con una comparación de identidad:

Tres consecuencias prácticas que aprovecharás en las próximas lecciones:

• No hace falta incluirlo en las dependencias de un efecto (05-02). El linter lo sabe y no te lo exige.
• No hay que envolverlo en useCallback (08-03) para pasarlo a un hijo memorizado: ya es estable por definición.
• Se puede pasar directamente como prop de callback sin miedo a provocar renders innecesarios.

La misma garantía se aplica a la función despachar de useReducer, como verás en 05-05.

Aquí está la idea central de la lección, y conviene enunciarla despacio.

Cada render es una fotografía congelada. Las variables de estado de ese render son constantes: valen lo que valían cuando React llamó a la función del componente, y no cambian hasta que empieza el render siguiente.

Recuerda cómo funciona un componente de función: es una función que React llama. En cada render, React la ejecuta de nuevo y useState devuelve el valor que corresponde a ese render. La variable horasReserva no es una caja mágica conectada a React: es una const local de esa ejecución concreta.

El ejemplo que lo hace evidente es un manejador con un retardo:

Muestra 2. Y no es un error: es exactamente lo correcto. El manejador manejarReservaDiferida fue creado durante el render en el que horas valía 2, y esa función captura ese valor. Aunque tres segundos después la pantalla ya muestre 5, la función sigue viviendo en la fotografía del render antiguo. Es el comportamiento normal de los cierres (closures) de JavaScript, aplicado a React.

Piénsalo así: si pulsas «enviar» en un formulario y luego, mientras se envía, cambias un campo, el mensaje enviado debe ser el que había al pulsar, no el que hay ahora. La instantánea no es un obstáculo: es lo que hace que los eventos sean predecibles.

Este es el ejemplo clásico, y ahora ya tienes las herramientas para explicarlo. Añadimos a CicloUrbano un botón que suma tres plazas de golpe:

Pulsas una vez y el contador marca 1, no 3. Sustituye mentalmente la variable por su valor en ese render y verás por qué:

Las tres llamadas encolan la misma orden: «pon el estado a 1». React procesa la cola, obtiene 1, y renderiza una vez. No se ha perdido ninguna actualización: es que las tres decían lo mismo.

La conclusión que hay que interiorizar: llamar al actualizador no cambia la variable en curso. setPlazasLibres(1) no hace plazasLibres = 1; hace «apunta que en el próximo render valdrá 1».

La solución es pasar una función actualizadora en lugar de un valor. React la guarda en la cola y la ejecuta después, una detrás de otra, pasándole el resultado de la anterior.

Ahora sí: 3. Así procesa React la cola antes del siguiente render:

Y este es el contraste con la versión de valor directo, donde cada elemento de la cola es un valor fijo que sustituye lo que hubiera:

La tercera fila enseña que se pueden mezclar: un valor directo descarta lo anterior y reinicia el cálculo. Es útil, por ejemplo, para «reiniciar y sumar»:

Reglas para escribir buenas funciones actualizadoras:

• Deben ser puras: calcular y devolver el nuevo estado, sin console.log que dependan del orden, sin peticiones, sin mutar nada. React puede llamarlas dos veces en desarrollo con StrictMode (01-03) precisamente para detectar impurezas.
• Nombra el parámetro con claridad: previas, reservasPrevias, datosPrevios. Evita la letra suelta.
• No leas otras variables de estado dentro: si el cálculo depende de dos estados a la vez, es señal de que esos dos estados deberían ser uno solo, o de que ha llegado el momento de useReducer (05-05).

React no repinta después de cada llamada al actualizador: agrupa todas las actualizaciones que se producen y hace un único render al final. Es lo que se llama batching.

Tres cambios de estado, un solo render. Sin agrupación tendrías tres renders y estados intermedios visibles en pantalla: la interfaz mostraría por un instante el panel vacío con las horas antiguas. La agrupación evita esos estados a medias.

El cambio importante de React 18 en adelante: la agrupación es automática en todas partes. Antes solo agrupaba dentro de manejadores de eventos de React; el código dentro de promesas, temporizadores o manejadores nativos provocaba un render por llamada.

Si alguna vez necesitas forzar un repintado inmediato antes de continuar —un caso muy raro, típicamente para medir el DOM—, existe flushSync de react-dom. Considéralo una válvula de escape: su uso habitual es un síntoma de que algo está mal planteado.

El argumento de useState solo se usa en el primer render, pero se evalúa en todos. Esa diferencia tiene consecuencias.

Aunque React descarte el resultado a partir del segundo render, JavaScript ha tenido que ejecutar la función para poder pasar su valor como argumento. Si recorre cinco bicicletas da igual; si lee localStorage, parsea un JSON grande o recorre miles de reservas, estás pagando ese coste en cada repintado.

La solución es pasar la función, sin llamarla. React la ejecutará una única vez, en la inicialización:

Un caso muy habitual en CicloUrbano: recuperar el borrador de reserva guardado en el navegador.

Sin la función envolvente, cada pulsación de tecla en el formulario provocaría un render, y cada render leería y parsearía localStorage para tirar el resultado a la basura.

Cuidado con la ambigüedad si el estado es una función. Si quieres guardar una función como valor de estado, useState(miFuncion) la interpretaría como inicializador perezoso y guardaría su resultado. Hay que envolverla: useState(() => miFuncion).

En 02-04 quedó establecida la regla: el estado se sustituye, no se modifica. React compara la referencia anterior con la nueva y, si son la misma, considera que no ha cambiado nada y no renderiza. Aquí está el recetario completo, aplicado a la lista de reservas de CicloUrbano.

Partimos de este estado en App:

Los cuatro casos que más aparecen, escritos con la forma funcional (porque dependen del valor anterior):

Fíjate en manejarCancelarReserva: el map devuelve el mismo objeto para las reservas que no cambian y un objeto nuevo solo para la afectada. Eso es exactamente lo que queremos: la mínima cantidad de referencias nuevas, para que las optimizaciones del Módulo 8 puedan saltarse el resto.

Aviso sobre sort y reverse: son métodos que modifican el array original. [...arr].sort(f) copia primero. JavaScript moderno ofrece además toSorted() y toReversed(), que ya devuelven una copia y hacen el [...arr] innecesario.

El caso anidado es el que más errores produce, porque hay que copiar todos los niveles del camino hasta la propiedad que cambia:

Esto olvida copiar el nivel intermedio y borra el teléfono:

Y este otro parece funcionar pero es una mutación disfrazada: modifica el objeto que ya estaba en el estado, así que la referencia de borrador no cambia y React puede no renderizar:

Ten en cuenta también que las paréntesis alrededor del objeto en (previo) => ({ ... }) son obligatorios: sin ellos, JavaScript interpreta las llaves como el cuerpo de la función y la flecha devuelve undefined.

Si el anidamiento pasa de dos niveles, la respuesta correcta casi nunca es escribir spreads más largos: es aplanar el estado (apartado siguiente) o recurrir a una biblioteca de inmutabilidad como Immer, que permite escribir código de aspecto mutable y produce copias por debajo.

Elegir qué guardar en el estado importa más que saber actualizarlo. Estos cinco principios evitan la mayoría de los errores de estado que verás en producción.

Si dos variables se actualizan siempre a la vez, son una sola.

Es la regla de la fuente única de verdad de 04-01, ahora dentro de un mismo componente.

La versión correcta tiene un beneficio inmediato: si el operario cambia el estado de bici-002 a «mantenimiento», la tarjeta seleccionada se entera. Con la copia, seguiría mostrando los datos viejos.

Tres booleanos sueltos permiten combinaciones que no deberían existir.

Con esa estructura hay 2 × 2 × 2 = 8 combinaciones y solo 4 tienen sentido. Basta con olvidar un setCargando(false) en una rama de error para que la interfaz muestre a la vez el mensaje de fallo y el indicador de carga.

Si un dato se puede calcular a partir de otros, no es estado. Ya lo viste en 04-01 con bicicletasVisibles; el error más común es el «total» calculado:

Guardar la jerarquía tal cual llega del servidor obliga a spreads de tres niveles para cambiar un dato. Guardar índices por identificador convierte esa operación en una línea.

Cuando estos cinco principios se quedan cortos —muchas piezas relacionadas, transiciones con reglas, manejadores que tocan tres estados a la vez— la respuesta ya no es reorganizar useState, sino cambiar de herramienta: useReducer reúne todas esas piezas bajo una función de transición única. Es la lección 05-05.

React conserva el estado de un componente mientras se renderice en la misma posición del árbol con el mismo tipo. Esto produce un comportamiento que sorprende: si cambias de bicicleta seleccionada, el PanelReserva mantiene las horas que había puestas para la anterior.

Podrías «arreglarlo» con un efecto que reinicie el estado al cambiar la prop, pero es la solución peor y la veremos como antipatrón en 05-02. La solución idiomática es una key distinta:

Al cambiar la key, React considera que es otro componente distinto: desmonta el anterior con todo su estado y monta uno nuevo desde cero. Es la misma key que usas en las listas (03-03), aplicada aquí con otro propósito: no identificar hermanos, sino declarar identidad a lo largo del tiempo.

Casos típicos donde la key es la herramienta correcta:

• Un formulario que debe vaciarse al cambiar de elemento editado.
• Un panel de detalle que debe volver a su pestaña inicial al cambiar de registro.
• Un componente de terceros que no ofrece forma de reiniciarse.

Regla práctica para no dudar: usa la forma funcional siempre que el nuevo estado se calcule a partir del actual. No penaliza el rendimiento, no complica el código y elimina de raíz toda una familia de errores difíciles de reproducir.

• Leer el estado justo después de actualizarlo. setHoras(5); console.log(horas); imprime el valor viejo. Es la instantánea del apartado 3, no un retraso. Si necesitas el valor nuevo, calcúlalo en una constante: const nuevasHoras = 5; setHoras(nuevasHoras); console.log(nuevasHoras);.
• Llamar al actualizador durante el render. setContador(1) en el cuerpo del componente provoca un bucle infinito («Too many re-renders»). Los actualizadores se llaman desde manejadores o desde efectos, nunca durante el render. La única excepción, poco frecuente, es el ajuste condicional de estado con un if que rompe el bucle.
• useState(calcular()) en lugar de useState(() => calcular()). El cálculo se ejecuta en todos los renders. Revisa esta línea siempre que el inicializador no sea un literal.
• Mutar el estado y renderizar «a mano». reservas.push(nueva); setReservas(reservas); no repinta: la referencia es la misma. Y si además hay memorización (Módulo 8), el bug se vuelve intermitente.
• Estados booleanos que se contradicen. cargando, error y exito como tres booleanos independientes acaban mostrando pantallas imposibles. Una cadena con los estados válidos lo resuelve.
• Guardar en el estado el objeto entero cuando basta el id. Es la duplicación del principio 2: la copia envejece mal.
• Olvidar los paréntesis en (previo) => ({ ... }). Sin ellos la función no devuelve nada y el estado pasa a undefined.
• Consejo de depuración: cuando un estado no se actualiza como esperas, escribe la línea sustituyendo mentalmente cada variable por su valor en ese render. La mayoría de los misterios se resuelven ahí.
• Consejo de diseño: antes de añadir un useState, pregúntate «¿puedo calcularlo?». La mayor parte del estado que sobra es estado derivado que alguien no quiso derivar.

Ejercicio 1. Este componente de CicloUrbano debe sumar las horas de golpe según el botón que se pulse, pero al pulsar «+3 horas» solo suma una. Corrígelo y explica por qué fallaba.

Ejercicio 2. El panel de reservas de CicloUrbano guarda su estado así. Reestructúralo aplicando los cinco principios del apartado 9 y escribe los manejadores manejarSeleccion, manejarCambioHoras y manejarConfirmar con la estructura nueva.

Ejercicio 3. Escribe los tres manejadores que gestionan la lista de reservas de App, todos con actualización inmutable y forma funcional: manejarConfirmar(idReserva) cambia el estado de esa reserva a 'confirmada'; manejarCancelar(idReserva) lo cambia a 'cancelada' y añade la propiedad canceladaEn con la fecha ISO actual; manejarPurgar() elimina de la lista todas las reservas cuyo estado sea 'cancelada'. Parte del estado const [listaReservas, setListaReservas] = useState(reservas);.

Solución 1.

manejarSumarTres fallaba porque horas es una constante de ese render. Con horas = 1, las tres líneas eran literalmente setHoras(2) tres veces: la cola contenía 2, 2, 2 y el resultado era 2 (una sola hora sumada). Con la forma funcional, la cola contiene tres funciones que React aplica en cadena: 1→2→3→4.

En manejarReiniciarYSumar la mezcla es intencionada. Con la versión original (setHoras(0); setHoras(horas + 2);) y horas = 5, la cola sería 0 y luego 7: el reinicio se pierde y el resultado es 7. Con la versión corregida la cola es 0 y luego f, así que f(0) = 2, que es lo que promete el botón.

Solución 2.

Los cambios, principio a principio: reservaSeleccionada deja de duplicar el objeto y pasa a derivarse del id (2); precioTotal se calcula en cada render en lugar de guardarse (4); y los cuatro booleanos de envío se funden en una sola variable con cuatro valores posibles, de modo que ya no existe la combinación «enviando y con error a la vez» (3). Además, envio agrupa estado y mensaje, que siempre cambian juntos (1). Con setEnvio({ estado: 'error', error: error.message }) es imposible olvidar apagar el indicador de carga.

Solución 3.

Tres detalles que valen la nota: el map devuelve la misma referencia para las reservas no afectadas, así que solo cambia el objeto que realmente cambió; new Date().toISOString() se ejecuta dentro del manejador y no durante el render, respetando la pureza (04-03); y filter devuelve un array nuevo por definición, así que no hace falta copiarlo antes.

useState es mucho más de lo que parecía en 02-04. Ahora sabes que devuelve un par [valor, actualizador] en el que el actualizador es estable para siempre, que el valor es una instantánea congelada del render en curso y que por eso tres setContador(contador + 1) seguidos suman uno solo. La forma funcional resuelve ese caso porque encola funciones que React aplica en cadena; la agrupación de actualizaciones —automática en todas partes desde React 18— convierte varios cambios en un único render; y la inicialización perezosa evita repetir cálculos caros en cada repintado. Tienes además el recetario completo de actualización inmutable para arrays y objetos aplicado a las reservas de CicloUrbano, cinco principios para estructurar el estado sin duplicados, contradicciones ni redundancias, y el truco de la prop key para reiniciar un componente entero cuando cambia lo que representa.

Con esto puedes gestionar cualquier dato que viva dentro de React. Pero una aplicación real no vive sola: hay temporizadores que marcan la disponibilidad de las estaciones, eventos del navegador, un título de pestaña que actualizar y, sobre todo, un servidor del que traer las bicicletas. Todo eso queda fuera de React, y conectarse a ello tiene sus propias reglas: cuándo empezar, cuándo parar y cómo no dejar basura por el camino. Es el modelo de sincronización con sistemas externos que se anunció en 04-03 y que por fin toca desarrollar. La próxima lección es Hook useEffect.