michael/astro
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

docs: spanish translation (#1531)

Browse source
This commit is contained in:
Jorge del Casar 2021-10-12 19:02:34 +02:00 committed by GitHub
parent 6ea1119a32
commit f6d0631cee
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
25 changed files with 2104 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

30
docs/src/config.ts
View file

@ -57,6 +57,36 @@ export const SIDEBAR = {
{ text: 'Comienzo rápido', link: 'es/quick-start' },
{ text: 'Instalación', link: 'es/installation' },
{ text: 'Astro vs. X', link: 'es/comparing-astro-vs-other-tools' },
{ text: 'Fundamentos', header: true },
{ text: 'Estructura del Proyecto', link: 'es/core-concepts/project-structure' },
{ text: 'Sintaxis del Componente', link: 'es/core-concepts/astro-components' },
{ text: 'Páginas', link: 'es/core-concepts/astro-pages' },
{ text: 'Maquetas', link: 'es/core-concepts/layouts' },
{ text: 'Enrutamiento', link: 'es/core-concepts/routing' },
{ text: 'Hidratación parcial', link: 'es/core-concepts/component-hydration' },
{ text: 'Guías', header: true },
{ text: 'Estilo y CSS', link: 'es/guides/styling' },
{ text: 'Markdown', link: 'es/guides/markdown-content' },
{ text: 'Depuración', link: 'es/guides/debugging' },
{ text: 'Obtención de datos', link: 'es/guides/data-fetching' },
{ text: 'Paginación', link: 'es/guides/pagination' },
{ text: 'RSS', link: 'es/guides/rss' },
{ text: 'Importaciones admitidas', link: 'es/guides/imports' },
{ text: 'Alias', link: 'es/guides/aliases' },
{ text: 'Desplegar en la web', link: 'es/guides/deploy' },
{ text: 'Publicar en npm', link: 'es/guides/publish-to-npm' },
{ text: 'Referencia', header: true },
{ text: 'Componentes incorporados', link: 'es/reference/builtin-components' },
{ text: 'Referencia de API', link: 'es/reference/api-reference' },
{ text: 'Referencia de CLI', link: 'es/reference/cli-reference' },
{
text: 'Referencia de configuración',
link: 'es/reference/configuration-reference',
},
{ text: 'Referencia de renderizador', link: 'es/reference/renderer-reference' },
],
'zh-CN': [
{ text: '起步', header: true },

22
docs/src/pages/es/comparing-astro-vs-other-tools.md
View file

@ -22,7 +22,7 @@ Docusaurus fue diseñada para construir la documentación de las páginas web y
#### Comparando el Rendimiento de Docusaurus vs. Astro
En la mayoría de casos, los sitios web de Astro cargarán mucho más rápido que los sitios web de Docusaurus. Esto es porque Astro automáticamente quita el código JavaScript innecesario de la página, cargando sólo los componentes individuales que la página que necesita. Esta característica se llama [hidratación parcial](/core-concepts/component-hydration).
En la mayoría de casos, los sitios web de Astro cargarán mucho más rápido que los sitios web de Docusaurus. Esto es porque Astro automáticamente quita el código JavaScript innecesario de la página, cargando sólo los componentes individuales que la página que necesita. Esta característica se llama [hidratación parcial](/es/core-concepts/component-hydration).
Docusaurus no soporta hidratación parcial, en lugar de eso, hace que el usuario cargue y rehidrata la página completa en el navegador, incluso si la mayoría del contenido de la página es estático. Esto crea una carga de página más lenta y un peor rendimiento para tu sitio web. No hay manera de deshabilitar este comportamiento en Docusaurus.
@ -41,9 +41,9 @@ Una de las más grandes razones detrás de la diferencia en los rendimientos es
Elder.js utiliza Svelte para generar tu sitio web. Astro es más flexible: eres libre de crear un componente UI en cualquier librería popular (React, Preact, Vue, Svelte, Solid entre otros) o puedes crear un componente de Astro con una sintaxis parecida a HTML, que es similar a HTML + JSX.
Elder.js es el único en esta lista, junto con Astro, que soporta [hidratación parcial](/core-concepts/component-hydration). Astro y Elder.js automáticamente quitan el código JavaScript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Elder.js tiene una API de hidratación parcial un poco diferente, pero Astro soporta algunas características que Elder.js no soporta (como `client:media`). Sin embargo, ambos generadores de sitios web construyen sitios web similares en temas de rendimiento.
Elder.js es el único en esta lista, junto con Astro, que soporta [hidratación parcial](/es/core-concepts/component-hydration). Astro y Elder.js automáticamente quitan el código JavaScript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Elder.js tiene una API de hidratación parcial un poco diferente, pero Astro soporta algunas características que Elder.js no soporta (como `client:media`). Sin embargo, ambos generadores de sitios web construyen sitios web similares en temas de rendimiento.
Elder.js utiliza una solución de rutas personalizadas que puede sentirse poco familiar para los nuevos desarrolladores. Astro utiliza [rutas basadas en archivos](/core-concepts/routing) que debería sentirse familiar a todos los desarrolladores que han visto Next.js, SvelteKit y otros generadores de sitios web estáticos como Eleventy.
Elder.js utiliza una solución de rutas personalizadas que puede sentirse poco familiar para los nuevos desarrolladores. Astro utiliza [rutas basadas en archivos](/es/core-concepts/routing) que debería sentirse familiar a todos los desarrolladores que han visto Next.js, SvelteKit y otros generadores de sitios web estáticos como Eleventy.
Elder.js fue diseñado para correr en sitios web grandes y afirma que puede construir un sitio web de 20 mil páginas en menos de 10 minutos (en una modesta máquina virtual). Al momento de escribir esto, Astro construye mil páginas en 66 segundos, pero aún no ha sido probado en proyectos de más de 20 mil páginas. Astro está aún en la fase inicial y la meta para Astro v1.0 es alcanzar la velocidad de construcción sitios web de Elder.js.
@ -61,7 +61,7 @@ Conceptualmente, Eleventy está alineado con el enfoque de Astro sobre "el uso m
Eleventy alcanza este punto al empujarte a evitar usar Javascript. Los sitios de Eleventy son escritos, con frecuencia, con poco o ninguna línea de Javascript. Esto se convierte en un problema cuando necesitas Javascript en el lado del cliente. Es tu responsabilidad crear tu propia línea de construcción de recursos para Eleventy. Esto puede ser una tarea difícil y te obliga a configurar una gran cantidad de optimizaciones, como la fusión de archivos, la minificación y otros.
Por otro lado, Astro automáticamente construye el CSS y Javascript en el lado del cliente por ti. Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Está funcionalidad se llama [hidratación parcial](/core-concepts/component-hydration). Mientras que en Eleventy lo puedes alcanzar esto por ti mismo; Astro la ofrece desde el inicio y sin configuración extra.
Por otro lado, Astro automáticamente construye el CSS y Javascript en el lado del cliente por ti. Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Está funcionalidad se llama [hidratación parcial](/es/core-concepts/component-hydration). Mientras que en Eleventy lo puedes alcanzar esto por ti mismo; Astro la ofrece desde el inicio y sin configuración extra.
## Gatsby vs. Astro
@ -75,7 +75,7 @@ Gatsby requiere de una API personalizada de GraphQL para trabajar con todo el co
#### Comparando el Rendimiento de Gatsby vs. Astro
En la mayoría de casos, los sitios de Astro cargarán mucho más rápido que los sitios de Gatsby. Esto pasa porque Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/core-concepts/component-hydration).
En la mayoría de casos, los sitios de Astro cargarán mucho más rápido que los sitios de Gatsby. Esto pasa porque Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/es/core-concepts/component-hydration).
Gatsby no soporta la hidratación parcial. En su lugar, hace que el usuario cargue e hidrate la página completa en el navegador, incluso si la mayoría del contenido es estático. Esto hace que las páginas carguen más lentamente y que el rendimiento sea más bajo para tu sitio web. Gatsby tiene [un plugin comunitario](https://www.gatsbyjs.com/plugins/gatsby-plugin-no-javascript/) para remover todo el Javascript de la página, pero esto rompería muchos sitios web. Esto le queda a usted con una decisión de todo-o-nada para la interactividad en cada una de las páginas.
@ -100,7 +100,7 @@ Hugo utiliza una [plantilla de lenguajes personalizados](https://gohugo.io/templ
Conceptualmente, Hugo está alineado con el enfoque de Astro sobre "el uso mínimo de Javascript en el lado del cliente". Tanto Hugo y Astro ofrecen un rendimiento similar, un uso extremadamente bajo de Javascript por defecto.
Tanto Hugo como Astro, traen incorporado soporte para la construcción, el empaquetado y la minificación de JavaScript. Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/core-concepts/component-hydration). Mientras que esto lo puedes hacer en Hugo por ti mismo, Astro lo ofrece incorporado por defecto.
Tanto Hugo como Astro, traen incorporado soporte para la construcción, el empaquetado y la minificación de JavaScript. Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/es/core-concepts/component-hydration). Mientras que esto lo puedes hacer en Hugo por ti mismo, Astro lo ofrece incorporado por defecto.
## Jekyll vs. Astro
@ -128,7 +128,7 @@ SvelteKit soporta tanto Static Site Generation (SSG) como Server-Side Rendering
#### Comparando el Rendimiento de SveltKit vs. Astro
En la mayoría de casos, los sitios de Astro cargarán mucho más rápido que los sitios de SveltKit. Esto pasa porque Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/core-concepts/component-hydration).
En la mayoría de casos, los sitios de Astro cargarán mucho más rápido que los sitios de SveltKit. Esto pasa porque Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/es/core-concepts/component-hydration).
SveltKit no soporta la hidratación parcial, en su lugar hace que el usuario cargue e hidrate la página completa en el navegador, incluso si la mayoría del contenido de la página es estático. Esto crea una carga de página más lenta y un rendimiento inferior para tu sitio web. SveltKit ofrece soporte para [páginas estáticas, con cero JavaScript](https://kit.svelte.dev/docs#ssr-and-javascript-hydrate). Sin embargo, en su página no hay planificación para realizar la hidratación parcial de componentes individuales. Por lo tanto, queda a tu criterio tomar la decisión de todo-o-nada en la interactividad de cada página.
@ -155,7 +155,7 @@ Next.js soporta tanto Static Site Generation (SSG) como Server-Side Rendering (S
#### Comparando el Rendimiento de Gatsby vs. Astro
En la mayoría de casos, los sitios de Astro cargarán mucho más rápido que los sitios de Next.js. Esto pasa porque Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/core-concepts/component-hydration).
En la mayoría de casos, los sitios de Astro cargarán mucho más rápido que los sitios de Next.js. Esto pasa porque Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/es/core-concepts/component-hydration).
Next.js no soporta hidratación parcial, en su lugar hace que el usuario cargue e hidrate la página completa en el navegador, incluso si la mayoría del contenido de la página es estático. Esto crea una carga de página más lenta y un rendimiento inferior para tu sitio web. Next.js ofrece un [ soporte experimental](https://piccalil.li/blog/new-year-new-website/#heading-no-client-side-react-code) para sitios completamente estáticos con cero Javascript. Sin embargo, en su página no hay planificación para realizar la hidratación parcial de componentes individuales. Por lo tanto, queda a tu criterio tomar la decisión de todo-o-nada en la interactividad de cada página.
@ -182,7 +182,7 @@ Nuxt soporta tanto Static Site Generation (SSG) como Server-Side Rendering (SSR)
#### Comparando el Rendimiento de Nuxt vs. Astro
En la mayoría de casos, los sitios de Astro cargarán mucho más rápido que los sitios de Nuxt. Esto pasa porque Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/core-concepts/component-hydration).
En la mayoría de casos, los sitios de Astro cargarán mucho más rápido que los sitios de Nuxt. Esto pasa porque Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/es/core-concepts/component-hydration).
Nuxt no soporta hidratación parcial, en su lugar hace que el usuario cargue e hidrate la página completa en el navegador, incluso si la mayoría del contenido de la página es estático. Esto crea una carga de página más lenta y un rendimiento inferior para tu sitio web. No hay forma de deshabilitar este comportamiento en Nuxt.
@ -207,7 +207,7 @@ Actualmente, Evan You (creador de Vue.js) está trabajando en una nueva versión
#### Comparando el VuePress de Gatsby vs. Astro
En la mayoría de casos, los sitios de Astro cargarán mucho más rápido que los sitios de VuePress. Esto pasa porque Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/core-concepts/component-hydration).
En la mayoría de casos, los sitios de Astro cargarán mucho más rápido que los sitios de VuePress. Esto pasa porque Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/es/core-concepts/component-hydration).
VuePress no soporta hidratación parcial, en su lugar hace que el usuario cargue e hidrate la página completa en el navegador, incluso si la mayoría del contenido de la página es estático. Esto crea una carga de página más lenta y un rendimiento inferior para tu sitio web. No hay forma de deshabilitar este comportamiento en VuePress.
@ -230,4 +230,4 @@ Zola utiliza [Tera](https://tera.netlify.app/) para renderizar tu sitio web. Ast
Conceptualmente, Zola está alineado con el enfoque de Astro sobre "el uso mínimo de Javascript en el lado del cliente". Tanto Zola y Astro ofrecen un rendimiento similar, un uso extremadamente bajo de Javascript por defecto.
Astro ofrece soporte para construir, empaquetar y minimizar JavaScript. Zola requiere usar otra herramienta de construcción como Webpack para empaquetar y procesar JavaScript. Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/core-concepts/component-hydration). Mientras que Zola puedes hacerlo por ti mismo, Astro lo ofrece incorporado por defecto.
Astro ofrece soporte para construir, empaquetar y minimizar JavaScript. Zola requiere usar otra herramienta de construcción como Webpack para empaquetar y procesar JavaScript. Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/es/core-concepts/component-hydration). Mientras que Zola puedes hacerlo por ti mismo, Astro lo ofrece incorporado por defecto.

380
docs/src/pages/es/core-concepts/astro-components.md Normal file
View file

@ -0,0 +1,380 @@
---
layout: ~/layouts/MainLayout.astro
title: Componentes de Astro
lang: es
---
Los **componentes de Astro** (archivos que terminan con `.astro`) son la base de las plantillas del lado del servidor en Astro. Piensa en la sintaxis del componente Astro como HTML mejorado con JavaScript.
Aprender una nueva sintaxis puede ser intimidante, por lo que cuidadosamente diseñamos la sintaxis del componente Astro para que los desarrolladores web se familizarizen lo más pronto posible. En gran medida se basa en patrones que probablemente ya conozcas: componentes, portada, propiedades y expresiones JSX. Estamos seguros de que esta guía te permitirá escribir componentes de Astro en poco tiempo, especialmente si ya estás familiarizado con HTML y JavaScript.
## Visión general de la sintaxis
Un único archivo `.astro` representa un solo componente Astro en tu proyecto. Este patrón se conoce como **Componente de archivo único (SFC, del inglés Single-File Component)**. Tanto Svelte (`.svelte`) como Vue (`.vue`) también siguen este patrón.
A continuación se muestra un recorrido por las diferentes piezas y características de la sintaxis del componente Astro. Puedes leerlo de principio a fin o saltar entre secciones.
### Plantilla HTML
La sintaxis del componente Astro es un superconjunto de HTML. **Si conoces HTML, ya sabes lo suficiente como para escribir tu primer componente Astro.**
Por ejemplo, este archivo de tres líneas es un componente Astro válido:
```html
<!-- Ejemplo1.astro - ¡El HTML estático es un componente Astro válido! -->
<div class="ejemplo-1">
<h1>¡Hola mundo!</h1>
</div>
```
Un componente Astro representa un fragmento de HTML en tu proyecto. Puede ser un componente reutilizable o una página completa de HTML que incluya elementos `<html>`, `<head>` y `<body>`. Consulta nuestra guía sobre [Páginas de Astro](/es/core-concept/astro-pages) para aprender a crear tu primera página HTML completa con Astro.
**Cada componente de Astro debe incluir una plantilla HTML.** Aunque puede mejorar su componente de varias maneras (ver más abajo), al fin y al cabo es la plantilla HTML la que dicta cómo se verá tu componente Astro renderizado.
### Estilos CSS
Las reglas CSS dentro de una etiqueta `<style>` se ajustan automáticamente a ese componente. Eso significa que puedes reutilizar los nombres de las clases en varios componentes, sin preocuparse por los conflictos. Los estilos se extraen y optimizan automáticamente en la compilación final para que no tengas que preocuparte por la carga de estilos.
Para obtener los mejores resultados, solo debes tener una etiqueta `<style>` por componente Astro. Esto no es necesariamente una limitación, pero a menudo dará como resultado un CSS mejor optimizado en su compilación final. Cuando trabajas con páginas, la etiqueta `<style>` puede ir anidada dentro de tu página `<head>`. Para los componentes independientes, la etiqueta `<style>` puede ir al nivel superior de su plantilla.
```html
<!-- Ejemplo de CSS del componente Astro -->
<style>
.circle {
background-color: red;
border-radius: 999px;
height: 50px;
width: 50px;
}
</style>
<div class="circle"></div>
```
```html
<!-- Ejemplo de CSS de Astro Page -->
<html>
<head>
<style>
...;
</style>
</head>
<body>
...
</body>
</html>
```
El uso de `<style global>` omitirá el alcance automático para cada regla CSS en el bloque `<style>`. Esta trampilla de escape debe evitarse si es posible, pero puede ser útil si, por ejemplo, necesitas modificar el estilo de los elementos HTML agregados por una librería externa.
Sass (una alternativa a CSS) está también disponible mediante `<style lang="scss">`.
📚 Lee nuestra guía completa sobre [Estilo de los componentes](/es/guides/styling) para obtener más información.
### Script preliminar
Para construir componentes dinámicos, presentamos la idea de un script preliminar del componente. [Frontmatter](https://jekyllrb.com/docs/front-matter/) es un patrón común en Markdown, donde algunos config/metadata están contenidos dentro de una valla de código (`---`) en la parte superior del archivo . Astro hace algo similar, pero con soporte completo para JavaScript y TypeScript en sus componentes.
Recuerda que Astro es un lenguaje de plantillas del lado del servidor, por lo que el script de su componente se ejecutará durante la compilación, pero solo el HTML se representará en el navegador. Para enviar JavaScript al navegador, puedes usar una etiqueta `<script>` en su plantilla HTML o [convertir tu componente para usar un framework de frontend](/es/core-concept/component-hydration) como React, Svelte, Vue, etc.
```astro
---
// Todo lo que esté dentro de la valla de código `---` es el script de tu componente.
// Este código JavaScript se ejecuta en tiempo de compilación.
// Consulte a continuación para obtener más información sobre lo que puede hacer.
console.log('Esto se ejecuta en el momento de la compilación, es visible en la salida CLI');
// Consejo: ¡TypeScript también es compatible de forma inmediata!
const thisWorks: number = 42;
---
<div class="ejemplo-1">
<h1>¡Hola mundo!</h1>
</div>
```
### Importaciones de componentes
Un componente Astro puede reutilizar otros componentes Astro dentro de su plantilla HTML. Esto se convierte en la base de nuestro sistema de componentes: crea nuevos componentes y luego reutilízalos en todo tu proyecto.
Para utilizar un componente Astro en tu plantilla, primero debes importarlo en el script preliminar del componente. Un componente Astro es siempre la importación predeterminada del archivo.
Una vez importado, puedes usarlo como cualquier otro elemento HTML en tu plantilla. Ten en cuenta que un componente de Astro **DEBE** comenzar con una letra mayúscula. Astro usará esto para distinguir entre elementos HTML nativos (`from`,` input`, etc.) y tus componentes Astro personalizados.
```astro
---
// Importa tus componentes en tu script del componente
import AlgunComponente from './AlgunComponente.astro';
---
<!-- ... ¡luego utilízalos en su HTML! -->
<div>
<AlgunComponente />
</div>
```
📚 También puedes importar y usar componentes de otros frameworks frontend como React, Svelte y Vue. Lee nuestra guía sobre [Hidratación de componentes](/es/core-concept/component-hydration) para obtener más información.
### Expresiones JSX dinámicas
En lugar de inventar nuestra propia sintaxis personalizada para la creación de plantillas dinámicas, te brindamos acceso directo a los valores de JavaScript dentro de su HTML, utilizando algo que se parece a [JSX](https://reactjs.org/docs/introducing-jsx.html) .
Los componentes Astro pueden definir variables locales dentro del script de Frontmatter. Todas las variables de secuencia de comandos están disponibles automáticamente en la plantilla HTML a continuación.
#### Dynamic Values
```astro
---
const nombre = "Tu nombre aquí";
---
<div>
<h1>¡Hola {nombre}!</h1>
</div>
```
#### Atributos dinámicos
```astro
---
const nombre = "Tu nombre aquí";
---
<div>
<div data-nombre={nombre}>Se admiten expresiones de atributo</div>
<div data-consejo={`Utilice cadenas de plantilla JS para mezclar ${"variables"}.`}>¡Qué bueno!</div>
</div>
```
#### HTML Dinámico
```astro
---
const elementos = ["Perro", "Gato", "Ornitorrinco"];
---
<ul>
{elementos.map((elemento) => (
<li>{elemento}</li>
))}
</ul>
```
### Propiedades del Componente
Un componente Astro puede definir y aceptar propiedades. Las propiedades están disponibles en el global `Astro.props` en su script preliminar.
```astro
---
// Ejemplo: <AlgunComponente saludo="(Opcional) Hola" name="Nombre requerido" />
const { saludo = 'Hola', nombre } = Astro.props;
---
<div>
<h1>¡{saludo}, {nombre}!</h1>
</div>
```
Puedes definir tus propiedades con TypeScript exportando un `Props` de tipo _interface_.
> _**En el futuri**_, Astro recogerá automáticamente cualquier interfaz de `Props` exportada y dará advertencias/errores de tipo para su proyecto.
```astro
---
// Ejemplo: <AlgunComponente /> (CUIDADO: propiedad "nombre" obligatoria)
export interface Props {
nombre: string;
saludo?: string;
}
const { saludo = 'Hola', nombre } = Astro.props;
---
<div>
<h1>¡{saludo}, {nombre}!</h1>
</div>
```
Luego puede pasar las propiedades del componente de esta manera:
```astro
---
// AlgunOtroCompoennte.astro
import AlgunComponente from "./AlgunComponente.astro";
let nombreDePila = "mundo";
---
<AlgunComponente nombre={nombreDePila}/>
```
### Ranuras
Los archivos `.astro` utilizan la etiqueta [`<slot>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/slot) para habilitar la composición de componentes. Viniendo de React o Preact, este es el mismo concepto que `hijos`. Puedes pensar en el elemento `<slot>` como un marcador de posición para el marcado que se pasará desde fuera del componente.
```astro
<!-- Example: MiComponente.astro -->
<div id="mi-componente">
<slot /> <!-- los hijos irán aquí -->
</div>
<!-- Usage -->
<MiComponente>
<h1>¡Hola mundo!</h1>
</MiComponente>
```
Ten en cuenta que si la etiqueta `<slot>` no se usa en la plantilla HTML, los elementos secundarios pasados al componente no se procesarán.
Las ranuras se vuelven aún más poderosas cuando se utilizan **ranuras con nombre **. En lugar de un solo elemento `<slot>` que representa a _todos_ los hijos, las ranuras con nombre te permiten especificar varios lugares donde los hijos deben ser colocados.
> **Nora:** El atributo `slot` attribute no está restringido a HTML simple, ¡los componentes también pueden usar `slot`!
```astro
<!-- Ejemplo: MiComponente.astro -->
<div id="mi-componente">
<header>
<!-- hijo con el atributo `slot="cabecera"` irá aquí -->
<slot name="cabecera" />
</header>
<main>
<!-- hijo sin atributo `slot` (or con el `slot="default"`) irá aquí -->
<slot />
</main>
<footer>
<!-- hijo con el atributo `slot="pie"` irá aquí -->
<slot name="pie" />
</footer>
</div>
<!-- Usage -->
<MiComponente>
<h1 slot="cabecera">¡Hola mundo!</h1>
<p>Lorem ipsum ...</p>
<FooterComponent slot="pie" />
</MiComponente>
```
Las ranuras también pueden devolver **contenido de respaldo**. Cuando no hay hijos pasados a un `<slot>` que coincidan, un elemento `<slot>` renderizará sus propios hijos de marcador de posición.
Slots can also render **fallback content**. When there are no matching children passed to a `<slot>`, a `<slot>` element will render its own children.
```astro
<!-- MiComponente.astro -->
<div id="mi-componente">
<slot>
<h1>¡Me renderizaré cuando esta ranura no tenga hijos!</h1>
</slot>
</div>
<!-- Usage -->
<MiComponente />
```
### Fragmentos y elementos múltiples
Una plantilla de componente Astro puede representar tantos elementos de nivel superior como desees. A diferencia de otros frameworks de componentes de interfaz de usuario, no es necesario que envuelvas todo en un único `<div>` si prefieres no hacerlo.
```html
<!-- Un componente Astro puede contener varios elementos HTML de nivel superior: -->
<div id="a" />
<div id="b" />
<div id="c" />
```
Sin embargo, cuando trabajes dentro de una expresión JSX, debes envolver varios elementos dentro de un **Fragmento**. Los fragmentos te permiten renderizar un conjunto de elementos sin agregar nodos adicionales al DOM. Esto es necesario en las expresiones JSX debido a una limitación de JavaScript: nunca puede "devolver" más de una cosa en una función o expresión de JavaScript. El uso de un fragmento resuelve este problema.
Un Fragmento debe abrirse con `<>` y cerrarse con `</>`. No se preocupe si olvida esto, el compilador de Astro le advertirá que debe agregar uno.
```astro
---
const elementos = ["Perro", "Gato", "Ornitorrinco"];
---
<ul>
{elementos.map((elemento) => (
<>
<li>{elemento} rojo</li>
<li>{elemento} azul</li>
<li>{elemento} verde</li>
</>
))}
</ul>
```
### Scripts izados
Por defecto, Astro no hace ninguna suposición sobre cómo deseas que se sirvan los scripts, por lo que si agregas una etiqueta `<script>` en una página o un componente, se quedará sola.
Sin embargo, si deseas que todos tus scripts se extraigan de los componentes y se muevan a la parte superior de la página, y luego se agrupen en producción, puedes lograrlo con scripts izados.
Un **script izado** se ve así:
```astro
<script hoist>
// Una secuencia de comandos en línea
</script>
```
O puede vincularse a un archivo JavaScript externo:
```astro
<script src={Astro.resolve('./mi-componente.js')} hoist></script>
```
Un script elevado puede estar dentro de una página o un componente, y no importa cuántas veces se use el componente, el script solo se agregará una vez:
```astro
---
import TwitterTimeline from '../components/TwitterTimeline.astro';
---
<-- The script will only be injected into the head once. -->
<TwitterTimeline />
<TwitterTimeline />
<TwitterTimeline />
```
## Comparando `.astro` versus` .jsx`
Los archivos `.astro` puede terminar pareciendo muy similares a los archivos `.jsx`, pero hay algunas diferencias claves. Aquí hay una comparación entre los dos formatos.
| Feature | Astro | JSX |
| ------------------------------------ | ------------------------------------------ | -------------------------------------------------------------- |
| Extensión de archivo | `.astro` | `.jsx` or `.tsx` |
| Componentes definidos por el usuario | `<Capitalized>` | `<Capitalized>` |
| Sintaxis de expresiones | `{}` | `{}` |
| Difundir atributos | `{...props}` | `{...props}` |
| Atributos booleanos | `autocomplete` === `autocomplete={true}` | `autocomplete` === `autocomplete={true}` |
| Funciones en línea | `{items.map(item => <li>{item}</li>)}` | `{items.map(item => <li>{item}</li>)}` |
| Soporte IDE | WIP - [VS Code][code-ext] | Fenomenal |
| Requiere importación JS | No | Sí, `jsxPragma` (`React` or `h`) debe estar dentro del alcance |
| Fragmentos | Automatic top-level, `<>` inside functions | Envolver con `<Fragment>` or `<>` |
| Múltiples frameworks por archivo | Yes | No |
| Modificando `<head>` | Just use `<head>` | Por-framework (`<Head>`, `<svelte:head>`, etc) |
| Estilo de comentario | `<!-- HTML -->` | `{/* JavaScript */}` |
| Caracteres especiales | `&nbsp;` | `{'\xa0'}` or `{String.fromCharCode(160)}` |
| Atributos | `dash-case` | `camelCase` |
## Resolución de URL
Es importante tener en cuenta que Astro **no** transformará las referencias HTML por ti. Por ejemplo, considera una etiqueta `<img>` con un atributo relativo `src` dentro de `src/pages/about.astro`:
```html
<!-- ❌ Incorrecto: Intentará cargar `/about/thumbnail.png` -->
<img src="./thumbnail.png" />
```
Dado que `src/pages/about.astro` se compilará en `/about/index.html`, es posible que no haya esperado que la imagen viva en `/about/thumbnail.png`. Entonces, para solucionar este problema, elige una de las dos opciones:
#### Opción 1: URL absolutas
```html
<!-- ✅ Correcto: referencia a public/thumbnail.png -->
<img src="/thumbnail.png" />
```
El enfoque recomendado es colocar archivos dentro de `public/*`. Esto hace referencia a un archivo en `public/thumbnail.png`, que se resolverá en `/thumbnail.png` en la compilación final (ya que `public/` termina en `/`).
#### Opción 2: Referencias de importación de activos
```astro
---
// ✅ Correcto: referencia a src/thumbnail.png
import thumbnailSrc from './thumbnail.png';
---
<img src={thumbnailSrc} />
```
Si prefieres organizar los activos junto con los componentes de Astro, puedes importar el archivo en JavaScript dentro del script del componente. Esto funciona según lo previsto, pero hace que sea más difícil hacer referencia a `thumbnail.png` en otras partes de su aplicación, ya que su URL final no es fácilmente predecible (a diferencia de los recursos en ` public/*`, donde se garantiza que la URL final nunca cambia).
[code-ext]: https://marketplace.visualstudio.com/items?itemName=astro-build.astro-vscode

68
docs/src/pages/es/core-concepts/astro-pages.md Normal file
View file

@ -0,0 +1,68 @@
---
layout: ~/layouts/MainLayout.astro
title: Páginas
lang: es
---
**Páginas** son un tipo especial de [Componente de Astro](/es/core-concepts/astro-components) que manejan el enrutamiento, la carga de datos y la creación de plantillas para cada página de su sitio web. Puedes pensar en ellos como cualquier otro componente de Astro, solo que con responsabilidades adicionales.
Astro también admite Markdown para páginas con mucho contenido, como publicaciones de blogs y documentación. Consulta [Contenido de Markdown](/es/guides/markdown-content) para obtener más información sobre cómo escribir páginas con Markdown.
## Enrutamiento basado en archivos
Astro usa Páginas para hacer algo llamado **enrutamiento basado en archivos.** Cada archivo en tu directorio `src/pages` se convierte en una página en tu sitio, usando el nombre del archivo para decidir la ruta final.
Los Componentes de Astro (`.astro`) y archivos Markdown (`.md`) son los únicos formatos admitidos para las páginas. No se admiten otros tipos de páginas (como un componente React `.jsx`), pero puedes usar cualquier cosa como componente de la interfaz de usuario dentro de una página `.astro` para lograr un resultado similar.
```
src/pages/index.astro -> mysite.com/
src/pages/about.astro -> mysite.com/about
src/pages/about/index.astro -> mysite.com/about
src/pages/about/me.astro -> mysite.com/about/me
src/pages/posts/1.md -> mysite.com/posts/1
```
## Plantillas de página
Todos los componentes de Astro son responsables de devolver HTML. Las páginas de Astro también devuelven HTML, pero tienen la responsabilidad única de devolver una respuesta de página completa `<html> ... </html>`, incluyendo `<head>` ([MDN <span class = "sr-only">- head</span>](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/head)) y `<body>` ([MDN <span class = "sr-only ">- body</span>](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/body)).
`<! doctype html>` es opcional y se agregará automáticamente.
```astro
---
// Ejemplo: esqueleto de página HTML
---
<!doctype html>
<html>
<head>
<title>Título del documento</title>
</head>
<body>
<h1>¡Hola mundo!</h1>
</body>
</html>
```
## Carga de datos
Las páginas de Astro pueden obtener datos para ayudar a generar tus páginas. Astro proporciona dos herramientas diferentes a las páginas para ayudarte a hacer esto: **fetch()** y **await de alto nivel**.
📚 Lee nuestra [guía completa sobre la obtención de datos](/es/guides/data-fetching) para obtener más información.
```astro
---
// Ejemplo: los scripts del componente de Astro se ejecutan en el momento de la compilación
const response = await fetch('http://example.com/movies.json');
const data = await response.json();
console.log(data);
---
<!-- Envía el resultado a la página -->
<div>{JSON.stringify(data)}</div>
```
## Página de error 404 personalizada
Para una página de error 404 personalizada, crea un archivo `404.astro` en `/src/pages`. Eso genera una página `404.html`. La mayoría de los [servicios de despliegue](/es/guides/deploy) lo encontrarán y lo utilizarán.
Esto es especial y diferente al comportamiento predeterminado de construir `page.astro` (o `page/index.astro`) a `page/index.html`.

114
docs/src/pages/es/core-concepts/component-hydration.md Normal file
View file

@ -0,0 +1,114 @@
---
layout: ~/layouts/MainLayout.astro
title: Hidratación Parcial en Astro
lang: es
---
**Astro genera todos los sitios web sin JavaScript en el lado del cliente, de forma predeterminada.** Utiliza cualquier componente de interfaz de usuario que desee (React, Svelte, Vue, etc.) y Astro lo representará automáticamente en HTML en el momento de la compilación y elimina todo el JavaScript. Esto mantiene todos los sitios rápidos de forma predeterminada.
Pero a veces, se requiere JavaScript del lado del cliente. Esta guía muestra cómo funcionan los componentes interactivos en Astro mediante una técnica llamada hidratación parcial.
```astro
---
// Ejemplo: Importar y luego usar un componente React.
// De forma predeterminada, Astro representa esto en HTML y CSS durante
// su compilación, sin JavaScript del lado del cliente.
// (¿Necesitas JavaScript del lado del cliente? Sigue leyendo...)
import MyReactComponent from '../components/MyReactComponent.jsx';
---
<!-- 100% HTML, Zero JavaScript! -->
<MyReactComponent />
```
## Concepto: Hidratación parcial
Hay muchos casos en los que necesita un componente de UI interactivo para ejecutarse en el navegador:
- Un carrusel de imágenes
- Una barra de búsqueda de autocompletar
- Un botón de apertura/cierre de la barra lateral móvil
- Un botón "Comprar ahora"
En Astro, depende de ti, como desarrollador, "habilitar" explícitamente cualquier componente de la página que deba ejecutarse en el navegador. Astro puede usar esta información para saber exactamente qué JavaScript se necesita y solo hidratar exactamente lo que se necesita en la página. Esta técnica se conoce como hidratación parcial.
**Hidratación parcial**, el acto de solo hidratar los componentes individuales que requieren JavaScript y dejar el resto de su sitio como HTML estático, puede parecer relativamente sencillo. ¡Debería! Los sitios web se han construido de esta manera durante décadas. Recientemente, las aplicaciones de una sola página (SPA) introdujeron la idea de que todo su sitio web está escrito en JavaScript y compilado/renderizado por cada usuario en el navegador.
_Nota: La hidratación parcial a veces se denomina "mejora progresiva" o "hidratación progresiva". Si bien hay ligeros matices entre los términos, para nuestros propósitos, puede pensar en todos ellos como sinónimos del mismo concepto.
**La hidratación parcial es el secreto de la historia de rendimiento rápido por defecto de Astro.** Next.js, Gatsby y otros marcos de JavaScript no pueden admitir la hidratación parcial porque imaginan todo su sitio web/página como una sola aplicación de JavaScript.
## Concepto: Arquitectura de la isla
**La arquitectura de la isla** es la idea de utilizar la hidratación parcial para construir sitios web completos. La arquitectura de la isla es una alternativa a la idea popular de construir su sitio web en un paquete de JavaScript del lado del cliente que debe enviarse al usuario.
Para citar a Jason Miller, quien [acuñó la frase](https://jasonformat.com/islands-architecture/):
> En un modelo de "islas", la representación del servidor no es una optimización complementaria destinada a mejorar el SEO o la UX. En cambio, es una parte fundamental de cómo se envían las páginas al navegador. El HTML devuelto en respuesta a la navegación contiene una representación significativa e inmediatamente renderizable del contenido solicitado por el usuario.
Además de los obvios beneficios de rendimiento de enviar menos JavaScript al navegador, existen dos beneficios clave para la arquitectura de la isla:
- **Los componentes se cargan individualmente.** Un componente liviano (como una barra lateral) se cargará y renderizará rápidamente sin ser bloqueado por los componentes más pesados ​​de la página.
- **Los componentes se procesan de forma aislada.** Cada parte de la página es una unidad aislada y un problema de rendimiento en una unidad no afectará directamente a las demás.
![diagram](https://res.cloudinary.com/wedding-website/image/upload/v1596766231/islands-architecture-1.png)
## Hidrata los componentes interactivos
Astro procesa todos los componentes en el servidor **en el momento de la compilación**, a menos que se use [client:only](#mycomponent-clientonly-). Para hidratar componentes en el cliente **en tiempo de ejecución**, puede usar cualquiera de las siguientes directivas `client:*`. Una directiva es un atributo de componente (siempre con un `:`) que le dice a Astro cómo debe renderizarse tu componente.
```astro
---
// Ejemplo: hidratación de un componente React en el navegador.
import MyReactComponent from '../components/MyReactComponent.jsx';
---
<!-- "client:visible" significa que el componente no cargará ningún Javascript
del lado del cliente hasta que sea visible en el navegador del usuario. -->
<MyReactComponent client:visible />
```
### `<MyComponent client:load />`
Hidratar el componente al cargar la página.
### `<MyComponent client:idle />`
Hidrata el componente tan pronto como el hilo principal esté libre (usa [requestIdleCallback()] [mdn-ric]).
### `<MyComponent client:visible />`
Hidrata el componente tan pronto como el elemento entre en la ventana gráfica (usa [IntersectionObserver] [mdn-io]). Útil para el contenido que se encuentra más abajo en la página.
### `<MyComponent client:media={QUERY} />`
Hidrata el componente tan pronto como el navegador coincida con la consulta de medios dada (usa [matchMedia] [mdn-mm]). Útil para alternar la barra lateral u otros elementos que solo deberían mostrarse en dispositivos móviles o de escritorio.
### `<MyComponent client:only />`
Hidrata el componente en la carga de la página, similar a `client:load`. El componente se **omitirá** en el momento de la compilación, lo que resulta útil para los componentes que dependen por completo de las API del lado del cliente. Es mejor evitar esto a menos que sea absolutamente necesario; en la mayoría de los casos, es mejor representar el contenido del marcador de posición en el servidor y retrasar las llamadas a la API del navegador hasta que el componente se hidrate en el navegador.
Si se incluye más de un renderizador en Astro [config](/es/reference/configuration-reference), `client:only` necesita una pista para saber qué renderizador usar para el componente. Por ejemplo, `client:only="react"` aseguraría que el componente esté hidratado en el navegador con el renderizador React. Para los renderizadores personalizados no proporcionados por `@astrojs`, use el nombre completo del renderizador proporcionado en su configuración de Astro, es decir,` <client: only="my-custom-renderer" /> `.
## ¿Puedo hidratar los componentes de Astro?
Los [componentes de Astro](./astro-components)(archivos `.astro`) son componentes con plantillas de solo HTML sin ejecución del lado del cliente. Si intentas hidratar un componente Astro con un modificador `client:`, obtendrás un error.
Para hacer que su componente Astro sea interactivo, necesitará convertirlo al framework de su elección: React, Svelte, Vue, etc. Si no tienes preferencias, recomendamos React o Preact ya que son más similares a la sintaxis de Astro.
Alternativamente, puedes agregar una etiqueta `<script>` a tu plantilla HTML del componente de Astro y enviar JavaScript al navegador de esa manera. Aunque esto está bien para las cosas simples, recomendamos un framework de frontend para componentes interactivos más complejos.
```astro
---
// Ejemplo: uso de Astro con etiquetas de secuencia de comandos
---
<h1>No clickeado</h1>
<button>Haz click para cambiar el título</button>
<script>
document.querySelector("button").addEventListener("click",() => {
document.querySelector("h1").innerText = "clickeado"
})
</script>
```
[mdn-io]: https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API
[mdn-ric]: https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback
[mdn-mm]: https://developer.mozilla.org/en-US/docs/Web/API/Window/matchMedia

155
docs/src/pages/es/core-concepts/layouts.md Normal file
View file

@ -0,0 +1,155 @@
---
layout: ~/layouts/MainLayout.astro
title: Maquetas
lang: es
---
**Las maquetas** son un tipo especial de [Componente](/es/core-concept/astro-components) que te ayudan a compartir y reutilizar diseños de página comunes dentro de tu proyecto.
Las maquetas son como cualquier otro componente de Astro reutilizable. No hay una nueva sintaxis o API que aprender. Sin embargo, las maquetas de página reutilizables son un patrón tan común en el desarrollo web que creamos esta guía para ayudarte a usarlos.
## Uso
Las maquetas de Astro soportan propiedades, slots y todas las otras características de los componentes de Astro. Las maquetas son solo componentes normales, ¡después de todo!
A diferencia de otros componentes, las maquetas suelen contener la página completa `<html>`, `<head>` y `<body>` (a menudo denominado **cáscara de la página**).
Es un patrón común colocar todos los componentes de su diseño en un solo directorio `src/layouts`.
## Example
```astro
---
// src/layouts/BaseLayout.astro
const {title} = Astro.props;
---
<html>
<head>
<title>Ejemplo de maqueta: {title}</title>
</head>
<body>
<!-- Añade una barra de navegación a cada página. -->
<nav>
<a href="#">Inicio</a>
<a href="#">Artículos</a>
<a href="#">Contacto</a>
</nav>
<!-- ranura: el contenido de su página se inyectará aquí. -->
<slot />
</body>
</html>
```
📚 El elemento `<slot />` permite que los componentes de Astro definan dónde deben ir los elementos secundarios (pasados a la maqueta). Obtén más información sobre cómo funciona `<slot />` en nuestra [Guía de componentes de Astro](/es/core-concepts/astro-components).
Una vez que tengas tu primera maqueta, puedes usarla como lo harías con cualquier otro componente de tu página. Recuerda que tu maqueta contiene tu página `<html>`, `<head>` y `<body>`. Solo necesitas proporcionar el contenido de la página personalizada.
```astro
---
// src/pages/index.astro
import BaseLayout from '../layouts/BaseLayout.astro'
---
<BaseLayout title="Inicio">
<h1>Hola, ¡mundo!</h1>
<p>Este es el contenido de mi página. Estará anidado dentro de una maqueta.</p>
</BaseLayout>
```
## Maquetas anidadas
Puedes anidar diseños cuando desees crear tipos de página más específicos sin copiar y pegar. Es común en Astro tener un `BaseLayout` genérico y luego muchos más diseños específicos (`PostLayout`, `ProductLayout`, etc.) que se reutilizan y construyen sobre él.
```astro
---
// src/layouts/PostLayout.astro
import BaseLayout from '../layouts/BaseLayout.astro'
const {titulo, author} = Astro.props;
---
<!-- Este maqueta reutiliza BaseLayout (ver el ejemplo anterior): -->
<BaseLayout titulo={titulo}>
<!-- Añade contenido nuevo específico de publicación a cada página. -->
<div>Autor del artículo: {author}</div>
<!-- ranura: el contenido de su página se inyectará aquí. -->
<slot />
</BaseLayout>
```
## Composición de maquetas
A veces, necesitas un control más granular sobre tu página. Por ejemplo, es posible que desees agregar SEO o etiquetas `meta` sociales en algunas páginas, pero no en otras. Puedes implementar esto con un accesorio en su maqueta (`<BaseLayout addMeta={true}...`) pero en algún momento puede ser más fácil componer tus maquetas sin anidar.
En lugar de definir toda la página `<html>` como un diseño grande, puedes definir los contenidos de `head` y `body` como componentes separados más pequeños. Esto te permite componer varios diseños juntos de formas únicas en cada página.
```astro
---
// src/layouts/BaseHead.astro
const {title, description} = Astro.props;
---
<meta charset="UTF-8">
<title>{title}</title>
<meta name="description" content={description}>
<link rel="preconnect" href="https://fonts.gstatic.com">
<link href="https://fonts.googleapis.com/css2?family=Spectral:ital,wght@0,400;0,700;1,400;1,700&display=swap" rel="stylesheet">
```
Observa cómo esta maqueta no incluye la carcasa de su página, y solo incluye algunos elementos genéricos que deberían ir en tu `<head>`. Esto te permite combinar varios componentes de maqueta juntos con más control sobre la estructura general de la página.
```astro
---
// src/pages/index.astro
import BaseHead from '../layouts/BaseHead.astro';
import OpenGraphMeta from '../layouts/OpenGraphMeta.astro';
---
<html>
<head>
<!-- Ahora, tienes control total sobre el encabezado, por página. -->
<BaseHead title="Page Title" description="Page Description" />
<OpenGraphMeta />
<!-- Incluso puedes agregar elementos personalizados y únicos según sea necesario. -->
<link rel="alternate" type="application/rss+xml" href="/feed/posts.xml">
</head>
<body>
<!-- ... -->
</body>
</html>
```
La única desventaja de este enfoque es que deberás definir los elementos `<html>`, `<head>` y `<body>` en cada página tú mismo. Esto es necesario para construir la página porque los componentes de maqueta ya no contienen la carcasa completa de la página.
## Maquetas Markdown
Las maquetas son esenciales para los archivos Markdown. Los archivos de Markdown pueden declarar una maqueta en el texto preliminar del archivo. Cada archivo Markdown se procesará en HTML y luego se inyectará en la ubicación `<slot />` de la maqueta.
```markdown
---
title: Publicación del blog
layout: ../layouts/PostLayout.astro
---
Esta publicación de blog se **renderizará** dentro de la maqueta `<PostLayout />`.
```
Las páginas de Markdown siempre pasan una propiedad `content` a su maqueta, que es útil para obtener información sobre la página, el título, los metadatos, los encabezados de la tabla de contenido y más.
```astro
---
// src/layouts/PostLayout.astro
const { content } = Astro.props;
---
<html>
<head>
<title>{content.title}</title>
</head>
<body>
<h1>{content.title}</h1>
<h2>{content.description}</h2>
<img src={content.image} alt="">
<article>
<!-- slot: ¡El contenido de Markdown va aquí! -->
<slot />
</article>
</body>
</html>
```
📚 Aprende más sobre el soporte de Markdown de Astro en nuestra [guía de Markdown](/es/guides/markdown-content).

58
docs/src/pages/es/core-concepts/project-structure.md Normal file
View file

@ -0,0 +1,58 @@
---
layout: ~/layouts/MainLayout.astro
title: Estructura del proyecto
lang: es
---
Astro incluye un diseño de carpeta dogmático para tu proyecto. Cada proyecto de Astro debe incluir estos directorios y archivos:
- `src/*` - El código fuente de tu proyecto (componentes, páginas, etc.)
- `public/*` - Tus activos sin código (tipografías, iconos, etc.)
- `package.json` - Un manifiesto de proyecto.
La forma más sencilla de configurar tu nuevo proyecto es con `npm init astro`. Consulta nuestra [Guía de instalación](/quick-start) para obtener un tutorial sobre cómo configurar tu proyecto automáticamente (con `npm init astro`) o manualmente.
## Estructura del proyecto
```
├── src/
│ ├── components/
│ ├── layouts/
│ └── pages/
│ └── index.astro
├── public/
└── package.json
```
### `src/`
La carpeta src es donde vive la mayor parte del código fuente de tu proyecto. Esto incluye:
- [Components Astro](/es/core-concepts/astro-components)
- [Páginas](/es/core-concepts/astro-pages)
- [Maquetas](/es/core-concepts/layouts)
- [Componentes frontend JS](/es/core-concepts/component-hydration)
- [Estilado (CSS, Sass)](/es/guides/styling)
- [Marcado](/es/guides/markdown-content)
Astro tiene un control total sobre cómo estos archivos se procesan, optimizan y empaquetan en la construcción final de tu sitio. Algunos archivos (como los componentes de Astro) nunca llegan directamente al navegador y, en cambio, se procesan en HTML. Otros archivos (como CSS) se envían al navegador, pero es posible que se incluyan con otros archivos CSS dependiendo de cómo los utilice tu sitio.
### `src/components`
Los [components](/es/core-concepts/astro-components) son unidades reutilizables de Interfaz de Usuario (UI) para tus páginas HTML. Se recomienda (pero no es obligatorio) que coloques tus componentes en este directorio. La forma en que los organices dentro de este directorio depende de ti.
Tus componentes de UI que no son de Astro (React, Preact, Svelte, Vue, etc.) también pueden vivir en el directorio `src/components`. Astro procesará automáticamente todos los componentes en HTML a menos que hayas habilitado un componente de interfaz a través de la hidratación parcial.
### `src/layouts`
Las [maquetas](/es/core-concepts/layouts) son componentes reutilizables para diseños de páginas HTML. Se recomienda (pero no es obligatorio) que coloques tus componentes de maqueta en este directorio. La forma en que los organices dentro de este directorio depende de ti.
### `src/pages`
Las [páginas](/es/core-concepts/astro-pages) páginas contienen todas las páginas (compatibles con `.astro` y `.md`) de tu sitio web. Es **obligatorio** que coloques tus páginas en este directorio.
### `public/`
Para la mayoría de los usuarios, la mayoría de sus archivos vivirán dentro del directorio `src/` para que Astro pueda manejarlos y optimizarlos adecuadamente en su compilación final. Por el contrario, el directorio `public/` es el lugar para que cualquier archivo viva fuera del proceso de construcción de Astro.
Si colocas un archivo en la carpeta pública, Astro no lo procesará. En su lugar, se copiará intacto en la carpeta de compilación. Esto puede ser útil para activos como imágenes y fuentes, o cuando necesita incluir un archivo específico como `robots.txt` o `manifest.webmanifest`.

102
docs/src/pages/es/core-concepts/routing.md Normal file
View file

@ -0,0 +1,102 @@
---
layout: ~/layouts/MainLayout.astro
title: Enrutamiento
lang: es
---
Astro utiliza **enrutamiento basado en archivos** para generar sus URL de compilación en función del archivo de maqueta del directorio `src/pages` de tu proyecto. Cuando se agrega un archivo al directorio `src/pages` de tu proyecto, está automáticamente disponible como una ruta basada en su nombre de archivo.
## Rutas estáticas
Los Componentes de Astro (`.astro`) y Archivos Markdown (`.md`) en el directorio `src/pages` se convierten en páginas de tu sitio web. La ruta de cada página se decide en función de su nombre de archivo y ruta dentro del directorio `src/pages`. Esto significa que no hay una "configuración de enrutamiento" separada para mantener en un proyecto Astro.
```bash
# Example: Static routes
src/pages/index.astro -> mysite.com/
src/pages/about.astro -> mysite.com/about
src/pages/about/index.astro -> mysite.com/about
src/pages/about/me.astro -> mysite.com/about/me
src/pages/posts/1.md -> mysite.com/posts/1
```
## Rutas dinámicas
A veces, necesitas generar muchas URLs a partir de un solo componente de página. Astro utiliza el enrutamiento basado en archivos para admitir **parámetros de ruta dinámica** en el nombre de archivo, de modo que una página pueda coincidir con muchas rutas dinámicas según algún patrón.
Una cosa importante a tener en cuenta: Astro es un creador de sitios estáticos. No hay un servidor Astro para ejecutar en producción, lo que significa que cada página debe crearse con anticipación. Las páginas que usan rutas dinámicas deben exportar una función `getStaticPaths()` que le dirá a Astro exactamente qué páginas generar. Obtenga más información al ver la completa [Referencia de API](/es/reference/api-reference#getstaticpaths).
### Parámetros con nombre
Los parámetros dinámicos se codifican en el nombre del archivo usando la notación `[corchete]`:
- `pages/blog/[slug].astro` → `/blog/:slug` (`/blog/hello-world`, `/blog/post-2`, etc.)
- `pages/[username]/settings.astro` → (`/fred/settings`, `/drew/settings`, etc.)
- `pages/[lang]-[version]/info.astro` → (`/en-v1/info`, `/fr-v2/info`, etc.)
#### Ejemplo: parámetros con nombre
Considera la siguiente página `pages/post/[pid].astro`:
```jsx
---
// Example: src/pages/post/[pid].astro
const {pid} = Astro.request.params;
---
<p>Artículo: {pid}</p>
```
Cualquier ruta como `/post/1`, `/post/abc`, etc. se corresponderá con `pages/post/[pid].astro`. El parámetro de ruta coincidente se pasará al componente de la página en `Astro.request.params`.
Por ejemplo, la ruta `/post/abc` tendrás disponible el siguiente objeto `Astro.request.params`:
```json
{ "pid": "abc" }
```
Se pueden combinar varios segmentos de ruta dinámica para que funcionen de la misma manera. La página `pages/post/[pid]/[comment].astro` coincidirá con la ruta`/post/abc/a-comment` y su objeto `query` será:
```json
{ "pid": "abc", "comment": "a-comment" }
```
### Parámetros Rest
Si necesitas más flexibilidad en el enrutamiento de tu URL, puedes usar un parámetro Rest como un comodín universal. Haz esto agregando tres puntos (`...`) dentro de tus corchetes. Por ejemplo:
- `pages/post/[...slug].astro` → (`/post/a`, `/post/a/b`, `/post/a/b/c`, etc.)
Los parámetros coincidentes se enviarán en un parámetro de consulta (`slug` en el ejemplo) a la página. En el ejemplo anterior, la ruta `/post/a/b/c` tendrá el siguiente objeto `query`:
```json
{ "slug": "a/b/c" }
```
Puede utilizar nombres distintos a `slug`, como: `[...param]` o `[...name]`.
Los parámetros Rest son opcionales por defecto, por lo que `pages/post/[...slug].astro` también podría coincidir con `/post/`.
#### Ejemplo: Parametros Rest
Para un ejemplo del mundo real, puede implementar el visor de archivos de GitHub así:
```
/[org]/[repo]/tree/[branch]/[...file]
```
En este ejemplo, una solicitud de `/snowpackjs/astro/tree/main/docs/public/favicon.svg` daría como resultado que los siguientes parámetros estuvieran disponibles para la página:
```js
{
org: 'snowpackjs',
repo: 'astro',
branch: 'main',
file: 'docs/public/favicon.svg'
}
```
## Advertencias
- Las rutas estáticas sin parámetros de ruta tendrán prioridad sobre todas las demás rutas, y los parámetros de ruta con nombre sobre la captura de todos los parámetros de ruta. Echa un vistazo a los siguientes ejemplos:
- `pages/post/create.astro` - Coincidirá `/post/create`
- `pages/post/[pid].astro` - Coincidirá `/post/1`, `/post/abc`, etc. Pero no `/post/create`
- `pages/post/[...slug].astro` - Coincidirá `/post/1/2`, `/post/a/b/c`, etc. Pero no `/post/create`, `/post/abc`

46
docs/src/pages/es/guides/aliases.md Normal file
View file

@ -0,0 +1,46 @@
---
layout: ~/layouts/MainLayout.astro
title: Alias
lang: es
---
Un **alias** es un atajo útil para tus importaciones de JavaScript. Esta puede ser una gran opción si no te gustan las rutas de importación relativas largas con muchos segmentos repetidos `../`. Define un alias para importar cosas directamente desde algún directorio de proyecto de nivel superior, sin importar qué tan profundamente anidado esté ubicado un archivo.
Con un alias, puedes importar desde `"$components/SomeComponent.astro"` en lugar de `" ../../../../../components/SomeComponent.astro "`.
## Agregar un alias personalizado
Para agregar un alias personalizado a tu proyecto, busca el archivo `snowpack.config.mjs` de tu proyecto. Este archivo de configuración contiene las instrucciones y la configuración de la herramienta de compilación interna de Astro [Snowpack](https://www.snowpack.dev/reference/configuration). Si no ves un archivo `snowpack.config.mjs` en el nivel superior de su proyecto (dentro de la misma carpeta que tu `package.json`), puedes crear un archivo en blanco ahora.
Para agregar un nuevo alias de importación, define una nueva entrada `alias`:
```ts
// snowpack.config.mjs
export default {
alias: {
// Asignar importaciones de "$components/*" a "src/components/*"
$components: './src/components',
// Asignar importaciones de "$/*" a "src/*"
$: './src',
// ¡Defina el tuyo!
'$my-special-alias': './src/some/special/folder',
},
// ...
};
```
Una vez que hayas definido tu(s) alia(s) y hayas reiniciado Astro (si es necesario), puedes comenzar a importar desde el alias en cualquier lugar de tu proyecto:
```js
import MyComponent from '$components/MyComponent.astro';
import mySvgUrl from '$/logo.svg';
```
Puede leer más sobre la configuración de `alias` en [la documentación de Snowpack](https://www.snowpack.dev/reference/configuration#alias).
## Consejos y trucos
- Recomendamos comenzar todos los alias con el carácter especial `$`. No es necesario.
- Es común definir un alias `$` de nivel superior para tu directorio `src`. No es necesario.
- Para agregar soporte VSCode para tus alias, también necesitarás definir tus alias en un archivo `tsconfig.json` o `jsconfig.json` a través del valor de configuración `"paths"`. Esto habilitará Intellisense en VSCode y la mayoría de los demás editores de texto.
- ¡No necesitas usar un alias con Astro! Algunas personas prefieren menos magia en su código y no quieren molestarse con pasos adicionales para la compatibilidad con el editor de texto.

65
docs/src/pages/es/guides/data-fetching.md Normal file
View file

@ -0,0 +1,65 @@
---
layout: ~/layouts/MainLayout.astro
title: Obtención de datos
lang: es
---
Los componentes y las páginas de Astro pueden obtener datos remotos para ayudar a generar tus páginas. Astro proporciona dos herramientas diferentes a las páginas para ayudarte a hacer esto: **fetch()** y **await de nivel superior**.
## `fetch()`
Las páginas de Astro tienen acceso a la función global `fetch()` en su script de configuración. `fetch()` es una API de JavaScript nativa ([MDN <span class = "sr-only">- fetch</span>](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch)) que te permite realizar solicitudes HTTP para cosas como API y recursos.
Aunque los scripts de componentes de Astro se ejecutan dentro de Node.js (y no en el navegador), Astro proporciona esta API nativa para que pueda obtener datos en el momento de la creación de la página.
```astro
---
// Movies.astro
const response = await fetch('https://example.com/movies.json');
const data = await response.json();
// Recuerda: las secuencias de comandos del componente de Astro se registran en la CLI
console.log(data);
---
<!-- Envía el resultado a la página -->
<div>{JSON.stringify(data)}</div>
```
## await de nivel superior
`await` es otra característica nativa de JavaScript que te permite esperar la respuesta de alguna promesa asincrónica ([MDN <span class =" sr-only ">- await</span>](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await)). Astro admite "await" en el nivel superior de la secuencia de comandos de tu componente.
**Importante:** Estos aún no están disponibles dentro de los componentes de Astro que no son de página. En su lugar, carga todos tus datos dentro de tus páginas y luego pásalos a tus componentes como propiedades.
## Usando `fetch()` fuera de Componentes de Astro
Si quieres usar `fetch()` en un componente que no sea Astro, usa la biblioteca [`node-fetch`](https://github.com/node-fetch/node-fetch):
```tsx
// Movies.tsx
import fetch from 'node-fetch';
import type { FunctionalComponent } from 'preact';
import { h } from 'preact';
const data = fetch('https://example.com/movies.json').then((response) =>
response.json()
);
// Los componentes que se procesan en tiempo de compilación también se registran en la CLI.
// Si cargaste este componente con una directiva, se registraría en la consola del navegador.
console.log(data);
const Movies: FunctionalComponent = () => {
// Envía el resultado a la página
return <div>{JSON.stringify(data)}</div>;
};
export default Movies;
```
Si cargas un componente usando `node-fetch` [interactivamente](/es/core-concept/component-hydration), con `client:load`, `client:visible`, etc., necesitarás no usar `node-fetch` o cambiar a una librería [isomórfica](https://en.wikipedia.org/wiki/Isomorphic_JavaScript) que se ejecutará tanto en el momento de la compilación como en el cliente, como [`node-fetch` README.md](https://github.com/node-fetch/node-fetch#motivation) recomienda:
> En lugar de implementar XMLHttpRequest en Node.js para ejecutar [Fetch polyfill] específico del navegador (https://github.com/github/fetch), ¿por qué no pasar de http nativo a buscar API directamente? Por lo tanto, node-fetch, código mínimo para una API compatible con window.fetch en tiempo de ejecución de Node.js.
>
> Consulta [isomorphic-unfetch](https://www.npmjs.com/package/isomorphic-unfetch) de Jason Miller o [cross-fetch] de Leonardo Quixada (https://github.com/lquixada/cross-fetch) para uso isomórfico (exporta node-fetch para el lado del servidor, whatwg-fetch para el lado del cliente).
> Citado de https://github.com/node-fetch/node-fetch#motivation

7
docs/src/pages/es/guides/debugging.md Normal file
View file

@ -0,0 +1,7 @@
---
layout: ~/layouts/MainLayout.astro
title: Depuración
lang: es
---
Astro se ejecuta en el servidor y se registra directamente en su terminal, por lo que puede ser difícil depurar valores de Astro. El componente `<Debug>` incorporado de Astro puede ayudarte a inspeccionar los valores dentro de tus archivos en el lado del cliente. Lee más sobre el [componente de depuración incorporado](/es/reference/builtin-components#debug-).

353
docs/src/pages/es/guides/deploy.md Normal file
View file

@ -0,0 +1,353 @@
---
layout: ~/layouts/MainLayout.astro
title: Desplegar en la web
lang: es
---
Las siguientes guías se basan en algunos supuestos compartidos:
- Estás utilizando la ubicación de salida de compilación predeterminada (`dist/`). Esta ubicación [se puede cambiar usando la opción de configuración `dist`](/es/reference/configuration-reference).
- Estás usando npm. Puedes usar comandos equivalentes para ejecutar los scripts si estás usando Yarn u otros administradores de paquetes.
- Astro está instalado como una dependencia de desarrollo local en su proyecto, y has configurado los siguientes scripts npm:
```json
{
"scripts": {
"start": "astro dev",
"build": "astro build",
"preview": "astro preview"
}
}
```
## Construyendo la aplicación
Puedes ejecutar el comando `npm run build` para compilar la aplicación.
```bash
$ npm run build
```
Por defecto, la salida de la compilación se colocará en `dist/`. Puedes desplegar esta carpeta `dist/` en cualquiera de tus plataformas preferidas.
## Páginas de GitHub
> **Advertencia:** De forma predeterminada, las páginas de Github romperán el directorio `_astro/` de su sitio web desplegado. Para deshabilitar este comportamiento y solucionar este problema, asegúrate de usar el script `deploy.sh` de abajo o agrega manualmente un archivo `.nojekyll` vacío a tu directorio `public/`.
1. Establece el `buildOptions.site` correcto en `astro.config.mjs`.
2. Dentro de tu proyecto, crea `deploy.sh` con el siguiente contenido (sin comentar las líneas apropiadas) y ejecútalo para implementar:
```bash{13,20,23}
#!/usr/bin/env sh
# abortar en errores
set -e
# construir
npm run build
# navegar hasta el directorio de salida de la compilación
cd dist
# añade .nojekyll para omitir el comportamiento predeterminado de las páginas de GitHub
touch .nojekyll
# si estás implementando en un dominio personalizado
# echo 'www.example.com' > CNAME
git init
git add -A
git commit -m 'deploy'
# si estás desplegando en https://<USERNAME>.github.io
# git push -f git@github.com:<USERNAME>/<USERNAME>.github.io.git main
# si estás desplegando en https://<USERNAME>.github.io/<REPO>
# git push -f git@github.com:<USERNAME>/<REPO>.git main:gh-pages
cd -
```
> También puedes ejecutar el script anterior en tu configuración de CI para habilitar la implementación automática en cada envío.
### GitHub Actions
1. En el repositorio del proyecto astro, crea la rama `gh-pages`, luego ve a Configuración > Páginas y establece la rama `gh-pages` para las Páginas de GitHub y establece el directorio en `/` (raíz).
2. Establezca el `buildOptions.site` correcto en `astro.config.mjs`.
3. Crea el archivo `.github/workflows/main.yml` y agrega el yaml de abajo. Asegúrate de editar con tus propios datos.
4. En GitHub, ve a Configuración > Configuración de desarrollador > Tokens de acceso personal. Genere un nuevo token con permisos de repositorio.
5. En el repositorio del proyecto Astro (no \<SU NOMBRE DE USUARIO\>.github.io) ve a Configuración > Secretos y agregue tu nuevo token de acceso personal con el nombre `API_TOKEN_GITHUB`.
6. Cuando envíes cambios al repositorio del proyecto Astro, CI los desplegará en \<SU NOMBRE DE USUARIO \>.github.io por ti.
```yaml
# Flujo de trabajo para compilar y desplegar en tus páginas de GitHub del repositorio.
# Edita los detalles de tu proyecto aquí.
# ¡Recuerda agregar API_TOKEN_GITHUB en Configuración del repositorio > Secretos también!
env:
githubEmail: <YOUR GITHUB EMAIL ADDRESS>
deployToRepo: <NAME OF REPO TO DEPLOY TO (E.G. <YOUR USERNAME>.github.io)>
name: Github Pages Astro CI
on:
# Activa el flujo de trabajo en eventos de push y pull requests, pero solo para la rama principal
push:
branches: [main]
pull_request:
branches: [main]
# Permite ejecutar este flujo de trabajo manualmente desde la pestaña Acciones.
workflow_dispatch:
jobs:
deploy:
runs-on: ubuntu-latest
steps:
# Registra tu repositorio en $GITHUB_WORKSPACE, para que tu trabajo pueda acceder a él.
- uses: actions/checkout@v2
# Instalar dependencias con npm
- name: Install dependencies
run: npm ci
# Construye el proyecto y agrega el archivo .nojekyll para suprimir el comportamiento predeterminado
- name: Build
run: |
npm run build
touch ./dist/.nojekyll
# Hace push a tu repositorio de páginas
- name: Push to pages repo
uses: cpina/github-action-push-to-another-repository@main
env:
API_TOKEN_GITHUB: ${{ secrets.API_TOKEN_GITHUB }}
with:
source-directory: 'dist'
destination-github-username: ${{ github.actor }}
destination-repository-name: ${{ env.deployToRepo }}
user-email: ${{ env.githubEmail }}
commit-message: Deploy ORIGIN_COMMIT
target-branch: gh-pages
```
### Travis CI
1. Set the correct `buildOptions.site` in `astro.config.mjs`.
2. Create a file named `.travis.yml` in the root of your project.
3. Run `npm install` locally and commit the generated lockfile (`package-lock.json`).
4. Use the GitHub Pages deploy provider template, and follow the [Travis CI documentation](https://docs.travis-ci.com/user/deployment/pages/).
```yaml
language: node_js
node_js:
- lts/*
install:
- npm ci
script:
- npm run build
deploy:
provider: pages
skip_cleanup: true
local_dir: dist
# A token generated on GitHub allowing Travis to push code on you repository.
# Set in the Travis settings page of your repository, as a secure variable.
github_token: $GITHUB_TOKEN
keep_history: true
on:
branch: master
```
## GitLab Pages
1. Establece el `buildOptions.site` correcto en `astro.config.mjs`.
2. Establece `build` en `astro.config.mjs` a `public` y `public` en `astro.config.mjs` a una carpeta recién nombrada que contiene todo lo que se encuentra actualmente en `public`. El razonamiento es porque `public` es una segunda carpeta de origen en astro, por lo que si desea generar la salida a `public`, deberá extraer los activos públicos de una carpeta diferente.
3. Crea un archivo llamado `.gitlab-ci.yml` en la raíz de su proyecto con el contenido de abajo. Esto creará y desplegará su sitio cada vez que realice cambios en su contenido:
```yaml
image: node:10.22.0
pages:
cache:
paths:
- node_modules/
script:
- npm install
- npm run build
artifacts:
paths:
- public
only:
- master
```
## Netlify
**Nota:** Si está utilizando una [imagen de compilación](https://docs.netlify.com/configure-builds/get-started/#build-image-selection) antigua en Netlify, asegúrate de configurar tu versión de Node.js en un archivo [`.nvmrc`](https://github.com/nvm-sh/nvm#nvmrc) (ejemplo:` node v14.17.6`) o una variable de entorno `NODE_VERSION`. Este paso ya no es necesario de forma predeterminada.
Puedes configurar tu implementación de dos maneras, a través del sitio web de Netlify o con un archivo de proyecto local `netlify.toml`.
### `netlify.toml` file
Crea un nuevo archivo `netlify.toml` en el nivel superior del repositorio de su proyecto con la siguiente configuración:
```toml
[build]
command = "npm run build"
publish = "dist"
```
Empuja el nuevo archivo `netlify.toml` a tu repositorio de git alojado. Luego, configura un nuevo proyecto en [Netlify](https://netlify.com) para tu repositorio de git. Netlify leerá este archivo y configurará automáticamente su implementación.
### Interfaz de usuario del sitio web de Netlify
Puedes omitir el archivo `netlify.toml` e ir directamente a [Netlify](https://netlify.com) para configurar tu proyecto. Netlify ahora debería detectar los proyectos de Astro automáticamente y pre-rellenar la configuración por ti. Asegúrate de introducir la siguiente configuración antes de presionar el botón "Desplegar":
- **Comando de construcción:** `astro build` o `npm run build`
- **Publicar directorio:** `dist`
## Google Firebase
1. Asegúrate de tener [firebase-tools](https://www.npmjs.com/package/firebase-tools) instalado.
2. Crea `firebase.json` y `.firebaserc` en la raíz de tu proyecto con el siguiente contenido:
`firebase.json`:
```json
{
"hosting": {
"public": "dist",
"ignore": []
}
}
```
`.firebaserc`:
```js
{
"projects": {
"default": "<YOUR_FIREBASE_ID>"
}
}
```
3. Después de ejecutar `npm run build`, despliega usando el comando `firebase deploy`.
## Surge
1. Primero instala [surge](https://www.npmjs.com/package/surge), si aún no lo has hecho.
2. Ejecuta `npm run build`.
3. Despliega en Surge escribiendo `surge dist`.
También puedes implementar en un [dominio personalizado](http://surge.sh/help/adding-a-custom-domain) agregando `surge dist yourdomain.com`.
## Heroku
1. Instalar [Heroku CLI](https://devcenter.heroku.com/articles/heroku-cli).
2. Crea una cuenta en Heroku [registrándose](https://signup.heroku.com).
3. Ejecuta `heroku login` y completa tus credenciales de Heroku:
```bash
$ heroku login
```
4. Crea un archivo llamado `static.json` en la raíz de su proyecto con el siguiente contenido:
`static.json`:
```json
{
"root": "./dist"
}
```
Esta es la configuración de su sitio; leer más en [heroku-buildpack-static](https://github.com/heroku/heroku-buildpack-static).
5. Configura tu git remoto de Heroku:
```bash
# cambio de versión
$ git init
$ git add .
$ git commit -m "My site ready for deployment."
# crear una nueva aplicación con un nombre específico
$ heroku apps:create example
# establecer buildpack para sitios estáticos
$ heroku buildpacks:set https://github.com/heroku/heroku-buildpack-static.git
```
6. Implemente su sitio:
```bash
# publicar sitio
$ git push heroku master
# abre un navegador para ver la tablero de version de Heroku CI
$ heroku open
```
## Vercel
Para implementar tu proyecto Astro con [Vercel para Git](https://vercel.com/docs/git), asegúrate de que lo has enviado a un repositorio de Git.
Ve a https://vercel.com/import/git e importa el proyecto en Vercel utilizando tu elección de Git (GitHub, GitLab o BitBucket). Sigue el asistente para seleccionar la raíz del proyecto con el `package.json` del proyecto y anula el paso de compilación usando `npm run build` y el directorio de salida sea `./dist`.
Una vez que se has importado tu proyecto, todos los envíos posteriores a las ramas generarán vistas previas de desarrollos y todos los cambios realizados en la rama de producción (comúnmente "main") darán como resultado un despliegue de producción.
Una vez desplegado, obtendrás una URL para ver tu aplicación en vivo, como la siguiente: https://astro.vercel.app
## Aplicaciones web estáticas de Azure
Puedes implementar tu proyecto Astro con el servicio Microsoft Azure [Static Web Apps](https://aka.ms/staticwebapps). Necesitas:
- Una cuenta de Azure y una clave de suscripción. Aquí puedes crear una [cuenta gratuita de Azure](https://azure.microsoft.com/free).
- El código de tu aplicación enviado a [GitHub](https://github.com).
- La [Extensión SWA](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azurestaticwebapps) en [Visual Studio Code](https://code.visualstudio.com).
Instala la extensión en VS Code y navega hasta la raíz de tu aplicación. Abre la extensión Static Web Apps, inicia sesión en Azure y haz clic en el signo '+' para crear una nueva Static Web App. Se te pedirá que designes qué clave de suscripción utilizar.
Sigue el asistente iniciado por la extensión para darle un nombre a tu aplicación, elige un framework preestablecido y designa la raíz de la aplicación (generalmente `/`) y la ubicación del archivo construido `/dist`. El asistente se ejecutará y creará una acción de GitHub en su repositorio en una carpeta `.github`.
La acción funcionará para desplegar tu aplicación (observa su progreso en la pestaña Acciones de tu repositorio) y, cuando se complete con éxito, podrá ver su aplicación en la dirección proporcionada en la ventana de progreso de la extensión haciendo clic en el botón 'Explorar sitio web' que aparece cuando el la acción de GitHub se ha ejecutado.
## Cloudflare Pages
Puedes implementar tu proyecto Astro en [Cloudflare Pages](https://pages.cloudflare.com). Necesitas:
- Una cuenta de Cloudflare. Si aún no tienes una, puedes crear una cuenta gratuita de Cloudflare durante el proceso.
- El código de tu aplicación enviado a un repositorio de [GitHub](https://github.com).
Luego, configura un nuevo proyecto en Cloudflare Pages.
Utiliza la siguiente configuración de compilación:
- **Framework preestablecido**: `Ninguno` (Al momento de escribir este artículo, Astro no está en la lista).
- **Comando de compilación**: `astro build` o `npm run build`
- **Directorio de salida de compilación**: `dist`
- **Variables de entorno (avanzadas)**: agrega una variable de entorno con el **Nombre de variable** de `NODE_VERSION` y un **Valor** de una [Versión de node que es compatible con Astro](https://docs.astro.build/installation#prerequisites), ya que la versión predeterminada de Cloudflare Pages probablemente no funcione.
Entonces haz clic en el botón **Guardar y Desplegar**.
## Render
Puedes desplegar tu proyecto Astro en [Render](https://render.com/) siguiendo estos pasos:
1. Crea una [cuenta en render.com](https://dashboard.render.com/) e inicia sesión.
2. Haz clic en el botón **Nuevo +** de tu panel y selecciona **Sitio estático**.
3. Conecta tu repositorio de [GitHub](https://github.com/) o [GitLab](https://about.gitlab.com/) o, alternativamente, introduce la URL pública de un repositorio público.
4. Asigna un nombre a tu sitio web, selecciona la rama y especifique el comando de compilación y el directorio de publicación.
- **comando de compilación**: `npm run build`
- **directorio de publicación**: `dist`
5. Haz clic en el botón **Crear sitio estático**.
## Créditos
Esta guía se basó originalmente en la guía de implementación estática bien documentada de [Vite](https://vitejs.dev/).

140
docs/src/pages/es/guides/imports.md Normal file
View file

@ -0,0 +1,140 @@
---
layout: ~/layouts/MainLayout.astro
title: Importaciones soportadas
lang: es
---
Astro usa Snowpack como su sistema de construcción interno. Snowpack proporciona a Astro soporte integrado para los siguientes tipos de archivos, sin necesidad de configuración:
- JavaScript (`.js`, `.mjs`)
- TypeScript (`.ts`, `.tsx`)
- JSON (`.json`)
- JSX (`.jsx`, `.tsx`)
- CSS (`.css`)
- CSS Modules (`.module.css`)
- Imágenes y Activos (`.svg`, `.jpg`, `.png`, etc.)
- Componentes de Astro (`.astro`)
- Markdown (`.md`)
- WASM (`.wasm`)
Cualquier archivo en tu directorio `public/` se copia en la compilación final, sin ser tocado por Snowpack o Astro. Lo siguiente se aplica a los archivos en su directorio `src/`, del cual Astro es responsable en última instancia.
## JavaScript y ESM
Astro fue diseñado para la sintaxis nativa de ES Module (ESM) de JavaScript. ESM te permite definir importaciones y exportaciones explícitas que los navegadores y las herramientas de compilación pueden comprender y optimizar mejor. Si estás familiarizado con las palabras clave "import" y "export" en JavaScript, ¡entonces ya conoces ESM!
```js
// Ejemplo ESM - src/user.js
export function getUser() {
/* ... */
}
// src/index.js
import { getUser } from './user.js';
```
Todos los navegadores ahora son compatibles con ESM, por lo que Astro puede enviar este código directamente al navegador durante el desarrollo.
## TypeScript
Astro incluye soporte integrado para crear archivos TypeScript (`*.ts`) en JavaScript. Los componentes Astro también son compatibles con TypeScript en la sección de script preliminar.
Ten en cuenta que este soporte integrado es solo de compilación. De forma predeterminada, Astro no verifica el tipo de su código TypeScript.
<!-- Para integrar la verificación de tipos en su flujo de trabajo de desarrollo/compilación, agrega el plugin [@snowpack/plugin-typescript](https://www.npmjs.com/package/@snowpack/plugin-typescript). -->
## JSX
Astro incluye soporte integrado para construir archivos JSX (`*.jsx` & `*.tsx`) a JavaScript.
Si estás usando Preact, Astro detectará la importación de Preact y cambiará para usar la función estilo Preact de JSX `h()`. Todo esto se hace automáticamente.
**Nota: Astro no admite JSX en archivos `.js`/`.ts`.**
## JSON
```js
// Carga el objeto JSON a través de la exportación predeterminada
import json from './data.json';
```
Astro admite la importación de archivos JSON directamente en tu aplicación. Los archivos importados devuelven el objeto JSON completo en la importación predeterminada.
## CSS
```js
// Load and inject 'style.css' onto the page
import './style.css';
```
Astro admite la importación de archivos CSS directamente a tu aplicación. Los estilos importados no exponen exportaciones, pero la importación de uno agregará automáticamente esos estilos a la página. Esto funciona para todos los archivos CSS de forma predeterminada y puede admitir lenguajes de compilación a CSS como Sass y Less a través de complementos.
Si prefieres no escribir CSS, Astro también es compatible con todas las librerías populares de CSS en JS (por ejemplo, styled-components) para el estilo.
## CSS Modules
```js
// 1. Convierte los nombres de clase './style.module.css' en valores únicos con ámbito.
// 2. Devuelve un objeto que asigna los nombres de clase originales a su valor de ámbito final.
import styles from './style.module.css';
// This example uses JSX, but you can use CSS Modules with any framework.
return <div className={styles.error}>Your Error Message</div>;
```
Astro admite módulos CSS utilizando la convención de nomenclatura `[nombre].module.css`. Al igual que con cualquier archivo CSS, la importación de uno aplicará automáticamente ese CSS a la página. Sin embargo, los módulos CSS exportan un objeto "estilos" predeterminado especial que asigna sus nombres de clase originales a identificadores únicos.
Los módulos CSS te ayudan a hacer cumplir el alcance y el aislamiento de los componentes en la interfaz con nombres de clase generados de forma única para sus hojas de estilo.
## Otros activos
```jsx
import imgReference from './image.png'; // img === '/src/image.png'
import svgReference from './image.svg'; // svg === '/src/image.svg'
import txtReference from './words.txt'; // txt === '/src/words.txt'
// Este ejemplo usa JSX, pero puedes usar referencias de importación con cualquier marco.
<img src={imgReference} />;
```
Todos los demás activos que no se mencionan explícitamente anteriormente se pueden importar a través de "import" de ESM y devolverán una referencia de URL al activo final creado. Esto puede ser útil para hacer referencia a activos que no son de JS por URL, como crear un elemento de imagen con un atributo `src` que apunte a esa imagen.
## WASM
```js
// Carga e inicializa el archivo WASM solicitado
const wasm = await WebAssembly.instantiateStreaming(fetch('/example.wasm'));
```
Astro admite la carga de archivos WASM directamente en tu aplicación utilizando la API [`WebAssembly`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly) del navegador. Lee nuestra [guía WASM](/es/guides/wasm) para obtener más información.
## Paquetes npm
```js
// Devuelve los paquetes npm React & React-DOM
import React from 'react';
import ReactDOM from 'react-dom';
```
Astro te permite importar paquetes npm directamente en el navegador. Incluso si un paquete se publicó utilizando un formato heredado, Astro convertirá el paquete a ESM antes de servirlo en el navegador.
Cuando inicies tu servidor de desarrollo o ejecutes una nueva compilación, es posible que vea un mensaje de que Snowpack está "instalando dependencias". Esto significa que Snowpack está convirtiendo sus dependencias para que se ejecuten en el navegador. Esto debe ejecutarse solo una vez, o hasta que cambie su árbol de dependencias agregando o quitando dependencias.
## Incluidos en Node
Recomendamos a los usuarios de Astro que eviten los archivos incorporados en Node.js (`fs`,` path`, etc.) siempre que sea posible. Astro pretende ser compatible con múltiples tiempos de ejecución de JavaScript en el futuro. Esto incluye [Deno](https://deno.land/) y [Cloudflare Workers](https://workers.cloudflare.com/) que no son compatibles con los módulos integrados de Node como `fs`.
Nuestro objetivo es proporcionar alternativas de Astro a las incorporaciones comunes de Node.js. Sin embargo, hoy en día no existen tales alternativas. Entonces, si _realmente_ necesitas usar estos módulos incorporados, no queremos detenerte. Astro soporta incorporaciones de Node.js usando el prefijo `node:` más nuevo de Node. Si deseas leer un archivo, por ejemplo, puedes hacerlo así:
```jsx
---
// Ejemplo: importar el "fs/promises" incorporado desde Node.js
import fs from 'node:fs/promises';
const url = new URL('../../package.json', import.meta.url);
const json = await fs.readFile(url, 'utf-8');
const data = JSON.parse(json);
---
<span>Versión: {data.version}</span>
```

13
docs/src/pages/es/guides/markdown-content.astro Normal file
View file

@ -0,0 +1,13 @@
---
import { Markdown } from 'astro/components';
import MainLayout from '~/layouts/MainLayout.astro';
const [content] = Astro.fetchContent('~/pages/guides/markdown-content.md');
---
<MainLayout content="{content}">
<Markdown>
> Esta página todavía no está disponible en Español. Se muestra la versión en inglés.
</Markdown>
{content.astro.html}
</MainLayout>

13
docs/src/pages/es/guides/pagination.astro Normal file
View file

@ -0,0 +1,13 @@
---
import { Markdown } from 'astro/components';
import MainLayout from '~/layouts/MainLayout.astro';
const [content] = Astro.fetchContent('~/pages/guides/pagination.md');
---
<MainLayout content="{content}">
<Markdown>
> Esta página todavía no está disponible en Español. Se muestra la versión en inglés.
</Markdown>
{content.astro.html}
</MainLayout>

13
docs/src/pages/es/guides/publish-to-npm.astro Normal file
View file

@ -0,0 +1,13 @@
---
import { Markdown } from 'astro/components';
import MainLayout from '~/layouts/MainLayout.astro';
const [content] = Astro.fetchContent('~/pages/guides/publish-to-npm.md');
---
<MainLayout content="{content}">
<Markdown>
> Esta página todavía no está disponible en Español. Se muestra la versión en inglés.
</Markdown>
{content.astro.html}
</MainLayout>

43
docs/src/pages/es/guides/rss.md Normal file
View file

@ -0,0 +1,43 @@
---
layout: ~/layouts/MainLayout.astro
title: RSS
lang: es
---
Astro admite la generación de feeds RSS rápida y automática para blogs y otros sitios web de contenido.
Puedes crear una fuente RSS desde cualquier página de Astro que utilice una función `getStaticPaths()` para el enrutamiento. Solo las rutas dinámicas pueden usar `getStaticPaths()` hoy (ver [Enrutamiento](/es/core-concepts/routing)).
> Esperamos que esta función esté disponible para todas las demás páginas antes de la v1.0. Como solución alternativa, puedes convertir una ruta estática en una ruta dinámica que solo genera una página. Consulta [Enrutamiento](/es/core-concepts/routing) para obtener más información sobre las rutas dinámicas.
Crea una fuente RSS llamando a la función `rss()` que se pasa como argumento a `getStaticPaths ()`. Esto creará un archivo `rss.xml` en tu compilación final basado en los datos que proporciones usando el array `items`.
```js
// Example: /src/pages/posts/[...page].astro
// Coloca esta función dentro de la secuencia de comandos del componente de Astro.
export async function getStaticPaths({rss}) {
const allPosts = Astro.fetchContent('../post/*.md');
const sortedPosts = allPosts.sort((a, b) => new Date(b.date) - new Date(a.date));
// Genera un feed RSS de esta colección
rss({
// El título, la descripción y los metadatos personalizados de la fuente RSS.
title: 'Don’s Blog',
description: 'An example blog on Astro',
customData: `<language>en-us</language>`,
// The list of items for your RSS feed, sorted.
items: sortedPosts.map(item => ({
title: item.title,
description: item.description,
link: item.url,
pubDate: item.date,
})),
// Opcional: personaliza dónde se escribe el archivo.
// De lo contrario, el valor predeterminado es "/rss.xml".
dest: "/my/custom/feed.xml",
});
// Devuelve tus rutas
return [...];
}
```
Nota: Las fuentes RSS **no** se crearán durante el desarrollo. Actualmente, las fuentes RSS solo se generan durante la compilación final.

13
docs/src/pages/es/guides/styling.astro Normal file
View file

@ -0,0 +1,13 @@
---
import { Markdown } from 'astro/components';
import MainLayout from '~/layouts/MainLayout.astro';
const [content] = Astro.fetchContent('~/pages/guides/styling.md');
---
<MainLayout content="{content}">
<Markdown>
> Esta página todavía no está disponible en Español. Se muestra la versión en inglés.
</Markdown>
{content.astro.html}
</MainLayout>

6
docs/src/pages/es/installation.md
View file

@ -49,7 +49,7 @@ Después de que `create-astro` cree la estructura básica de tu proyecto, recuer
npm install
```
Ahora puedes [Iniciar](#start-astro) tu proyecto de Astro. Una vez, que hayas completado tu proyecto, puedes [Compilar](#build-astro) tu proyecto. Astro va a empaquetar tu aplicación y después generará los archivos estáticos, que estarán listos para ser [Desplegados](/guides/deploy) en tu proveedor de hosting favorito.
Ahora puedes [Iniciar](#start-astro) tu proyecto de Astro. Una vez, que hayas completado tu proyecto, puedes [Compilar](#build-astro) tu proyecto. Astro va a empaquetar tu aplicación y después generará los archivos estáticos, que estarán listos para ser [Desplegados](/es/guides/deploy) en tu proveedor de hosting favorito.
## Manual de Instalación
@ -94,7 +94,7 @@ Ahora, puedes reemplazar la sección de "scripts" del archivo `package.json` que
}
```
El comando [`dev`](#start-astro) inicia el servidor de desarrollo de Astro en `http://localhost:3000`. Una vez que tu proyecto esté listo, el comando [`build`](#build-astro) genera tu proyecto en el directorio `dist/`. [Lee más sobre cómo desplegar Astro en la guía de despliegue](/guides/deploy).
El comando [`dev`](#start-astro) inicia el servidor de desarrollo de Astro en `http://localhost:3000`. Una vez que tu proyecto esté listo, el comando [`build`](#build-astro) genera tu proyecto en el directorio `dist/`. [Lee más sobre cómo desplegar Astro en la guía de despliegue](/es/guides/deploy).
### Crear tu primera página
@ -166,6 +166,6 @@ Te recomendamos fervientemente que te familiarices con la forma en que Astro fun
📚 Aprende más sobre la estructura de proyectos de Astro, en nuestra [guía de estructura de proyecto](/es/core-concepts/project-structure).
📚 Aprende más sobre la sintaxis de los componentes de Astro, en nuestra [guía de componentes de Astro](/core-concepts/astro-components).
📚 Aprende más sobre la sintaxis de los componentes de Astro, en nuestra [guía de componentes de Astro](/es/core-concepts/astro-components).
📚 Aprende más sobre la rutas basada en archivos de Astro, en nuestra [guía de rutas](core-concepts/astro-pages).

6
docs/src/pages/es/quick-start.md
View file

@ -58,7 +58,7 @@ Los sitios de Astro son estáticos, por lo que puedes desplegarlos en tu servici
- [Google Firebase](https://firebase.google.com/)
- [Netlify](https://www.netlify.com/)
- [Vercel](https://vercel.com/)
- [Lee más acerca del despliegue con nuestra guía de despliegue de Astro.](/guides/deploy)
- [Lee más acerca del despliegue con nuestra guía de despliegue de Astro.](/es/guides/deploy)
## Próximos Pasos
@ -66,8 +66,8 @@ Los sitios de Astro son estáticos, por lo que puedes desplegarlos en tu servici
Te recomendamos que te tomes tu tiempo para familiarizarte con la forma en la que Astro. Lo puedes hacer al explorar con mayor profundidad nuestra documentación. Te sugerimos que consideres lo siguiente.
📚 Aprende más sobre la estructura de proyectos de Astro, en nuestra [guía de estructura de proyecto](/core-concepts/project-structure).
📚 Aprende más sobre la estructura de proyectos de Astro, en nuestra [guía de estructura de proyecto](/es/core-concepts/project-structure).
📚 Aprende más sobre la sintaxis de los componentes de Astro, en nuestra [guía de componentes de Astro](/core-concepts/astro-components).
📚 Aprende más sobre la sintaxis de los componentes de Astro, en nuestra [guía de componentes de Astro](/es/core-concepts/astro-components).
📚 Aprende más sobre la rutas basada en archivos de Astro, en nuestra [guía de rutas](core-concepts/astro-pages).

294
docs/src/pages/es/reference/api-reference.md Normal file
View file

@ -0,0 +1,294 @@
---
layout: ~/layouts/MainLayout.astro
title: Referencia de API
lang: es
---
## `Astro` global
La variable `Astro` global está disponible en todos los contextos en los archivos `.astro`. Tiene las siguientes funciones:
### `Astro.fetchContent()`
`Astro.fetchContent()` is a way to load local `*.md` files into your static site setup.
```jsx
// ./src/components/my-component.astro
---
const data = Astro.fetchContent('../pages/post/*.md'); // returns an array of posts that live at ./src/pages/post/*.md
---
<div>
{data.slice(0, 3).map((post) => (
<article>
<h1>{post.title}</h1>
<p>{post.description}</p>
<a href={post.url}>Read more</a>
</article>
))}
</div>
```
`.fetchContent()` only takes one parameter: a relative URL glob of which local files you'd like to import. Currently only `*.md` files are supported. It's synchronous, and returns an array of items of type:
```js
{
/** frontmatter from the post.. example frontmatter:
title: '',
tag: '',
date: '',
image: '',
author: '',
description: '',
**/
astro: {
headers: [], // an array of h1...h6 elements in the markdown file
source: '', // raw source of the markdown file
html: '' // rendered HTML of the markdown file
},
url: '' // the rendered path
}[]
```
### `Astro.request`
`Astro.request` returns an object with the following properties:
| Name | Type | Description |
| :------------- | :---- | :---------------------------------------------- |
| `url` | `URL` | The URL of the request being rendered. |
| `canonicalURL` | `URL` | [Canonical URL][canonical] of the current page. |
### `Astro.resolve()`
`Astro.resolve()` helps with creating URLs relative to the current Astro file, allowing you to reference files within your `src/` folder.
Astro _does not_ resolve relative links within HTML, such as images:
```html
<img src="../images/penguin.png" />
```
The above will be sent to the browser as-is and the browser will resolve it relative to the current **page**. If you want it to be resolved relative to the .astro file you are working in, use `Astro.resolve`:
```astro
<img src={Astro.resolve('../images/penguin.png')} />
```
### `Astro.site`
`Astro.site` returns a `URL` made from `buildOptions.site` in your Astro config. If undefined, this will return a URL generated from `localhost`.
```astro
---
const path = Astro.site.pathname;
---
<h1>Welcome to {path}</h1>
```
### `Astro.slots`
`Astro.slots` returns an object with any slotted regions passed into the current Astro file.
```js
const {
heading as headingSlot, // true or undefined, based on whether `<* slot="heading">` was used.
default as defaultSlot, // true or undefined, based on whether `<* slot>` or `<* default>` was used.
} = Astro.slots;
```
## `getStaticPaths()`
If a page uses dynamic params in the filename, that component will need to export a `getStaticPaths()` function.
This function is required because Astro is a static site builder. That means that your entire site is built ahead of time. If Astro doesn't know to generate a page at build time, your users won't see it when they visit your site.
```jsx
---
export async function getStaticPaths() {
return [
{ params: { /* required */ }, props: { /* optional */ },
{ params: { ... } },
{ params: { ... } },
// ...
];
}
---
<!-- Your HTML template here. -->
```
The `getStaticPaths()` function should return an array of objects to determine which paths will be pre-rendered by Astro.
⚠️ The `getStaticPaths()` function executes in its own isolated scope once, before any page loads. Therefore you can't reference anything from its parent scope, other than file imports. The compiler will warn if you break this requirement.
### `params`
The `params` key of every returned object tells Astro what routes to build. The returned params must map back to the dynamic parameters and rest parameters defined in your component filepath.
`params` are encoded into the URL, so only strings are supported as values. The value for each `params` object must match the parameters used in the page name.
For example, suppose that you have a page at `src/pages/posts/[id].astro`. If you export `getStaticPaths` from this page and return the following for paths:
```js
---
export async function getStaticPaths() {
return [
{ params: { id: '1' } },
{ params: { id: '2' } }
];
}
const {id} = Astro.request.params;
---
<body><h1>{id}</h1></body>
```
Then Astro will statically generate `posts/1` and `posts/2` at build time.
### Data Passing with `props`
To pass additional data to each generated page, you can also set a `props` value on every returned path object. Unlike `params`, `props` are not encoded into the URL and so aren't limited to only strings.
For example, suppose that you generate pages based off of data fetched from a remote API. You can pass the full data object to the page component inside of `getStaticPaths`:
```js
---
export async function getStaticPaths() {
const data = await fetch('...').then(response => response.json());
return data.map((post) => {
return {
params: { id: post.id },
props: { post } };
});
}
const {id} = Astro.request.params;
const {post} = Astro.props;
---
<body><h1>{id}: {post.name}</h1></body>
```
Then Astro will statically generate `posts/1` and `posts/2` at build time using the page component in `pages/posts/[id].astro`. The page can reference this data using `Astro.props`:
### `paginate()`
Pagination is a common use-case for websites that Astro natively supports via the `paginate()` function. `paginate()` will automatically generate the array to return from `getStaticPaths()` that creates one URL for every page of the paginated collection. The page number will be passed as a param, and the page data will be passed as a `page` prop.
```js
export async function getStaticPaths({ paginate }) {
// Load your data with fetch(), Astro.fetchContent(), etc.
const response = await fetch(`https://pokeapi.co/api/v2/pokemon?limit=150`);
const result = await response.json();
const allPokemon = result.results;
// Return a paginated collection of paths for all posts
return paginate(allPokemon, { pageSize: 10 });
}
// If set up correctly, The page prop now has everything that
// you need to render a single page (see next section).
const { page } = Astro.props;
```
`paginate()` assumes a file name of `[page].astro` or `[...page].astro`. The `page` param becomes the page number in your URL:
- `/posts/[page].astro` would generate the URLs `/posts/1`, `/posts/2`, `/posts/3`, etc.
- `/posts/[...page].astro` would generate the URLs `/posts`, `/posts/2`, `/posts/3`, etc.
#### The pagination `page` prop
Pagination will pass a `page` prop to every rendered page that represents a single page of data in the paginated collection. This includes the data that you've paginated (`page.data`) as well as metadata for the page (`page.url`, `page.start`, `page.end`, `page.total`, etc). This metadata is useful for things like a "Next Page" button or a "Showing 1-10 of 100" message.
| Name | Type | Description |
| :----------------- | :-------------------: | :-------------------------------------------------------------------------------------------------------------------------------- |
| `page.data` | `Array` | Array of data returned from `data()` for the current page. |
| `page.start` | `number` | Index of first item on current page, starting at `0` (e.g. if `pageSize: 25`, this would be `0` on page 1, `25` on page 2, etc.). |
| `page.end` | `number` | Index of last item on current page. |
| `page.size` | `number` | How many items per-page. |
| `page.total` | `number` | The total number of items across all pages. |
| `page.currentPage` | `number` | The current page number, starting with `1`. |
| `page.lastPage` | `number` | The total number of pages. |
| `page.url.current` | `string` | Get the URL of the current page (useful for canonical URLs) |
| `page.url.prev` | `string \| undefined` | Get the URL of the previous page (will be `undefined` if on page 1). |
| `page.url.next` | `string \| undefined` | Get the URL of the next page (will be `undefined` if no more pages). |
### `rss()`
RSS feeds are another common use-case that Astro supports natively. Call the `rss()` function to generate an `/rss.xml` feed for your project using the same data that you loaded for this page. This file location can be customized (see below).
```js
// Example: /src/pages/posts/[...page].astro
// Place this function inside your Astro component script.
export async function getStaticPaths({rss}) {
const allPosts = Astro.fetchContent('../post/*.md');
const sortedPosts = allPosts.sort((a, b) => new Date(b.date) - new Date(a.date));
// Generate an RSS feed from this collection
rss({
// The RSS Feed title, description, and custom metadata.
title: 'Don’s Blog',
description: 'An example blog on Astro',
customData: `<language>en-us</language>`,
// The list of items for your RSS feed, sorted.
items: sortedPosts.map(item => ({
title: item.title,
description: item.description,
link: item.url,
pubDate: item.date,
})),
// Optional: Customize where the file is written to.
// Defaults to "/rss.xml"
dest: "/my/custom/feed.xml",
});
// Return a paginated collection of paths for all posts
return [...];
}
```
```ts
// The full type definition for the rss() function argument:
interface RSSArgument {
/** (required) Title of the RSS Feed */
title: string;
/** (required) Description of the RSS Feed */
description: string;
/** Specify arbitrary metadata on opening <xml> tag */
xmlns?: Record<string, string>;
/** Specify custom data in opening of file */
customData?: string;
/**
* Specify where the RSS xml file should be written.
* Relative to final build directory. Example: '/foo/bar.xml'
* Defaults to '/rss.xml'.
*/
dest?: string;
/** Return data about each item */
items: {
/** (required) Title of item */
title: string;
/** (required) Link to item */
link: string;
/** Publication date of item */
pubDate?: Date;
/** Item description */
description?: string;
/** Append some other XML-valid data to this item */
customData?: string;
}[];
}
```
## `import.meta`
> In this section we use `[dot]` to mean `.`. This is because of a bug in our build engine that is rewriting `import[dot]meta[dot]env` if we use `.` instead of `[dot]`.
All ESM modules include a `import.meta` property. Astro adds `import[dot]meta[dot]env` through [Snowpack](https://www.snowpack.dev/).
**`import[dot]meta[dot]env[dot]SSR`** can be used to know when rendering on the server. Sometimes you might want different logic, for example a component that should only be rendered in the client:
```jsx
import { h } from 'preact';
export default function () {
// Note: rewrite "[dot]" to "." for this to to work in your project.
return import[dot]meta[dot]env[dot]SSR ? <div class="spinner"></div> : <FancyComponent />;
}
```
[canonical]: https://en.wikipedia.org/wiki/Canonical_link_element

71
docs/src/pages/es/reference/builtin-components.md Normal file
View file

@ -0,0 +1,71 @@
---
layout: ~/layouts/MainLayout.astro
title: Componentes integrados
lang: es
---
Astro incluye varios componentes integrados para que los utilices en tus proyectos. Todos los componentes integrados están disponibles a través de `import {} from 'astro/components';`.
## `<Code />`
```astro
---
import { Code } from 'astro/components';
---
<!-- Resaltado de sintaxis de código JavaScript. -->
<Code code={`const foo = 'bar';`} lang="js" />
<!-- Opcional: personaliza tu tema. -->
<Code code={`const foo = 'bar';`} lang="js" theme="dark-plus" />
<!-- Opcional: habilite el ajuste de palabras. -->
<Code code={`const foo = 'bar';`} lang="js" wrap />
```
Este componente proporciona resaltado de sintaxis para bloques de código en el momento de la compilación (no se incluye JavaScript del lado del cliente). El componente funciona internamente con shiki y es compatible con todos los [temas](https://github.com/shikijs/shiki/blob/main/docs/themes.md) populares y [lenguajes](https://github.com /shikijs/shiki/blob/main/docs/languages.md).
También puede utilizar el componente `<Prism />` para el resaltado de sintaxis impulsado por la librería de resaltado de sintaxis [Prism](https://prismjs.com/). Esta es la librería que el Markdown de Astro usa por defecto. Sin embargo, cambiaremos todo el uso a `<Code>` a medida que avanzamos hacia nuestra versión v1.0.
## `<Markdown />`
```astro
---
import { Markdown } from 'astro/components';
---
<Markdown>
# ¡La sintaxis de Markdown ahora es compatible! **¡Hurra!**
</Markdown>
```
Mira nuestra [Guía de Markdown](/es/guides/markdown-content) para más información.
<!-- TODO: We should move some of the specific component info here. -->
## `<Prism />`
```astro
---
import { Prism } from 'astro/components';
---
<Prism lang="js" code={`const foo = 'bar';`} />
```
Este componente proporciona resaltado de sintaxis específico del lenguaje para bloques de código. Dado que esto nunca cambia en el cliente, tiene sentido usar un componente Astro (es igualmente razonable usar un componente de framework para este tipo de cosas; ¡Astro es solo servidor por defecto para todos los frameworks!).
Consulta la [lista de lenguajes soportados por Prism](https://prismjs.com/#supported-languages) donde puedes encontrar undonde puede encontrar el alias correspondiente de un lenguaje. ¡Y también puedes mostrar tus bloques de código Astro con `lang="astro"`!
## `<Debug />`
```astro
---
import Debug from 'astro/debug';
const serverObject = {
a: 0,
b: "string",
c: {
nested: "object"
}
}
---
<Debug {serverObject} />
```
Este componente proporciona una forma de inspeccionar los valores en el lado del cliente, sin JavaScript.

67
docs/src/pages/es/reference/cli-reference.md Normal file
View file

@ -0,0 +1,67 @@
---
layout: ~/layouts/MainLayout.astro
title: Referencia de CLI
lang: es
---
## Comandos
### `astro dev`
Ejecuta el servidor de desarrollo de Astro. Esto inicia un servidor HTTP que responde a las solicitudes de páginas almacenadas en `src/pages` (o la carpeta que se especifique en tu [configuración](/es/reference/configuration-reference)).
**Flags**
#### `--port`
Especifica el puerto en el que se ejecutará. El valor predeterminado es `3000`.
### `astro build`
Crea tu sitio para producción.
### `astro preview`
Inicia un servidor de archivos estático local para servir tu directorio `dist/` construido. Útil para obtener una vista previa de tu compilación estática localmente, antes de desplegarla.
Este comando está destinado únicamente a pruebas locales y no está diseñado para ejecutarse en producción. Para obtener ayuda con el alojamiento de producción, consulta nuestra guía sobre [DEspliegue de un sitio web Astro](/es/guides/deploy).
## Global Flags
### `--config path`
Especifica la ruta al archivo de configuración. El valor predeterminado es `astro.config.mjs`. Use esto si usas un nombre diferente para su archivo de configuración o tienes tu archivo de configuración en otra carpeta.
```shell
astro --config config/astro.config.mjs dev
```
### `--project-root path`
Especifica la ruta a la raíz del proyecto. Si no se especifica, se supone que el directorio de trabajo actual es la raíz.
La raíz se utiliza para encontrar el archivo de configuración de Astro.
```shell
astro --project-root examples/snowpack dev
```
### `--reload`
Borra la caché (las dependencias se crean dentro de las aplicaciones Astro).
### `--verbose`
Habilita el registro detallado, que es útil al depurar un problema.
### `--silent`
Habilita el registro silencioso, que es útil cuando no deseas ver los registros de Astro.
### `--version`
Imprima el número de versión de Astro y sale.
### `--help`
Imprime el mensaje de ayuda y sale.

29
docs/src/pages/es/reference/configuration-reference.md Normal file
View file

@ -0,0 +1,29 @@
---
layout: ~/layouts/MainLayout.astro
title: Referencia de Configuración
lang: es
---
Para configurar Astro, agrega un archivo `astro.config.mjs` en la raíz de tu proyecto. Todos los ajustes son opcionales.
Puedes ver la API de configuración completa (incluida la información sobre la configuración predeterminada) en [GitHub](https://github.com/snowpackjs/astro/blob/latest/packages/astro/src/@types/config.ts).
```js
// Example: astro.config.mjs
// @type-check habilitado!
// VSCode y otros editores de texto habilitados para TypeScript proporcionarán autocompletado,
// información sobre herramientas útiles y advertencias si el objeto exportado no es válido.
// Puede desactivar esto eliminando los comentarios "@ts-check" y `@type` a continuación.
// @ts-check
export default /** @type {import('astro').AstroUserConfig} */ (
{
// ...
}
);
```
## Configuración Snowpack
Astro funciona internamente con Snowpack. Puedes configurar Snowpack directamente creando un archivo `snowpack.config.mjs`. Consulta [snowpack.dev](https://www.snowpack.dev/reference/configuration) para obtener la documentación completa sobre este archivo.

13
docs/src/pages/es/reference/renderer-reference.astro Normal file
View file

@ -0,0 +1,13 @@
---
import { Markdown } from 'astro/components';
import MainLayout from '~/layouts/MainLayout.astro';
const [content] = Astro.fetchContent('~/pages/reference/renderer-reference.md');
---
<MainLayout content="{content}">
<Markdown>
> Esta página todavía no está disponible en Español. Se muestra la versión en inglés.
</Markdown>
{content.astro.html}
</MainLayout>