Astro 2.6: Middleware

¡Astro 2.6 ya está aquí, y es grande! Varias características experimentales han sido marcadas como estables y ahora están disponibles en todos los proyectos de Astro (sin bandera “experimental” requerida):

• Middleware
• Modo de salida SSR híbrido
• Directivas de cliente personalizadas
• Incrustación de CSS

Astro 2.6 también introduce nuevas características y mejoras, incluyendo una nueva característica experimental para gestionar redirecciones:

• Redirecciones (experimental): Configuración de redirecciones de páginas individuales en tu configuración de Astro.
• Mejoras en Markdoc: Markdoc ahora tiene paridad de características con MDX en Astro.
• Mejoras en las herramientas de lenguaje: La extensión de VSCode para Astro recibe una actualización, impulsada por Volar.

Si ya tienes Astro instalado, puedes actualizarlo a la versión 2.6 ejecutando el comando upgrade en tu proyecto (usando tu gestor de paquetes preferido):

npm install astro@latest
pnpm upgrade astro@latest
yarn upgrade astro@latest

Mientras estás en eso, ¡actualiza también cualquier integración y adaptador @astrojs/* que tengas instalado!

Middleware

Middleware ya es estable y está disponible en todos los proyectos sin una bandera experimental. El middleware te permite ejecutar código antes o después de que la página se renderice y se devuelva al usuario. Esto aporta una nueva capa de control a los proyectos de Astro y desbloquea nuevos hooks para autenticación, redirecciones, modificación de headers y más.

export async function onRequest(context, next) {
  // Do something before the request is handled.
  const response = await next()
  // Or, do something before the response is returned.
  return response
}

Astro 2.6 también introdujo un nuevo objeto locals para pasar datos desde el middleware. Cualquier dato adjunto al objeto locals se persiste y está disponible para leer desde el global Astro.locals dentro de cualquier componente de página de Astro o función de endpoint de API.

Aquí tienes un ejemplo de cómo podrías implementar una verificación básica de autenticación dentro de tu middleware, pasando el contexto del usuario cargado a la ruta de la página:

// Example: A simple authentication check in middleware.
export async function onRequest({ cookies, locals }, next) {
  // Check for the "sid" user session ID cookie.
  // Return a 405 (Not Allowed) if the cookie is missing.
  const sessionId = cookies.get("sid");
  if (!sessionId) {
    return new Response(null, {status: 405});
  }
  // Use your own `getUser()` function to validate the user.
  // Return a 405 (Not Allowed) if the user isn't real.
  const user = await getUser(sessionId);
  if (!user) {
    return new Response(null, {status: 405});
  }
  // Attach the loaded user to the `locals` object.
  // Now, it can be read in the page route!
  locals.user = user;
  // Return `next()` to return the response.
  return next();
}

El objeto locals.user ahora está garantizado que exista en tu proyecto, y estará disponible para leer dentro de cualquier página renderizada o handler de endpoint de API.

---
const { user } = Astro.locals
---

<h1>Hello {user.name}!</h1>

El middleware se introdujo por primera vez detrás de una bandera experimental en Astro 2.4. La API ahora es estable y está disponible para todos los desarrolladores de Astro sin una bandera. Lee nuestra guía de documentación de Middleware para saber más.

Modo de Salida SSR Híbrido

El nuevo modo de salida SSR híbrido de Astro ya es estable y está disponible para todos los desarrolladores de Astro sin una bandera experimental. Configurar output: "hybrid" te permite mezclar endpoints de API interactivos y páginas en un sitio mientras mantienes el proyecto generalmente estático y pre-renderizado por defecto.

export default defineConfig({
  output: "hybrid",
  adapter: netlify(),
})

El nuevo modo de salida "hybrid" de Astro ayuda a cerrar la brecha entre lo estático y lo dinámico. El modo de salida híbrido desbloquea la misma funcionalidad SSR en tu proyecto que el modo de salida "server" original, con una diferencia clave: cada página tendrá por defecto pre-renderizado estático. Esto coincide más estrechamente con el comportamiento del modo de compilación "static", donde cada página se pre-renderiza a HTML para respuestas instantáneas desde el servidor o CDN. Pero a diferencia del modo "static", el modo de salida híbrido incluye un servidor en la salida de tu compilación para que ahora puedas añadir páginas dinámicas adicionales y APIs a tu sitio.

Por ejemplo, una agencia podría usar el nuevo modo de salida híbrido de Astro para añadir un handler de formulario dinámico de “Contáctanos” a su sitio web estático en solo unos pocos pasos. Configura la opción output a "hybrid" (y añade un adaptador de despliegue si aún no lo has hecho). Esto mantendrá el mismo comportamiento de “estático por defecto” que antes, pero ahora puedes marcar el endpoint de API de ese formulario como dinámico con export const prerender = false para que se ejecute en cada envío del formulario.

// Mark the page as `prerender = false` to skip pre-rendering
// and run the API endpoint in the server on every submission.
export const prerender = false

export function post({ request }) {
  // ...
}

Esta característica fue contribuida por el miembro de la comunidad de Astro @MoustaphaDev y surgió de nuestro roadmap público y proceso RFC. ¡Gracias!

Directivas de cliente personalizadas

Las directivas de cliente personalizadas ya son estables y están disponibles para todos los desarrolladores de Astro y autores de integraciones sin una bandera experimental.

Las directivas de cliente son la piedra angular de la arquitectura de islas de Astro. Controlan cómo debe cargar la UI interactiva en tu página, a nivel de componente por componente. Astro tiene muchas directivas integradas como client:idle (“Hola Astro, carga este botón cuando la página esté inactiva”) y client:visible (“Hola Astro, solo carga este carrusel de imágenes si se vuelve visible en la página”). Nunca había sido posible definir tus propias directivas de cliente personalizadas, hasta ahora.

Por ejemplo, ahora puedes definir tu propia directiva client:hover que solo cargará e hidratará un componente interactivo cuando el usuario pase el cursor sobre él:

import { defineConfig } from "astro/config"
import onHoverDirective from "./directives/client-hover.js"

export default defineConfig({
  integrations: [onHoverDirective()],
})

Una vez añadida, la integración definiría el comportamiento de client:hover para que pudieras empezar a usarlo en tu propio proyecto:

<Counter client:hover />

¡Crea tus propias directivas de cliente, o publícalas en npm para compartirlas con otros!

Las directivas de cliente personalizadas se introdujeron por primera vez detrás de una bandera experimental en Astro 2.5. La API ahora es estable y está disponible para todos los desarrolladores de Astro sin una bandera. Lee nuestra guía de directivas de cliente personalizadas para saber más.

Incrustación de CSS

Astro 2.6 introduce una nueva opción de configuración para incrustar automáticamente pequeños fragmentos de CSS en tu HTML. Esta optimización puede acelerar la mayoría de las páginas (especialmente en la primera carga) al reducir el número de peticiones y hojas de estilo externas necesarias para cargar la página. Puedes probarlo hoy configurando inlineStylesheets: "auto" en tu archivo de configuración:

import { defineConfig } from "astro/config"

export default defineConfig({
  build: {
    inlineStylesheets: "auto",
  },
})

La incrustación automática de CSS probablemente se convertirá en el comportamiento por defecto en Astro 3.0. Lee nuestra Referencia de Configuración para saber más sobre esta opción y cómo configurarla para tu proyecto.

Esta característica fue contribuida por el miembro de la comunidad de Astro @lilnasy y surgió de nuestro roadmap público y proceso RFC. ¡Gracias!

Redirecciones (experimental)

Astro 2.6 introduce una nueva característica experimental para añadir redirecciones más fácilmente en tu proyecto. Para usarla, necesitarás habilitar la bandera experimental experimental.redirects en el archivo de configuración de tu proyecto.

import { defineConfig } from "astro/config"

export default defineConfig({
  redirects: {
    "/old": "/new",
  },
  experimental: {
    redirects: true,
  },
})

Tradicionalmente, las redirecciones se han dejado para que los desarrolladores las resuelvan por sí mismos. Esto crea más trabajo para el desarrollador y puede ser especialmente difícil de resolver entre diferentes hosts, y de una manera que funcione consistentemente entre desarrollo y producción.

La nueva característica de redirects de Astro resuelve esto con una única API para gestionar tus redirecciones directamente en tu configuración de Astro. Esto funciona tanto en desarrollo como en producción y puede optimizarse aún más para un host específico usando nuestra API de adaptador existente. Por ejemplo, el adaptador de Netlify convertirá automáticamente tus redirecciones en un archivo _redirects específico de Netlify para el máximo rendimiento posible a través de su CDN.

Nuestro objetivo es tener una forma fiable de configurar redirecciones que funcione en todos nuestros hosts y adaptadores soportados. Estamos buscando feedback durante este período experimental, así que pruébalo y comparte tu experiencia con nosotros en Discord.

Mejoras en Markdoc

El soporte de Markdoc en Astro sigue mejorando con la última versión de @astrojs/markdoc. Esta nueva versión trae paridad completa de características con Markdown y MDX en Astro, incluyendo generación automática de id en encabezados, mejor soporte para resaltado de sintaxis, y soporte para extensiones de configuración con extends.

Hemos trabajado estrechamente con el equipo de Markdoc en Stripe para seguir mejorando la experiencia de creación de contenido en Astro. Ver el ecosistema de Markdoc crecer ha sido emocionante, ¡y estamos orgullosos de ser parte de ello!

Mejoras en las Herramientas de Lenguaje

Las herramientas de lenguaje de Astro recibieron una importante actualización con el lanzamiento 2.0 de @astrojs/language-server y la Extensión 2.0 de VSCode para Astro. Esta versión completa una reescritura importante y migración interna a Volar para mejorar el rendimiento, las características y la estabilidad.

Volar es un framework genérico para herramientas de lenguaje del equipo de Vue. Usar un framework como Volar aporta varios beneficios a nuestro servidor de lenguaje, de forma similar a cómo Astro usa Vite internamente. Volar nos permite pasar menos tiempo recreando laboriosamente herramientas y más tiempo construyendo características para nuestros usuarios. VSCode, astro check, y todos los demás consumidores del servidor de lenguaje de Astro deberían beneficiarse de este cambio.

Volar se está convirtiendo rápidamente en un framework estándar sobre el que todos los lenguajes pueden construir, y estamos emocionados de apoyar el proyecto. Esperamos seguir mejorando Volar para todos, incluyendo los desarrolladores de Astro.

Un agradecimiento especial a Johnson Chu (mantenedor de Volar) por ayudarnos con este proyecto.