Hasta ahora, cuando teníamos contenido (lista de tareas, posts, productos) lo metíamos a mano en un array dentro del frontmatter o lo pedíamos por fetch. Para un blog real, ninguna de las dos opciones es buena:
Astro propone una tercera vía: las Content Collections.
Pones tus posts (Markdown, MDX o JSON) dentro de src/content/<coleccion>/, defines un schema con Zod, y Astro te da una API tipada para consultarlos: getCollection, getEntry, etc.
Beneficios:
title.Tus posts viven en archivos Markdown o MDX. Cada archivo es una entrada de la colección.
src/content/blog/
├── hola-astro.md
├── content-collections.md
└── view-transitions.mdCrea src/content.config.ts (o src/content/config.ts en versiones antiguas) y define el schema:
Cuando defines la colección, Astro:
src/content/blog/*.md) contra el schema.title en algún post, te lo dice.Un post es un archivo Markdown con frontmatter:
Desde una página, importa getCollection o getEntry:
post.data contiene los campos validados por el schema (con tipado completo). post.id es el slug derivado del nombre del archivo.
Cada entrada expone un método render():
<Content /> te pinta el cuerpo Markdown ya renderizado, con sus headings, code blocks, etc.
Zod te da mucho juego: refinamientos, valores por defecto, transformaciones.
Tienes dos archivos:
src/content.config.tssrc/pages/blog.astroEn el config:
defineCollection y z de astro:content.blog con un schema que tenga al menos title: z.string() y pubDate: z.date() (o z.coerce.date()).collections (un objeto con la colección).En la página:
getCollection desde astro:content.await getCollection("blog") y guarda el resultado.<ul> mostrando {post.data.title}.Aunque el editor no tenga posts reales, el código tiene que compilar y la consulta tiene que estar bien escrita. Cuando lleves esto a un proyecto real con archivos en src/content/blog/*.md, te aparecerán automáticamente.