Pasar datos con props desde getStaticPaths

getStaticPaths no solo decide qué URLs existen: también puede entregar, junto a cada ruta, los datos que esa página necesitará. Cada objeto del array admite una segunda clave, props, que viaja emparejada con params. Si params responde a qué dirección genero, props responde a con qué datos la relleno. La consecuencia es limpia y potente: la página recibe su contenido ya masticado en Astro.props, sin tener que volver a buscarlo. Sobre esa pareja se levanta el patrón más común de todo Astro: una página por cada entrada de una colección.

params identifica, props acompaña

La tentación, al programar una ruta dinámica, es usar el parámetro para volver a buscar el dato dentro de la página: recibo slug, y con él consulto de nuevo la colección para encontrar el post. Funciona, pero es trabajo repetido. getStaticPaths ya tenía delante la colección entera cuando decidió las rutas; obligar a la página a redescubrir lo que aquella ya sabía es dar dos vueltas al mismo dato.

La clave props elimina ese rodeo. En el mismo objeto donde declaras params, adjuntas los datos que la página va a necesitar, y estos llegan intactos a Astro.props.

---
// src/pages/blog/[slug].astro
export async function getStaticPaths() {
  const posts = await getCollection('blog');
  return posts.map((post) => ({
    params: { slug: post.id },   // decide la URL
    props: { post },             // acompana el dato
  }));
}

const { post } = Astro.props;    // llega ya listo
---
<h1>{post.data.title}</h1>

La división de trabajo es nítida y merece grabarse. params es lo que se convierte en URL: por fuerza son cadenas, porque una dirección es texto. props es lo que se convierte en contenido de la página: puede ser un objeto rico —la entrada entera, con su data tipado— porque nunca toca la URL. Uno mira hacia fuera, hacia el visitante que teclea la dirección; el otro mira hacia dentro, hacia la plantilla que se va a renderizar.

El patrón: una página por entrada de la colección

Juntando params y props nace el gesto que define el enrutado orientado a datos: recorrer una colección con map y emitir, por cada entrada, un objeto que usa su identificador como params y la entrada completa como props. Un post de la colección, una ruta materializada; añade un post, aparece su página; borra otro, desaparece la suya.

---
import { getCollection, render } from 'astro:content';

export async function getStaticPaths() {
  const posts = await getCollection('blog');
  return posts.map((post) => ({
    params: { slug: post.id },
    props: { post },
  }));
}

const { post } = Astro.props;
const { Content } = await render(post);
---
<article>
  <h1>{post.data.title}</h1>
  <Content />
</article>

Aquí conviven las dos mitades del framework: los datos deciden cuántas páginas hay —una por entrada— y el fichero [slug].astro decide cómo es cada una. El número de páginas ya no lo escribes tú; lo dicta el tamaño de la colección. Es la diferencia entre mantener a mano un fichero por artículo y tener un único fichero que se multiplica solo según el contenido.

flowchart TD
COL[coleccion de posts] --> GSP[getStaticPaths recorre con map]
GSP --> O1[objeto params slug mas props post]
GSP --> O2[objeto params slug mas props post]
O1 --> URL1[params define la url]
O1 --> PG1[props llena Astro props]
O2 --> URL2[params define la url]
O2 --> PG2[props llena Astro props]
PG1 --> R[la pagina renderiza sin volver a consultar]
PG2 --> R
style COL fill:#89b4fa,color:#11111b
style R fill:#a6e3a1,color:#11111b

Observa un matiz de perspectiva. getStaticPaths ve la colección entera: es una vista global, capaz de razonar sobre el conjunto. Cada página, en cambio, solo ve su rebanada: lo que recibe por props. Esa asimetría no es una limitación, es una herramienta. Como la función tiene delante todos los datos a la vez, puede calcular cosas que una página aislada no podría —y pasárselas ya resueltas—.

Enriquecer con datos derivados: vecinos y cálculo global

El caso que mejor muestra el poder de props es el de los datos que solo existen en relación con el conjunto: el post anterior y el siguiente, la posición en una serie, los artículos relacionados. Una página por sí sola no sabe quiénes son sus vecinos; pero getStaticPaths, que ordena la colección completa, sí lo sabe, y puede adjuntar esa información a cada ruta.

---
export async function getStaticPaths() {
  const posts = (await getCollection('blog')).sort(
    (a, b) => b.data.pubDate.valueOf() - a.data.pubDate.valueOf(),
  );
  return posts.map((post, i) => ({
    params: { slug: post.id },
    props: {
      post,
      anterior: posts[i + 1],   // el conjunto conoce a los vecinos
      siguiente: posts[i - 1],
    },
  }));
}
---

La página recibe por props no solo su propia entrada, sino su contexto dentro de la colección, calculado una sola vez y ya listo para pintar unos enlaces de navegación. Reproducir esto desde dentro de cada página obligaría a recargar y reordenar la colección entera en cada una —el mismo trabajo global repetido mil veces— para al final quedarte con dos vecinos. props te deja hacer ese cálculo global donde tiene sentido, una vez, y repartir el resultado.