Una de las ideas más potentes de Astro: el código del frontmatter se ejecuta en el servidor o en build, antes de mandar HTML al navegador. Eso significa que puedes hacer cosas que en una SPA serían impensables sin spinners y useEffect:
await fetch(...) directoEl resultado se renderiza a HTML estático (en sitios SSG) o por petición (en SSR). En ambos casos, el cliente recibe HTML ya pintado: sin estado de carga, sin flash de contenido vacío, sin JS extra.
¿Ves la diferencia con React? No hay useState, no hay useEffect, no hay loading. Astro hace el fetch al construir el sitio, mete los datos en el HTML y lo entrega.
En SSG, no importa: el fetch ocurre una vez, en build. Si la API tarda 800 ms, tu deploy tarda 800 ms más, pero los usuarios reciben HTML estático instantáneo.
En SSR, el fetch ocurre por petición. Aplica las mismas precauciones que cualquier servidor (cachés, timeouts, fallback).
Si la API tiene un schema conocido, declara el tipo:
Y usuarios.map((u) => u.name) ya tiene autocompletado.
Algunas señales para sacarlo a otro sitio:
import.meta.env.SECRETO) que se quedan en build.Puedes hacer Promise.all para paralelizar:
En el editor tienes src/pages/index.astro. Por simplicidad, hemos preparado un array usuarios directamente en el frontmatter (también te dejamos el snippet con fetch real comentado si quieres usarlo).
<ul>, recorre usuarios con {usuarios.map(u => <li>{u.name}</li>)}.id y juega con <strong> o <span> para enriquecer la salida.La idea clave: al construir el sitio, Astro genera un <li> por usuario y los inserta en el HTML final. El navegador no ve ni el array ni el .map: ve <li>...</li> listos.