Llevas usando un hook desde la lección 02-04 sin haberle puesto nombre a la categoría: useState. Y en las dos últimas lecciones han aparecido las razones históricas por las que los hooks existen: el infierno de envoltorios de los HOC y las render props (04-02), y la lógica relacionada repartida entre métodos del ciclo de vida que estaban a cincuenta líneas unos de otros (04-03). Esta lección cierra ese círculo. Vas a entender qué es exactamente un hook, qué problema vino a resolver, por qué tiene dos reglas de uso aparentemente arbitrarias —y el mecanismo interno que las explica—, qué hooks existen y en qué lección del curso se ve cada uno. No desarrollaremos ninguno a fondo: ese es el trabajo del Módulo 5 completo. Aquí montamos el mapa antes de recorrer el territorio.

1. Qué problema vinieron a resolver los hooks
2. Qué es un hook, con precisión
3. Regla 1: solo en el nivel superior
4. El mecanismo: la lista ordenada de hooks
5. Regla 2: solo desde componentes o desde otros hooks
6. eslint-plugin-react-hooks, la red de seguridad
7. Catálogo de los hooks del curso
8. Uso básico combinado: PanelResumen con useState + useEffect
9. Estado local, referencia y contexto: tres cosas distintas

Antes de 2019, un componente de React tenía que elegir entre dos formas incompatibles:

• Componente de función: sencillo, legible, sin this… pero sin estado y sin acceso al ciclo de vida. Solo servía para presentación.
• Componente de clase: podía todo, a cambio de constructor, bind, this y métodos de ciclo de vida.

Eso obligaba a un refactor completo en cuanto un componente de presentación necesitaba recordar un dato. Pero el problema de fondo era otro, y más grave: no había forma decente de reutilizar lógica con estado.

Supón que tres componentes de CicloUrbano necesitan saber el ancho de la ventana para decidir cuántas tarjetas caben. Con clases, la lógica —suscribirse al evento resize, guardar el ancho, darse de baja— había que copiarla en los tres, o envolver los tres en un HOC, o meterlos dentro de una render prop. Las dos últimas opciones producían árboles como este:

Cuatro niveles que no dibujan nada, props que aparecen sin origen visible y una depuración incómoda. Eso es el infierno de envoltorios (wrapper hell) que viste en 04-02.

El segundo problema era la organización por momentos en lugar de por asuntos, que analizamos en 04-03:

Tres asuntos que no tienen nada que ver comparten método, y cada uno tiene su otra mitad en un método distinto. Es la receta perfecta para olvidarse de una limpieza.

Los hooks resuelven las tres cosas a la vez:

Y una cosa que no hicieron: eliminar las clases. Siguen funcionando, y para los límites de error todavía son obligatorias (04-05).

Un hook es una función de JavaScript cuyo nombre empieza por use y que engancha el componente al sistema interno de React, permitiéndole acceder a capacidades como el estado, los efectos o el contexto.

Desmenucemos la definición:

• Es una función normal. No es una palabra clave del lenguaje, no es sintaxis especial, no requiere compilación. useState es una función que React exporta y tú importas.
• Su nombre empieza por use. No es decorativo: es la convención por la que React y las herramientas de análisis reconocen un hook. eslint-plugin-react-hooks decide si una función es un hook mirando su nombre, y aplica las reglas en consecuencia. Si escribes tu propia función con estado y la llamas obtenerAncho en vez de useAncho, las reglas no se aplicarán y perderás la red de seguridad.
• Engancha con el sistema interno. Aquí está la clave conceptual. Un componente de función es solo una función: cuando termina, sus variables desaparecen. Entonces, ¿dónde se guarda el estado entre renders? Fuera del componente, en una estructura de datos interna de React, asociada a esa instancia concreta. El hook es el cable que conecta la función con ese almacén.

Esa idea —el estado vive en React, no en la función— es lo que hace posibles las dos reglas del apartado siguiente. Y también explica algo que ya observaste en 02-04: dos instancias del mismo componente tienen estados independientes, porque React guarda un almacén por instancia, no por componente.

Llama a los hooks únicamente en el nivel superior del componente. Nunca dentro de condicionales, bucles, funciones anidadas ni después de un return anticipado.

El último caso tiene una solución conceptual, no técnica: si cada estación necesita su propio estado, cada estación necesita su propio componente. Extraes ContadorPlazas y llamas al hook dentro de él. Cada instancia tendrá su almacén, y la regla se cumple sola.

¿Por qué reglas tan estrictas? Porque el mecanismo interno de React depende del orden. Vamos a verlo.

React no guarda el estado por el nombre de la variable. No puede: const [horas, setHoras] es destructuring de un array, y React nunca ve el nombre horas. Lo que hace es mucho más simple: mantiene, para cada instancia de componente, una lista ordenada de celdas, y un puntero que avanza una posición con cada llamada a un hook.

En el primer render React crea las celdas en el orden en que se llaman los hooks. En todos los renders siguientes se limita a leerlas en el mismo orden. El vínculo entre useState(1) y su valor guardado es exclusivamente la posición.

De ahí sale la regla: si en un render se llaman tres hooks y en el siguiente solo dos, las posiciones se desplazan y cada variable recibe el valor de otra.

El resultado en pantalla: confirmada pasa a valer '' en lugar de false, y setConfirmada escribe en la celda que pertenecía a nota. No hay ningún error de sintaxis, la aplicación no se detiene y el fallo se manifiesta como un comportamiento absurdo muy difícil de rastrear. React detecta muchos de estos casos y avisa con:

Cuando veas ese mensaje, busca un hook dentro de un if, de un bucle, de un try/catch o después de un return anticipado. Siempre es eso.

La consecuencia práctica: el número y el orden de las llamadas a hooks debe ser idéntico en todos los renders de un componente. Por eso los hooks se escriben todos juntos, arriba del todo, antes de cualquier lógica condicional. Y si necesitas un valor condicional, la condición va dentro del hook, no alrededor:

Llama a los hooks solo desde componentes de función de React o desde otros hooks personalizados. Nunca desde funciones JavaScript normales.

La razón sale directamente del apartado anterior: las celdas pertenecen a una instancia de componente que se está renderizando ahora mismo. Si llamas a un hook desde una función suelta, React no sabe a qué lista de celdas dirigirse, y lanza:

El caso del manejador de evento merece un aviso, porque es un error frecuente en quien empieza: los manejadores se ejecutan después del render, cuando ya no hay ninguna renderización en curso. Los hooks se llaman durante el render; los manejadores usan lo que esos hooks devolvieron.

Y la consecuencia constructiva de esta regla es la que da sentido a todo: una función que empieza por use y llama a hooks es un hook personalizado, y eso es todo lo que hace falta para reutilizar lógica con estado. Sin envoltorios, sin niveles nuevos en el árbol. Lo construirás en Hooks Personalizados.

Las dos reglas son fáciles de romper sin darse cuenta, sobre todo al refactorizar. Por eso el equipo de React mantiene un plugin de ESLint que las comprueba automáticamente, y que las plantillas de Vite para React ya traen configurado.

Qué aporta cada regla:

La primera regla se equivoca tan poco que conviene tratarla como error de compilación. Si alguna vez te apetece silenciarla con un comentario, la respuesta correcta casi siempre es reestructurar el componente —extraer un componente hijo, mover la condición dentro del hook—, no callar el aviso.

Este es el mapa completo. No memorices los detalles ahora: la columna de la derecha te dice dónde se explica cada uno a fondo.

Dos observaciones sobre el catálogo:

• La mayoría de los componentes solo necesitan useState. Después, por frecuencia, van useEffect y useContext. useMemo y useCallback son herramientas de optimización que solo se aplican tras medir un problema, y llegan en el módulo 8 precisamente por eso.
• Existen más hooks de los que aparecen aquí (useImperativeHandle, useSyncExternalStore, useDebugValue, useOptimistic, useActionState…). Son especializados y este curso los deja fuera salvo mención puntual. Con la tabla anterior cubres el noventa y cinco por ciento del React que se escribe a diario.

Un aperitivo del módulo 5. Este componente de CicloUrbano combina los dos hooks que más usarás: guarda un contador de consultas del resumen y sincroniza el título de la pestaña del navegador con la flota disponible.

Qué hace cada pieza y por qué está donde está:

• Los dos useState van al principio, en el nivel superior, uno detrás de otro. Ocupan las celdas 0 y 1, en ese orden, en todos los renders. Regla 1 cumplida.
• disponibles y enTaller no son estado. Se calculan de flota en cada render. Si fueran estado, habría que recalcularlos a mano cada vez que cambia la flota, con el riesgo de desincronización que viste en 04-01.
• setConsultas((consultasPrevias) => …) usa la forma funcional porque el valor nuevo depende del anterior. Es la precaución de 02-04.
• El useEffect sincroniza con un sistema externo: el document.title pertenece al navegador, no a React. Aquí es donde se aplica el modelo mental de 04-03: no se trata de «ejecutar código al montar», sino de mantener el título sincronizado con disponibles. Por eso disponibles aparece en la lista de dependencias [disponibles]: cuando ese número cambie, la sincronización se rehará.
• manejarConsulta no llama a ningún hook. Usa los resultados de los hooks (setConsultas, setMensaje, disponibles), que es exactamente el reparto correcto según la regla 2.
• El aria-live="polite" viene de 03-06: el mensaje cambia sin que la persona usuaria mueva el foco, y hay que anunciarlo.

Y en App, sin ninguna ceremonia:

Nada de HOC, nada de render props, ningún nivel extra en el árbol. Dos llamadas a función dentro del componente y ya tiene estado y efectos. Esa es la aportación de los hooks resumida en un ejemplo.

Para cerrar el mapa, la distinción que más ordena las decisiones que tomarás en el módulo 5:

En una frase cada uno:

• Estado: «lo que se ve, y cuando cambia hay que repintar».
• Referencia: «lo que se recuerda entre renders sin que nadie tenga que repintarse». Es exactamente el this.temporizador de la clase PanelActividad de 04-03.
• Contexto: «lo que está disponible para todo un subárbol sin ir de mano en mano», la respuesta a la perforación de props que quedó pendiente en 04-01.

• Hook dentro de un if, un bucle o un try. Rompe la correspondencia por posición y provoca fallos incomprensibles. Si necesitas condicionalidad, mueve la condición dentro del hook o extrae un componente hijo.
• Hook después de un return anticipado. Es el mismo error disfrazado: el return hace que las líneas siguientes no se ejecuten en algunos renders. Todos los hooks van antes de cualquier return.
• Llamar a un hook desde un manejador de evento. Los manejadores se ejecutan fuera del render. Llama al hook arriba y usa su resultado dentro del manejador.
• Nombrar obtenerAlgo a una función que llama a hooks. Sin el prefijo use, el plugin de ESLint no la reconoce como hook y no comprueba nada dentro de ella. La convención es funcional, no estética.
• Creer que useState en un bucle da «un estado por elemento». No lo da: da un desastre. Un estado por elemento significa un componente por elemento.
• Silenciar rules-of-hooks con un comentario de ESLint. Es tratar el síntoma. La regla no se equivoca prácticamente nunca.
• Consejo: escribe todos los hooks juntos, al principio del componente. Estado, referencias, contexto y efectos, en ese orden, y después la lógica derivada, los manejadores y el return. Si mantienes esa disposición en todo el proyecto, cumplir las reglas es automático.
• Consejo: mira los hooks en React DevTools. Al seleccionar un componente de función verás la lista de sus hooks en orden, con sus valores. Es la lista de celdas del apartado 4, hecha visible.

Ejercicio 1. Este componente de CicloUrbano rompe las reglas de los hooks en tres sitios distintos. Identifica cada infracción, explica qué regla incumple y qué consecuencia concreta tiene, y reescribe el componente correctamente.

Ejercicio 2. Sin escribir código, indica qué hook usarías en cada situación de CicloUrbano y en qué lección se estudia. Justifica brevemente cada elección.

1. Recordar qué tipo de bicicleta está filtrado en el catálogo.
2. Guardar el identificador de un setTimeout para poder cancelarlo.
3. Que quince componentes repartidos por el árbol conozcan el usuario que ha iniciado sesión.
4. Mantener el document.title al día con el número de reservas activas.
5. Gestionar un formulario de reserva con ocho campos y transiciones complejas entre estados de validación.

Ejercicio 3. Amplía el PanelResumen del apartado 8 con un tercer trozo de estado, ultimaConsulta, que guarde la hora de la última consulta como una cadena legible (toLocaleTimeString('es-ES')), o null si todavía no se ha consultado. Muéstralo en pantalla solo cuando exista. Después responde: ¿en qué posición de la lista de celdas queda ese nuevo estado y por qué es importante dónde lo declares?

Solución 1. Las tres infracciones:

1. return anticipado antes de un hook (regla 1). Cuando estacion es nulo, la función termina antes de llegar a las llamadas siguientes, y el número de hooks ejecutados cambia entre renders. Además, useState(estacion.plazas) en la línea anterior ya habría reventado al leer .plazas de null: la guarda llega tarde.
2. useState dentro de un if (regla 1). detalleAbierto solo se crea cuando mostrarDetalle es verdadero; al cambiar esa prop, las celdas se desplazan y los estados se mezclan entre sí.
3. useState dentro de un manejador de evento (regla 2). manejarAlquiler se ejecuta después del render, cuando no hay renderización en curso: React lanza «Invalid hook call».

Y un cuarto problema, no de reglas sino de corrección: setPlazasLibres(plazasLibres + 1) debería usar la forma funcional, y además no tiene tope superior (podría superar las plazas totales de la estación).

Observa el patrón general de la corrección: los hooks se declaran todos, siempre; lo condicional es el uso de su valor en el JSX, no la llamada.

Solución 2.

Solución 3.

ultimaConsulta ocupa la celda 2, porque es el tercer hook llamado. Lo importante no es el número en sí, sino que esa posición sea la misma en todos los renders: por eso la declaración va en el nivel superior, junto a las otras dos, y no dentro del if que decide si mostrarla. La condición se aplica solo al JSX ({ultimaConsulta && …}), nunca a la llamada al hook. Si lo hubieras declarado dentro de un condicional, en los renders donde no se cumpliera, useEffect pasaría a leer la celda equivocada.

Un hook es una función que empieza por use y engancha un componente de función al sistema interno de React, dándole acceso a estado, efectos, contexto y todo lo que antes exigía una clase. Nacieron para resolver tres problemas concretos que arrastraban las clases: la imposibilidad de dar estado a una función, el infierno de envoltorios que producían los HOC y las render props (04-02), y la lógica de un mismo asunto repartida entre métodos del ciclo de vida (04-03).

Sus dos reglas —solo en el nivel superior y solo desde componentes o desde otros hooks— no son caprichos de estilo: se explican por el mecanismo de la lista ordenada de celdas que React mantiene por instancia. El vínculo entre una llamada a useState y su valor guardado es la posición, y por eso el número y el orden de las llamadas debe ser idéntico en todos los renders. eslint-plugin-react-hooks vigila las dos reglas por ti, y conviene tratar rules-of-hooks como error. Tienes también el mapa completo: qué hooks existen, para qué sirve cada uno y en qué lección se estudia; y un primer PanelResumen de CicloUrbano que combina useState con useEffect sin un solo envoltorio.

Queda una pieza para cerrar el módulo, y es la excepción que confirma todo lo anterior. Los hooks han sustituido a los métodos del ciclo de vida en todo… menos en un caso: capturar los errores que lanza un componente durante el render. Si una tarjeta de CicloUrbano revienta por un dato inesperado, React desmonta el árbol entero y la persona usuaria se queda mirando una página en blanco. Evitarlo requiere una herramienta que a día de hoy sigue exigiendo un componente de clase. La próxima lección es Límites de Error: Capturar Fallos en la Interfaz.