El almacén de CicloUrbano ya tiene forma y comportamiento: tres slices completos, reglas de negocio en los reductores, entidades normalizadas, selectores junto a su dominio y carga asíncrona con createAsyncThunk. Todo eso existe hoy sin que ningún componente lo sepa. Esta lección cierra el circuito con react-redux, y lo hace prestando una atención desproporcionada a un solo asunto, porque es el que separa una integración que funciona de una que repinta la aplicación entera con cada acción: la regla de oro de la comparación por identidad en useSelector. Vas a ver cómo se suscribe un componente y cuándo vuelve a ejecutarse, reproducir el fallo del selector que devuelve un array nuevo y corregirlo de cuatro formas distintas, reescribir PaginaCatalogo, PaginaReservas, PanelReservas y MenuUsuario sobre el almacén, decidir con argumentos qué se queda fuera de Redux, despachar thunks mostrando carga y error, aprender a leer connect en código heredado, depurar con el historial de DevTools y organizar el código por funcionalidad. Se cierra con una comparación honesta entre contexto + reductor, Redux Toolkit y Zustand para una aplicación como esta.

1. useSelector: cómo se suscribe un componente
2. La regla de oro: comparación por identidad
3. El fallo reproducido
4. Las cuatro soluciones
5. createSelector en la práctica
6. useDispatch y por qué despachar es estable
7. MenuUsuario sobre sliceSesion
8. PaginaCatalogo: el filtro de la URL y el almacén conviviendo
9. PaginaReservas y PanelReservas sobre sliceReservas
10. Despachar thunks desde un componente
11. Qué se queda fuera de Redux
12. connect y mapStateToProps: solo para leer código heredado
13. Depuración con Redux DevTools
14. Organización del código: carpeta por funcionalidad
15. Comparativa final honesta

Lo que hace useSelector por dentro, paso a paso:

1. Se suscribe al almacén mediante almacen.subscribe(...), usando el Provider que colocaste en main.jsx (07-03).
2. Ejecuta la función selectora con el estado actual y devuelve el resultado.
3. Tras cada acción despachada, vuelve a ejecutar la función selectora con el estado nuevo.
4. Compara el resultado nuevo con el anterior usando Object.is (comparación por identidad de referencia).
5. Si son distintos, provoca un repintado del componente. Si son iguales, no hace nada.

Ese paso 5 es la selección granular que el contexto no podía dar (07-02). Un componente suscrito a estado.reservas.ids.length no se repinta cuando cambia el tema, cuando se escribe en el buscador o cuando se confirma una reserva sin alterar el número.

Y el paso 3 es el que hay que tener siempre presente: la función selectora se ejecuta tras cada acción, sea del dominio que sea. sesion/sesionIniciada, catalogo/terminoCambiado, reservas/reservaConfirmada: todas hacen que se ejecuten todos los selectores de todos los componentes montados. Los selectores deben ser, por tanto, baratos.

useSelector compara con Object.is. Si tu selector construye un objeto o un array nuevo en cada llamada, la comparación siempre dará «ha cambiado» y el componente se repintará con cada acción del almacén, venga de donde venga.

Es la misma trampa de identidad que viste en 07-02 con el value de un proveedor, en otro sitio y con otro nombre. Y aquí es peor, porque un componente mal suscrito se repinta con acciones que no tienen nada que ver con él.

La fila de «una referencia guardada en el estado» explica por qué la normalización de 07-04 es tan buena idea: como Immer reutiliza las referencias de las ramas que no cambian, estado.reservas.entidades['res-01'] es literalmente el mismo objeto mientras nadie toque esa reserva, y la comparación por identidad funciona sola.

Vamos a ver el problema con el selector derivado de 07-04, que es exactamente el caso peligroso.

Recuerda el selector: termina con [...filtradas].sort(...). Devuelve un array nuevo cada vez.

Prueba a hacer esto en el navegador con DevTools abierto:

1. Escribe una letra en el buscador → catalogo/terminoCambiado → se ejecuta el componente. Correcto: el catálogo ha cambiado.
2. Pulsa el botón de tema... y aquí no pasa nada, porque el tema no está en Redux. Bien pensado.
3. Inicia sesión → sesion/sesionIniciada → se ejecuta PaginaCatalogo. El catálogo no ha cambiado en absoluto.
4. Confirma una reserva → reservas/reservaConfirmada → se ejecuta PaginaCatalogo otra vez.

Con el registro en consola verás la línea aparecer con cada acción de la aplicación. Y no es solo un render: como visibles es un array nuevo, ListaBicicletas recibe una prop nueva y también se repinta, con todas sus TarjetaBicicleta dentro.

En desarrollo, react-redux te avisa por consola:

Es un aviso muy fácil de ignorar y muy caro de ignorar.

La más simple, la más rápida y la que se olvida más a menudo.

Cuando lo que necesitas son dos o tres valores sueltos, varios useSelector de primitivas siempre ganan. No hay memorización que mantener, no hay dependencias que declarar y cada uno solo repinta cuando su valor cambia de verdad.

La generalización de la anterior. Un componente puede tener tantos useSelector como necesite; el coste de cada suscripción es despreciable.

Aquí ids es seguro porque es el array que vive en el estado, no uno construido al vuelo. Immer solo lo sustituye cuando se añade o se quita una reserva.

Cuando el selector tiene que calcular de verdad —filtrar, ordenar, agregar—, la respuesta es memorizarlo. Es el apartado 5 entero.

useSelector acepta un segundo argumento: una función que decide si dos resultados son iguales.

shallowEqual compara clave a clave con Object.is. El objeto sigue siendo nuevo en cada llamada, pero como su contenido superficial es igual, useSelector no repinta.

RTK ofrece además useSelector con createSelector ya integrado, y react-redux exporta useDebugValue-friendly helpers, pero en la práctica basta con estas cuatro opciones.

Cuál elegir:

Orden de preferencia: 1 → 2 → 3 → 4. La cuarta es la última porque shallowEqual recorre el objeto en cada comparación y no evita el trabajo del selector, solo el repintado.

createSelector viene de Reselect y RTK lo reexporta. Recibe una lista de selectores de entrada y una función combinadora, y memoriza: si las entradas son idénticas a las de la llamada anterior, devuelve el resultado anterior sin recalcular y con la misma referencia.

Qué ocurre ahora en el escenario del apartado 3:

Tres advertencias importantes sobre createSelector:

1. Los selectores de entrada deben ser baratos y estables. Se ejecutan siempre; lo que se ahorra es la función combinadora. Si una entrada devolviera un objeto nuevo cada vez, la memorización nunca acertaría y el selector sería peor que no tenerlo.

2. La memorización tiene tamaño. Históricamente Reselect guardaba un solo resultado, así que un selector con argumento usado desde dos componentes con argumentos distintos se invalidaba mutuamente en cada llamada. En Reselect 5 —el que trae RTK 2— la memorización por defecto (weakMapMemoize) maneja bien varios argumentos y ese problema desaparece en la mayoría de casos. Si necesitas el comportamiento clásico con varios consumidores, el patrón es una fábrica de selectores:

3. No memorices lo que no cuesta. createSelector alrededor de (estado) => estado.sesion.usuario es ruido: no hay cálculo que ahorrar y la referencia ya es estable. Memoriza cuando el selector construya algo.

createSelector y useMemo resuelven el mismo problema en capas distintas: uno memoriza sobre el estado del almacén y sirve para todos los componentes; el otro memoriza dentro de un componente. El detalle de cuándo compensa memorizar está en 08-03.

useDispatch devuelve la función dispatch del almacén, que es siempre la misma: el almacén se crea una vez, en almacen.js, y su dispatch no cambia jamás durante la vida de la aplicación.

Consecuencias prácticas:

• Un componente que solo despacha nunca se repinta por Redux. No está suscrito a nada. Es el equivalente automático de la división estado/acciones que en 07-02 hubo que montar a mano con dos contextos.
• despachar puede ir en las dependencias de un useEffect sin causar bucles. De hecho, el linter de hooks te pedirá que lo incluyas, y es correcto hacerlo.
• No hace falta memorizar los manejadores que solo despachan por miedo a la identidad: la función que provoca el trabajo es estable.

Fíjate en el patrón de nombres del proyecto aplicado a Redux: manejarClic es el manejador interno del componente y reservaConfirmada es el creador de acción importado del slice. La convención de «manejadores manejarX dentro, props alX hacia fuera» sigue vigente; lo que cambia es que ahora, en lugar de invocar una prop alConfirmar, muchos componentes despachan directamente.

Un matiz de diseño que merece pensarse: no todos los componentes deberían despachar. Un TarjetaBicicleta que despacha acciones deja de ser reutilizable y deja de poder probarse sin un almacén. La regla razonable es que las páginas y los paneles se conectan; los componentes de presentación reciben props. ListaBicicletas y TarjetaBicicleta siguen recibiendo bicicletas y alSeleccionar como hasta ahora.

El caso más sencillo, y el que enseña la solución 1.

Tres puntos que resumen media lección:

• seleccionarEsOperario devuelve un booleano. Es estado derivado calculado en el selector (07-04), y al ser primitivo la comparación por identidad funciona perfectamente.
• abierto se queda en useAlternar. Es exactamente el ejemplo del apartado 11.
• sesionCerrada() se llama sin argumentos y devuelve { type: 'sesion/sesionCerrada' }. Y recuerda de 07-04 que sliceReservas reacciona a esa misma acción en su extraReducers limpiando las reservas: un solo despacho, dos dominios actualizados, sin acoplamiento entre componentes.

Esta es la decisión de diseño más interesante de la lección, y estaba pendiente desde 07-04.

El problema: ?tipo= vive en la URL desde 06-02 y sliceCatalogo tiene un campo tipo. Dos fuentes de verdad para el mismo dato es exactamente lo que 07-01 prohíbe.

La decisión: el tipo se queda en la URL y desaparece del slice. La URL es la fuente de verdad porque el filtro debe poder compartirse por enlace y sobrevivir a un recargado, y ningún almacén de cliente da eso. El slice conserva termino y orden, que no son enlazables por decisión de producto, y seleccionarBicicletasVisibles recibe el tipo como argumento, tal como se escribió en el apartado 5.

Lo que hay que retener de este componente:

• Tres fuentes de estado coexisten sin duplicarse: el filtro en la URL, el término y el catálogo en el almacén, y la selección en un useState local. Cada uno donde le corresponde según la taxonomía de 07-01.
• useEffect con [despachar] como única dependencia funciona precisamente porque despachar es estable. Y condition del thunk (07-04) evita que el doble render de StrictMode provoque dos peticiones.
• ListaBicicletas y SelectorTipo no conocen Redux. Siguen recibiendo props. Son componentes de presentación y así se mantienen probables y reutilizables.
• La alternativa que NO se ha elegido: mantener tipo en el slice y sincronizarlo con la URL mediante un useEffect. Habría funcionado casi siempre, y habría fallado en los casos difíciles —pegar una URL, el botón «atrás», abrir en una pestaña nueva—, además de meter un render extra en cada cambio de filtro. Cuando hay dos candidatos a fuente de verdad, se elige uno y el otro deja de existir.

Este par de componentes ilustra el patrón más eficiente de Redux con listas, y merece explicarse bien:

• El padre selecciona solo los identificadores. ids es el array que vive en el estado; solo cambia de referencia al añadir o quitar una reserva. Confirmar una reserva no repinta PaginaReservas.
• Cada hijo selecciona su propia entidad por identificador. Gracias a Immer, entidades['res-01'] conserva su referencia mientras nadie toque esa reserva, así que confirmar res-01 repinta exclusivamente la fila de res-01.

Con una lista de doscientas reservas, la diferencia entre este patrón y seleccionar el array completo en el padre es de doscientos renders a uno. Es la aplicación práctica de por qué se normalizó el estado en 07-04.

Un thunk se despacha igual que una acción: despachar(cargarBicicletas()). La diferencia es que devuelve una promesa con métodos útiles.

Puntos importantes:

• .unwrap() convierte el resultado del thunk en algo con lo que se puede usar try/catch: devuelve el payload del fulfilled o lanza el error del rejected. Sin él, await despachar(...) se resuelve siempre, incluso cuando la petición ha fallado, y el catch nunca se ejecutaría. Es el fallo más común al despachar thunks.
• La carga y el error se leen del almacén, no de un useState paralelo. Una única fuente de verdad, y además visible en DevTools.
• La navegación y el aviso ocurren en el componente, no en el thunk. Un reductor no navega y un thunk no debería conocer el enrutador: la lógica de interfaz se queda en la interfaz.
• disabled={enviando} y aria-busy (03-06) evitan el doble envío desde la interfaz; el condition del thunk (07-04) lo evita también desde el almacén. Las dos cosas, no una sola.

Tener un almacén no significa meterlo todo dentro. Esta es la lista razonada para CicloUrbano.

El criterio que resume la tabla: algo entra en Redux cuando su cambio es un suceso del dominio que merece quedar registrado. «El usuario ha abierto un menú» no lo es. «El usuario ha cancelado una reserva» sí.

⚠️ Este apartado existe únicamente para que sepas leer proyectos anteriores a 2019. connect sigue funcionando y react-redux lo mantiene, pero no se usa en código nuevo. No aparecerá más en el curso.

Antes de los hooks, la conexión se hacía con un componente de orden superior:

Equivalencia con hooks:

Por qué se abandonó: connect añade un componente envolvente por cada conexión —lo que ensucia el árbol en DevTools—, obliga a separar el componente «tonto» del «conectado», tiene una API con cuatro formas distintas de escribir mapDispatchToProps y es notablemente difícil de tipar. Los hooks hacen lo mismo con menos indirección.

Lo que sí conviene conservar de aquella época es la distinción conceptual entre componentes de presentación y conectados. connect la imponía; con hooks hay que mantenerla por disciplina, y es la regla del apartado 6: páginas y paneles se conectan, los componentes de presentación reciben props.

Ahora que la aplicación despacha acciones de verdad, la herramienta de 07-03 vale lo que prometía. Un ejemplo concreto de cómo cambia la forma de buscar un fallo.

El síntoma: «a veces, al confirmar dos reservas seguidas, la segunda aparece cancelada».

Sin Redux, la investigación sería: poner console.log en tres manejadores, intentar reproducirlo, sospechar de un problema de cierre, sospechar de una condición de carrera, añadir más registros.

Con Redux DevTools:

1. Reproduce el fallo una vez.
2. Mira la lista de acciones. Ahí está toda la secuencia real:

   sesion/sesionIniciada
   catalogo/cargarBicicletas/pending
   catalogo/cargarBicicletas/fulfilled
   reservas/reservaConfirmada     ← payload: 'res-01'
   reservas/reservaCancelada      ← payload: 'res-02'   ⚠️ ¿de dónde sale esto?
   reservas/reservaConfirmada     ← payload: 'res-02'
   

3. La acción sobra y está identificada en veinte segundos. El fallo no está en el reductor ni en el estado: hay un onClick que despacha reservaCancelada cuando no debería, probablemente un manejador mal cableado en el botón de la segunda fila.
4. Pulsa skip sobre esa acción y comprueba que sin ella el resultado es el correcto: confirma el diagnóstico sin tocar el código.
5. Mira el panel Diff de la acción sospechosa para ver exactamente qué cambió.

Y si el fallo lo reportó un usuario, puede exportar el historial en JSON y tú importarlo: reproduces su sesión exacta en tu máquina.

Lo que cambia de fondo no es la velocidad, es la naturaleza de la pregunta. Sin Redux preguntas «¿por qué el estado está mal?». Con Redux preguntas «¿qué acción lo dejó así?», y esa pregunta siempre tiene respuesta, porque está en la lista.

Tres funciones que se usan a diario:

Hasta ahora CicloUrbano se organiza por tipo: componentes/, paginas/, hooks/, contextos/, reductores/. Con Redux, la comunidad recomienda otra cosa.

Reglas que hacen que esto funcione:

1. componentes/ guarda solo lo genuinamente compartido. Si algo lo usa un único dominio, vive en su carpeta.
2. Un dominio no importa del interior de otro. Si reservas necesita algo de catalogo, se importa de la raíz de esa carpeta, y si empieza a pasar mucho, la frontera entre dominios está mal trazada.
3. rutas.jsx sigue en la raíz y sí importa de varios dominios: es, por definición, el mapa que los une.
4. La migración es gradual. Se mueve un dominio cada vez, y la aplicación sigue funcionando en cada paso.

En un proyecto del tamaño de CicloUrbano la organización por tipo aún se aguanta. La razón para cambiar no es estética: es que la carpeta por funcionalidad hace visible el acoplamiento. Cuando reservas/ necesita cinco cosas de catalogo/, se ve en los import y es una señal de diseño, no un detalle de colocación.

Con todo el módulo en la mano, esta es la comparación para una aplicación como CicloUrbano.

Y la recomendación, dicha sin adornos:

Para CicloUrbano, con honestidad: es una aplicación pequeña con un equipo pequeño, y contexto + useReducer seguiría siendo suficiente. Redux se ha introducido porque es lo que te vas a encontrar en el trabajo, porque el modelo mental —acciones, reductores puros, selectores, estado normalizado— se transfiere íntegro a Zustand y a Jotai, y porque las DevTools son una herramienta que conviene haber usado al menos una vez. Lo que no vamos a hacer es fingir que era imprescindible.

Un último aviso, que es el más importante del módulo y el hilo hacia la próxima lección: cuando 07-06 saque las bicicletas, las estaciones y las reservas del almacén hacia una caché de estado de servidor, lo que quede en Redux será muy poco. En muchas aplicaciones reales, después de ese movimiento el estado de cliente cabe en dos contextos, y esa es una conclusión legítima a la que hay que llegar habiendo entendido Redux, no evitándolo.

Error 1: un selector que devuelve un objeto o un array construido. El error número uno, con diferencia. Provoca repintados con cada acción de la aplicación. Primitivas, referencias del estado o createSelector.

Error 2: agrupar varios valores en un objeto «por comodidad». useSelector((e) => ({ a: e.x, b: e.y })) sin shallowEqual es el error 1 disfrazado. Dos useSelector son más simples y más rápidos.

Error 3: olvidar .unwrap() al despachar un thunk. await despachar(thunk()) se resuelve siempre, así que el catch no se ejecuta nunca y los fallos se tragan en silencio.

Error 4: seleccionar el array completo en el padre de una lista. Selecciona los identificadores en el padre y la entidad en cada hijo: de N repintados pasas a uno.

Error 5: conectar componentes de presentación. TarjetaBicicleta con useSelector deja de poder reutilizarse y de poder probarse sin almacén. Páginas y paneles se conectan; el resto recibe props.

Error 6: duplicar en Redux algo que ya vive en la URL y sincronizarlo con un efecto. Elige una fuente de verdad y borra la otra.

Error 7: leer el estado con almacen.getState() dentro de un componente. No suscribe a nada, así que el componente no se repinta cuando cambia. getState() es para thunks y middleware.

Consejo 1: activa el aviso de selectores inestables. react-redux ya lo emite en desarrollo. No lo ignores: cada uno de esos avisos es un componente repintándose de más.

Consejo 2: nombra los selectores seleccionarX y expórtalos desde el slice. Un componente no debería escribir nunca estado.reservas.entidades directamente.

Consejo 3: mide con el Profiler antes de memorizar. createSelector en un selector trivial es coste sin beneficio. El Módulo 8 enseña a medirlo (08-05).

Consejo 4: mantén el almacén pequeño a propósito. Cada campo que añades es un campo que alguien tendrá que entender. La tabla del apartado 11 es una herramienta de decisión, no una lista cerrada.

Ejercicio 1. Este componente provoca un repintado con cada acción del almacén, tiene tres problemas distintos y además falla al enviar. Encuéntralos y reescríbelo.

Ejercicio 2. Escribe un selector memorizado seleccionarResumenReservas que devuelva { activas, confirmadas, canceladas, totalHoras } a partir del estado normalizado de sliceReservas, y el componente DistintivoReservas que lo consuma mostrando solo el número de activas. Justifica por qué el componente no debería usar ese selector tal cual y qué harías en su lugar.

Ejercicio 3. Traduce este componente heredado a hooks, conservando el comportamiento.

Solución 1. Los tres problemas de rendimiento y el de envío:

1. El primer useSelector devuelve un objeto literal. Referencia nueva en cada llamada: repintado con cada acción.
2. El segundo useSelector devuelve el resultado de un filter. Array nuevo en cada llamada: el mismo problema, por segunda vez.
3. bicicletas y estaciones se seleccionan y no se usan. Suscripción gratuita a dos ramas del estado.
4. Falta .unwrap(): await despachar(cargarBicicletas(...)) se resuelve incluso cuando el thunk termina en rejected, así que el catch nunca se ejecuta y un fallo de red mostraría «Flota actualizada».

Se han eliminado las dos suscripciones inútiles, el filtro se memoriza con una fábrica —para que dos ResumenFlota de estaciones distintas no se invaliden entre sí— y el envío informa correctamente del fallo.

Solución 2.

Por qué DistintivoReservas no debería usarlo tal cual: el selector devuelve un objeto, y aunque createSelector lo memoriza, se recalcula —y devuelve un objeto nuevo— cada vez que cambia cualquier reserva. Si el distintivo solo muestra el número de activas, se repintaría al cancelar una reserva, al confirmar otra o al cambiar las horas de una tercera, aunque el número de activas siga igual.

La solución es seleccionar la primitiva:

El selector memorizado hace el cálculo una sola vez y se comparte entre todos los consumidores; cada componente extrae el primitivo que necesita y useSelector compara ese número. Es la combinación de las soluciones 1 y 3, y es el patrón recomendado para selectores que devuelven agregados: memoriza el agregado, selecciona el campo.

Solución 3.

Cuatro mejoras que la traducción trae de propina:

• Desaparece el componente envolvente que connect insertaba en el árbol.
• cargando es un booleano derivado en el selector, no un objeto: comparación por identidad perfecta.
• <li onClick> pasa a ser un <button> dentro del <li>. El original no era accesible: un <li> no recibe foco ni responde al teclado (03-06). Migrar código heredado es buen momento para arreglar esto.
• despachar en las dependencias del efecto es correcto y no causa bucles, precisamente por ser estable.

El circuito está cerrado. useSelector suscribe un componente al almacén, ejecuta su función selectora tras cada acción y compara el resultado con Object.is, de donde sale la regla de oro: un selector que construye un objeto o un array nuevo en cada llamada provoca repintados con cada acción de la aplicación, venga del dominio que venga. Las cuatro soluciones, en orden de preferencia: seleccionar primitivas, dividir en varios useSelector, memorizar con createSelector —recordando que los selectores de entrada deben ser baratos y que la memorización solo compensa cuando hay cálculo— y, como último recurso, una función de igualdad como shallowEqual. useDispatch devuelve la función dispatch del almacén, que es estable para siempre: un componente que solo despacha nunca se repinta por Redux, y despachar puede ir en las dependencias de un efecto sin miedo.

CicloUrbano queda conectado con criterio. MenuUsuario lee dos primitivas de sliceSesion y conserva su desplegable en useAlternar. PaginaCatalogo hace convivir tres fuentes de estado sin duplicar ninguna: el filtro en la URL —que sigue siendo la fuente de verdad, con el tipo pasado como argumento al selector memorizado—, el término y el catálogo en el almacén, y la selección en un useState local. PaginaReservas selecciona solo los identificadores y PanelReserva selecciona su propia entidad, de modo que confirmar una reserva repinta exactamente una fila: la recompensa directa de haber normalizado el estado. Los thunks se despachan con .unwrap() para que try/catch funcione, y la carga y el error se leen del almacén, no de un useState paralelo. Y la tabla de qué se queda fuera —tema, modales, filtro de URL, selección del catálogo, borrador del formulario, avisos— resume el criterio de todo el módulo: algo entra en Redux cuando su cambio es un suceso del dominio que merece quedar registrado.

También sabes leer connect, mapStateToProps y mapDispatchToProps sin escribirlos nunca, usar el historial de DevTools para cambiar la pregunta de «¿por qué el estado está mal?» a «¿qué acción lo dejó así?», y organizar el código por funcionalidad en lugar de por tipo, con componentes/ reservado a lo genuinamente compartido. La comparativa final es honesta: para una aplicación del tamaño de CicloUrbano, contexto + useReducer habría bastado; Redux Toolkit se paga solo cuando hay equipo, tamaño y lógica que auditar; y Zustand ocupa un término medio muy razonable.

Queda la pieza más grande, y la que va a cambiar el equilibrio de todo lo anterior. En el almacén hay hoy un campo bicicletas cargado con un createAsyncThunk, y ya se dijo dos veces que estaba ahí de forma provisional: los datos que vienen de un servidor no son estado de la aplicación. No te pertenecen, se quedan obsoletos solos, se comparten entre pestañas y usuarios y llegan tarde. Tratarlos como estado de cliente obliga a escribir a mano carga, error, cancelación, condiciones de carrera, deduplicación, revalidación, invalidación, reintentos y paginación —para cada recurso—. En la próxima lección montarás una API ficticia con json-server, conocerás TanStack Query, entenderás el ciclo de vida de un dato en caché, harás mutaciones con actualización optimista y su reversión, reescribirás useFetchBicicletas como useBicicletas, y fijarás la arquitectura final de CicloUrbano: Redux para el estado del cliente, Query para el del servidor. La próxima lección es Estado del Servidor: Peticiones, Caché y Sincronización.