La lección anterior dejó CicloUrbano enrutada pero mutilada: cada pantalla se pinta sola, sin Cabecera y sin PieDePagina, porque Diseno se quedó fuera del mapa de rutas. La solución obvia —envolver cada página en <Diseno>— funciona y es mala: repite el mismo marcado nueve veces, vuelve a montar la cabecera en cada navegación y no permite que el marco comparta datos con la pantalla. React Router propone algo mejor: las rutas se anidan igual que los componentes, de modo que una ruta padre pinta el marco y reserva un hueco donde aparecerá la ruta hija activa. En esta lección aprenderás ese mecanismo con children y <Outlet />, convertirás Diseno en la ruta raíz, distinguirás las rutas índice de las rutas con path: '', usarás rutas sin path para agrupar sin ensuciar la URL, construirás el detalle de estación con pestañas flota e incidencias, pasarás datos del padre al hijo con useOutletContext, generarás migas de pan a partir del propio mapa con handle y useMatches, y manejarás errores por rama con errorElement.

1. La idea: composición de interfaz a través de la URL
2. children y <Outlet />
3. Diseno como ruta raíz: qué mejora exactamente
4. Rutas índice: index: true
5. index: true frente a path: ''
6. Rutas sin path: agrupar sin añadir segmento
7. Rutas relativas y absolutas
8. Caso completo: detalle de estación con pestañas
9. useOutletContext: datos del padre a la hija
10. Migas de pan con handle y useMatches
11. Errores por rama: errorElement y useRouteError
12. errorElement frente a LimiteDeError
13. Nota sobre loader y action

Vuelve a mirar una URL de CicloUrbano y léela por trozos:

Cada segmento acota al anterior. Y si te fijas, la interfaz que corresponde a esa URL tiene exactamente la misma estructura de muñecas rusas: el marco de la aplicación contiene la pantalla de estaciones, que contiene el detalle de est-02, que contiene la pestaña de incidencias.

Anidar rutas consiste en declarar que una ruta es hija de otra, de modo que cuando la hija esté activa el padre también se renderiza, y la hija aparece dentro de él.

Esa correspondencia entre la jerarquía de la URL y la jerarquía de componentes es lo que hace que el enrutamiento en React encaje tan bien con lo que ya sabes de composición (04-02): un mapa de rutas anidado es un árbol de componentes, escrito de otra manera.

Dos piezas y ya está. En el mapa, la propiedad children; en el componente padre, el componente <Outlet />.

Compáralo con la versión de 04-02, que recibía { children }:

<Outlet /> es el children del enrutador. Es la misma idea de hueco de 04-02, pero rellenado automáticamente por la ruta hija que coincide con la URL. Nota que Diseno ya no acepta children: si necesitas ambas cosas —y a veces ocurre—, puedes tener las dos, pero en CicloUrbano no hace falta.

Y las reglas que gobiernan el anidamiento:

• Los path de las hijas son relativos al padre y no llevan / inicial. El hijo path: 'estaciones' dentro del padre path: '/' produce la URL /estaciones. Escribir path: '/estaciones' en la hija también funciona (es absoluta), pero rompe el patrón y complica reorganizar el árbol.
• Si el padre no tiene <Outlet />, la hija no se ve. Es el error más frecuente de esta lección: todo está bien configurado, la URL coincide, pero la pantalla no aparece porque falta el hueco.
• Se puede anidar sin límite de profundidad, aunque más de tres o cuatro niveles suele indicar que el modelo de URLs se ha complicado de más.

Este es el mapa completo de CicloUrbano ya anidado, sustituyendo al plano de 06-02:

Fíjate en que la ruta estaciones no tiene element: solo agrupa. Cuando una ruta tiene hijas y ningún elemento, React Router pinta implícitamente un <Outlet /> en su lugar, así que las hijas suben directamente al hueco del abuelo. Es una forma limpia de organizar el mapa por secciones.

Qué mejora exactamente convertir Diseno en ruta raíz en lugar de envolver cada página:

La fila de los proveedores es la de mayor calado y explica una decisión pendiente de 06-02. ProveedorReservas y ProveedorAvisos van dentro de Diseno, no en main.jsx:

El razonamiento es el de 06-02, un nivel más abajo: ProveedorTema y ProveedorUsuario van fuera del enrutador porque deben sobrevivir a absolutamente todo; ProveedorReservas y ProveedorAvisos van en la ruta raíz porque pertenecen al marco de la aplicación, lo consumen varias pantallas y así quedan junto a la interfaz que los usa. Como Diseno no se desmonta al navegar, el efecto práctico es el mismo y el mapa se lee mejor. Este detalle es el que permite que en 06-04 crees una reserva en /reservas/nueva y la veas en /reservas: si el proveedor se reiniciara al cambiar de pantalla, la reserva se habría evaporado por el camino.

Pregunta: con el padre path: 'estaciones' y la hija path: ':estacionId', ¿qué se ve en /estaciones a secas? Nada dentro del <Outlet />: ninguna hija coincide.

Para eso está la ruta índice:

Una ruta índice (index: true) es la hija que se renderiza en el <Outlet /> del padre cuando la URL coincide exactamente con el padre y no hay más segmentos.

Sus reglas:

• Una ruta índice no tiene path. { index: true, path: 'algo' } es un error.
• Una ruta índice no puede tener children. Es una hoja del árbol por definición.
• Solo puede haber una por padre.
• Es la pantalla por defecto de esa sección, y por eso da nombre al patrón: es el «índice» de la carpeta, como el index.html de un directorio en un servidor web.

En CicloUrbano hay tres: el catálogo bajo la raíz, el listado bajo estaciones y la pestaña de flota bajo el detalle de estación.

Existe una alternativa que parece equivalente y no lo es del todo:

Ambas coinciden con la URL del padre. Las diferencias:

En la práctica: usa index: true casi siempre. path: '' es la herramienta para un caso concreto —insertar un componente intermedio que además tenga hijas propias— y ahí compite con la ruta sin path del apartado siguiente, que suele expresarlo mejor.

Un aviso: path: '/' en una ruta hija no es lo mismo que path: ''. La barra la convierte en absoluta y produce coincidencias sorprendentes. Dentro de un padre, deja las hijas siempre relativas.

Este es un patrón que resuelve un problema muy concreto: aplicar un marco común a varias pantallas sin que la URL lo refleje.

Una ruta sin path (pathless route) es una ruta con element y children pero sin path. No consume ningún segmento de la URL: solo inserta su elemento en el árbol y deja que las hijas sigan como si no estuviera.

Fíjate en el resultado: /taller sigue siendo /taller, no /protegido/taller. El componente RutaProtegida se renderiza entre Diseno y PaginaTaller, comprueba la sesión y decide si pinta su <Outlet /> o redirige. Este es el patrón 2 de 06-05, y lo verás allí desarrollado.

Otros usos habituales:

La regla mental: path es para la URL; el anidamiento es para la interfaz. Que dos pantallas compartan marco no obliga a que compartan prefijo, y una ruta sin path es justamente la forma de desacoplar ambas cosas.

En path y en to, una cadena que empieza por / es absoluta y una que no, relativa. La diferencia importa más de lo que parece.

En path (dentro del mapa):

La relativa se recomienda porque si mañana renombras la sección a paradas, cambias una línea y todo el subárbol sigue. Con rutas absolutas tendrías que editar cada hija.

En to (dentro de los componentes): la referencia es la ruta activa, no la URL literal. Estando en /estaciones/est-02:

El caso de .. tiene una sutileza que conviene conocer: por defecto sube un nivel de la jerarquía de rutas, no de segmentos de URL. Si quieres el comportamiento de segmentos, como en un sistema de ficheros, se pide explícitamente:

Consejo práctico: usa rutas relativas dentro de un subárbol (las pestañas de una pantalla, la navegación interna de una sección) y absolutas para la navegación principal (el menú de Cabecera). Las relativas hacen que un subárbol se pueda mover de sitio sin tocar sus enlaces; las absolutas dejan claro el destino en el menú global.

Vamos con el caso central de la lección. /estaciones/:estacionId muestra los datos de la estación y dos pestañas: flota (por defecto) e incidencias. Cada pestaña es una ruta, así que tiene su propia URL, se puede compartir y el botón atrás alterna entre ellas.

Detalles que hacen que esto funcione:

• to="." apunta a la propia ruta activa, es decir, a /estaciones/est-02. Con end exige coincidencia exacta, de modo que estando en /incidencias la pestaña «Flota» no aparece marcada. Sin end, ambas se verían activas a la vez, que es el error clásico de las pestañas anidadas.
• to="incidencias" es relativo: se añade al final de la ruta actual. Nunca escribas aquí /estaciones/est-02/incidencias, porque tendrías que interpolar el identificador a mano y el componente dejaría de ser reutilizable.
• La flota se calcula una vez en el padre y baja a las hijas por context, en lugar de que cada pestaña vuelva a filtrar el array. Es el apartado siguiente.
• La navegación entre pestañas no vuelve a montar la cabecera de la estación: el <article>, el título y las pestañas persisten; solo cambia lo que hay dentro del <Outlet />. Exactamente la misma ganancia que con Diseno, un nivel más abajo.

Problema real: PestanaFlota y PestanaIncidencias necesitan la estación y su flota. Podrían leer useParams() y volver a buscar en dominio.js, pero eso duplicaría el trabajo, duplicaría también la comprobación de «no encontrada» y —cuando los datos vengan de una API en 07-06— duplicaría la petición.

<Outlet /> acepta una prop context con lo que quieras pasar, y la hija lo lee con useOutletContext():

useOutletContext frente a useContext —porque la duda es legítima después de 05-04:

La regla: useOutletContext para lo local de la ruta; contexto de React para lo global. Pasar el usuario por useOutletContext desde Diseno sería técnicamente posible, pero obligaría a que cada nivel intermedio lo reenviase: la perforación de props que 05-04 vino a eliminar.

Un aviso de mantenibilidad: useOutletContext no avisa si el padre no ha puesto context; devuelve null y la desestructuración revienta con un mensaje poco informativo. Si el objeto es importante, protégelo como haces con los hooks de contexto del proyecto:

Con el árbol de rutas anidado tienes gratis la información necesaria para unas migas de pan: la cadena de rutas activas ya describe dónde está el usuario. useMatches() devuelve esa cadena, de la raíz a la hoja.

Cada elemento de la cadena tiene:

handle es la clave: un campo sin significado para React Router y con el significado que tú decidas. En el mapa del apartado 3 ya lo hemos rellenado con { miga: '…' }.

La miga como función permite migas dinámicas que usan los parámetros:

Con eso, en /estaciones/est-02/incidencias las migas dicen Inicio › Estaciones › Parque Norte, y cada una es un enlace real. Coloca <MigasDePan /> en Diseno, justo encima del <Outlet />, y funcionará en todas las pantallas sin tocar ninguna:

Esta es la ventaja del modo de datos que anunciaba 06-01: el mapa de rutas es un dato, y por tanto se puede recorrer para generar interfaz. Con <Routes> y <Route> en JSX esto sería mucho más incómodo.

En 04-05 construiste LimiteDeError, la única clase del proyecto, capaz de capturar los errores de render de su subárbol. El modo de datos de React Router añade un mecanismo paralelo y más fino: cada ruta puede declarar su propio errorElement.

Cuando algo falla dentro de esa rama, React Router sustituye el elemento de la ruta más cercana que tenga errorElement por ese elemento, dejando intactos sus ancestros. El componente lee el error con useRouteError():

Puntos importantes:

• isRouteErrorResponse distingue un error «esperado» —una Response que has lanzado tú— de una excepción de JavaScript. Los dos casos merecen mensajes distintos: el primero es una situación prevista; el segundo, un fallo.
• Lanzar una Response es la tercera estrategia que 06-02 mencionaba para un recurso inexistente:

• El detalle técnico solo en desarrollo. import.meta.env.DEV es la variable de Vite (01-02). En producción, el mensaje al usuario; la traza, a registrarError.
• errorElement por rama. Si pones uno en la ruta estaciones, un fallo en el detalle de una estación se contiene ahí: la cabecera, el pie y las migas siguen vivos, y el usuario puede navegar a otra sección sin recargar.

Tienes dos mecanismos de contención y conviene saber qué cubre cada uno. No compiten: se complementan.

Esa fila de «se reinicia al navegar» es la ventaja práctica más notable. Con LimiteDeError, una vez capturado el fallo el subárbol queda sustituido hasta que alguien pulse «Reintentar». Con errorElement, basta con que el usuario navegue a otra ruta para que todo vuelva a la normalidad, que es el comportamiento que espera.

La configuración recomendada para CicloUrbano combina ambos:

Y sigue vigente la limitación de 04-05, que ninguno de los dos resuelve: los errores lanzados dentro de un manejador de eventos no los captura nadie. Ahí sigue haciendo falta try/catch y un aviso al usuario a través de useAvisos.

El modo de datos se llama así por dos propiedades de ruta que esta lección no desarrolla:

La idea es potente: el loader carga los datos antes de pintar la pantalla, y así se evita el patrón «renderizar, lanzar un efecto, mostrar un indicador de carga, repintar» con el que has trabajado desde 05-02, junto con las cascadas de peticiones que produce. useLoaderData() recupera el resultado en la página.

No lo usaremos aquí por una razón de orden: es una decisión de arquitectura de datos, no de enrutamiento, y compite con las bibliotecas de estado del servidor. En 07-06 compararás loader/action con TanStack Query y decidirás; y en 10-01, con Next.js, verás la versión de esa misma idea llevada al servidor. Por ahora, CicloUrbano sigue leyendo de dominio.js y de useFetchBicicletas, que es suficiente y mantiene el foco.

Olvidar <Outlet /> en el componente padre. El síntoma es exasperante: la ruta coincide, no hay ningún error en consola, y la pantalla hija simplemente no aparece. Si una ruta tiene children, su element debe contener un <Outlet />.

Poner / inicial en el path de una hija. { path: '/estaciones' } dentro del padre { path: '/' } es absoluta: funciona por casualidad, pero deja de funcionar en cuanto muevas el subárbol. Las hijas van sin barra inicial.

Pestañas todas activas a la vez. Le falta end al NavLink de la pestaña índice (to="."). Sin él, la pestaña por defecto se considera activa también en las hermanas, porque su destino es prefijo de todas.

Interpolar la URL completa en las pestañas. to={/estaciones/${estacionId}/incidencias} funciona, pero obliga a arrastrar el identificador y rompe si cambias el mapa. Usa to="incidencias" relativo.

Confundir index: true con una ruta que coincide siempre. La ruta índice se pinta solo cuando la URL coincide exactamente con el padre. En /estaciones/est-02 la índice de estaciones no está activa.

Usar useOutletContext sin que el padre pase context. Devuelve null y la desestructuración lanza un error confuso. Comprueba, o al menos documenta el contrato en un comentario.

Recalcular en cada pestaña lo que el padre ya tiene. Si PestanaFlota y PestanaIncidencias vuelven a filtrar bicicletas, duplicas trabajo, duplicas la comprobación de existencia y —cuando haya API— duplicas las peticiones. Calcula en el padre y baja por context.

Consejo: refleja en la URL lo que el usuario querría compartir. Una pestaña sí (/estaciones/est-02/incidencias tiene sentido enviado por chat); el estado de un acordeón abierto, no. Si el estado no sobrevive a un F5 y a nadie le importa, es useState; si sí importa, es ruta o parámetro de consulta.

Consejo: anida el mapa igual que anidarías los componentes. Si al dibujar la pantalla el marco contiene a la sección y esta a la pestaña, el mapa debe tener esa misma forma. Cuando el mapa y el diseño divergen, aparecen los remontajes y las duplicaciones.

Consejo: usa handle para todo lo declarativo de la ruta. Migas, título del documento, icono del menú, nivel de permiso. Es un campo libre y convierte el mapa en la única fuente de verdad sobre la navegación.

Reorganiza la rama de reservas para que /reservas y /reservas/nueva compartan un marco común, MarcoReservas, que muestre un encabezado «Reservas» y un pequeño menú con dos enlaces relativos («Mis reservas» y «Nueva reserva») marcando el activo. Requisitos:

• Ninguna URL debe cambiar: siguen siendo /reservas y /reservas/nueva.
• MarcoReservas no debe volver a montarse al pasar de una a otra.
• El enlace «Mis reservas» no debe aparecer activo estando en /reservas/nueva.

Usando handle y useMatches, escribe un hook useTituloDeRuta que ponga en document.title un texto compuesto por la miga de la ruta más profunda y el nombre de la aplicación, por ejemplo Parque Norte · CicloUrbano. Debe actualizarse en cada navegación y usar el valor por defecto CicloUrbano cuando ninguna ruta declare miga.

La pestaña de incidencias tiene un fallo: si una bicicleta no tiene estado, bici.estado.toUpperCase() lanza. Configura el mapa para que ese fallo no tumbe la pantalla de detalle de la estación —el título, las plazas y las pestañas deben seguir visibles— sino solo el contenido de la pestaña. Explica qué rutas necesitan errorElement y por qué no basta con el de la ruta raíz.

Solución 1

Las tres claves: las hijas conservan index: true y path: 'nueva', así que las URLs no cambian; MarcoReservas es el element del padre y por tanto persiste al navegar entre hijas, cambiando solo el <Outlet />; y el end en to="." evita que «Mis reservas» aparezca activo en /reservas/nueva, porque sin él su destino sería prefijo del de la hermana.

Solución 2

Se llama una sola vez, desde Diseno, y funciona en todas las pantallas:

Dos comentarios. Primero, la dependencia del efecto es texto, una cadena, no el array coincidencias: este último es un objeto nuevo en cada render y provocaría que el efecto se ejecutase siempre, el problema de dependencias de 05-02. Segundo, esto es exactamente la definición de efecto que fijamos en aquella lección: sincronizar React con un sistema externo, en este caso el título del documento.

Solución 3

Hace falta un errorElement en las rutas de las pestañas, no solo en la raíz:

Por qué no basta con el errorElement de la raíz: React Router busca el errorElement de la ruta que ha fallado y, si no lo tiene, sube por sus ancestros hasta encontrar uno, sustituyendo el elemento de esa ruta. Si el más cercano es el de la raíz, lo que se sustituye es <Diseno /> entero: desaparecen cabecera, migas, pie, título de la estación y pestañas, y el usuario se queda mirando una pantalla de error completa por un fallo que afecta a un recuadro. Poniendo el errorElement en la propia pestaña, la sustitución ocurre exactamente donde estaba el <Outlet /> de PaginaDetalleEstacion: el resto de la pantalla sigue intacto y el usuario puede cambiar a la otra pestaña.

Es la misma lógica de granularidad de 04-05 con los LimiteDeError alrededor del catálogo y del formulario, ahora expresada en el mapa de rutas en vez de en el JSX. Y viene con un extra: al navegar a otra ruta, el estado de error se limpia solo.

Las rutas anidadas son composición de interfaz expresada a través de la URL: una ruta padre declara children y abre un hueco con <Outlet />, y la hija que coincide con la URL se pinta ahí. Has convertido Diseno en la ruta raíz de CicloUrbano, y la ganancia es concreta y medible: Cabecera y PieDePagina dejan de desmontarse y volver a montarse en cada navegación, sus efectos no se repiten, su estado interno persiste, y los proveedores que viven ahí —ProveedorReservas y ProveedorAvisos— sobreviven a los cambios de pantalla, que es lo que permitirá crear una reserva en una pantalla y verla en otra. Sabes que index: true marca la pantalla por defecto de una sección, en qué se diferencia de path: '', y que una ruta sin path agrupa varias pantallas bajo un mismo marco sin añadir ningún segmento a la URL, patrón del que 06-05 hará su herramienta principal.

Has construido el detalle de estación con pestañas anidadas: flota como ruta índice e incidencias como hermana, con NavLink relativos —to="." con end y to="incidencias"— que marcan la pestaña activa sin interpolar el identificador, de modo que cada pestaña tiene su propia dirección compartible y el botón atrás alterna entre ellas. useOutletContext te ha permitido calcular la estación y su flota una sola vez en el padre y bajarlas a las pestañas, reservando el contexto de React para lo verdaderamente ambiental. useMatches junto con el campo libre handle ha convertido el mapa de rutas en la fuente de las migas de pan y del título del documento, la primera muestra clara de por qué en el modo de datos conviene que el mapa sea un dato y no marcado. Y errorElement con useRouteError te da contención de fallos por rama, complementaria al LimiteDeError de 04-05: aquel es la red de seguridad global y la única que existe fuera del enrutador; este captura además los errores de loader/action, distingue las Response lanzadas a propósito con isRouteErrorResponse y —ventaja nada menor— se limpia solo al navegar.

Toda la navegación que has escrito hasta aquí nace de un clic en un enlace. Pero hay situaciones en las que la aplicación debe navegar por su cuenta: cuando el usuario confirma el FormularioReserva en /reservas/nueva, lo correcto es crear la reserva, despacharla al reductorReservas y llevarlo a /reservas sin que el formulario quede en el historial; cuando alguien intenta abandonar un formulario a medias, conviene detenerlo y preguntar; y mientras una navegación está en curso, conviene decírselo. La próxima lección es Navegación Programática.