Layouts anidados
Componer un layout de sección dentro de un layout base: un BlogLayout que envuelve su slot en un article y a su vez vive dentro de Base. La cadena de slots, el reparto de responsabilidades y los límites sanos del anidamiento.
Por qué anidar layouts
El layout base es dueño del documento: el <html>, el <head>, la navegación y el pie. Pero las secciones de un sitio no son iguales entre sí. Un artículo necesita un contenedor <article>, una cabecera con el título y la fecha, y una columna de lectura estrecha. Una página de docs necesita una barra lateral con el índice. Una landing quiere ir a todo el ancho sin cabecera interna. Todo eso es estructura, pero estructura de sección, no de sitio.
Podrías meterlo todo en el layout base con ramas condicionales —“si es un post, envuelve en <article>; si es docs, pinta la barra lateral”—, pero ese camino lleva a un fichero monstruoso que lo sabe todo de todas las secciones y crece sin control. El anidamiento ofrece la alternativa limpia: en lugar de un layout que se ramifica, muchos layouts pequeños que se componen. Cada sección tiene su propio layout, y todos comparten el base envolviéndose en él.
Un layout que usa otro layout
Como un layout es solo un componente, nada impide que un layout importe y use otro layout. Ese es el mecanismo entero del anidamiento: el layout de sección se escribe exactamente como una página que usa un layout, salvo que él mismo expone un <slot /> para su propio contenido.
---// src/layouts/BlogLayout.astroimport Base from './Base.astro';const { title, date } = Astro.props;---<Base title={title}> <article> <h1>{title}</h1> <time>{date}</time> <slot /> </article></Base>Lee con calma lo que hace BlogLayout. Recibe sus propias props, title y date. Usa Base como envoltorio y le reenvía hacia arriba lo que Base necesita —el title, para el <head>—. Y coloca su propio <slot /> dentro de un <article>, junto al encabezado y la fecha. Es a la vez consumidor de un layout y proveedor de otro: por arriba usa a Base, por abajo sirve a las páginas.
La página del blog, por su parte, usa BlogLayout sin enterarse de que Base existe:
---// src/pages/blog/primer-post.astroimport BlogLayout from '../../layouts/BlogLayout.astro';---<BlogLayout title="Mi primer post" date="2026-07-01"> <p>El cuerpo del artículo va aquí, y aterriza dentro del article.</p></BlogLayout>La cadena de slots
Lo elegante del anidamiento es cómo viaja el contenido. El párrafo de la página entra en el <slot /> de BlogLayout; ahí queda envuelto en el <article>; y ese <article> entero se convierte, a su vez, en los hijos de Base, que lo colocan en su propio <slot /> dentro del <body>. Es una cadena de proyecciones: el contenido atraviesa dos huecos y sale envuelto en dos capas.
Lo decisivo es que cada capa solo conoce a su vecina inmediata. BlogLayout no sabe nada del <head> ni de la navegación: eso es asunto de Base. Base no sabe nada del <article> ni de la fecha: eso es asunto de la sección. Ninguna capa necesita entender la cadena completa para hacer su trabajo. Esta ignorancia por niveles es lo que mantiene el sistema comprensible por mucho que crezca: para razonar sobre BlogLayout te basta con saber qué le pide a Base y qué ofrece a las páginas, sin cargar en la cabeza el documento entero.
Especialización por sección
Con esta técnica, un sitio real se organiza como un árbol de composición. Un único Base en la raíz; colgando de él, un layout por cada sección con su estructura propia; y colgando de cada uno, las páginas.
Las props fluyen hacia arriba por la cadena tanto como el contenido fluye hacia dentro: BlogLayout recibe title de la página y se lo pasa a Base. Comparado con el anti-patrón del layout único lleno de condicionales, este reparto es más fácil de leer, de probar y de extender: añadir una sección nueva es escribir un layout nuevo que use Base, sin tocar nada de lo existente.