German translation - docs (#1830)
* New translation of getting-started.md Rework of the basic translation, resolving a bunch of issues and correcting misconceptions in terminologies. * Spelling correction * Omitting redundant paragraph. Minor corrections. * New translation Fixing errors and grammatical misconceptions. Rectifying terminology. * Minor corrections in quick-start.md * Update quick-start.md Minor corrections * Update quick-start.md Small fix * Update quick-start.md * Update getting-started.md * Update quick-start.md * Update quick-start.md * Update quick-start.md * New translation installation.md New translation leveraging a consistent nomenklatura, fixing spelling errors * Update installation.md * Update installation.md * Update installation.md * Update docs/src/pages/de/getting-started.md Co-authored-by: Kim Schneider <web@schneider.kim> * Update docs/src/pages/de/getting-started.md Co-authored-by: Kim Schneider <web@schneider.kim> * Update docs/src/pages/de/getting-started.md Co-authored-by: Kim Schneider <web@schneider.kim> * Update docs/src/pages/de/installation.md Co-authored-by: Kim Schneider <web@schneider.kim> * Update docs/src/pages/de/quick-start.md Co-authored-by: Kim Schneider <web@schneider.kim> * Update docs/src/pages/de/quick-start.md Co-authored-by: Kim Schneider <web@schneider.kim> * Update docs/src/pages/de/quick-start.md Co-authored-by: Kim Schneider <web@schneider.kim> * Update docs/src/pages/de/installation.md Co-authored-by: Kim Schneider <web@schneider.kim> * Update docs/src/pages/de/getting-started.md Co-authored-by: Kim Schneider <web@schneider.kim> * [ci] yarn format * Create 0.21.0.md First translation * [ci] yarn format * Create themes.astro First translation * Create 404.astro First translation * Update 0.21.0.md Small changes according to the reviews. Additionally changing 'Hydratation' to 'Anreicherung' in the code example (76), which is far more closer to the fact. * [ci] yarn format * Update themes.astro Changed 'Motive' to 'Vorlagen' throughout this document * Create comparing-astro-vs-other-tools.md First translation. Last missing page from the first documentation section 'SETUP' * [ci] yarn format * Create astro-components.md First translation * [ci] yarn format * Update comparing-astro-vs-other-tools.md Corrected reference to Vue in Nuxt section * Update comparing-astro-vs-other-tools.md Replaced 'Vorlagen' with the english term 'Templates' for consistency inside nomenclature across all document pages. * Create astro-pages.md First translation * [ci] yarn format * Create project-structure.md First translation * Create component-hydration.md New translation * [ci] yarn format * Create layouts.md First translation * Create routing.md First translation * [ci] yarn format * Update quick-start.md Changed expression to 'Entwickeln' * Update installation.md Changed expression to 'Entwickeln' * Update comparing-astro-vs-other-tools.md Changed all occurences of 'partielle Anreicherung' to 'Partial Hydration' * Update comparing-astro-vs-other-tools.md Minor punctuation fix * Update astro-components.md Bunch of suggestions worked in * [ci] yarn format * Update astro-pages.md Added suggestions * Update component-hydration.md Added suggestions * Update layouts.md Added suggestions * [ci] yarn format * Update project-structure.md Added suggestions * Update routing.md Added suggestions * Update installation.md Added suggestions * Update 0.21.0.md Added suggestions * Update quick-start.md added suggestions * Update themes.astro Added suggestions * Update 0.21.0.md Added suggestion * Update astro-components.md Minor punctuation fix * [ci] yarn format * Update astro-components.md Replaced last of 'Anreicherung' * Update astro-components.md Punctuation fix, again((( * [ci] yarn format * Update docs/src/pages/de/core-concepts/astro-components.md Minor punctioation fix Co-authored-by: Kim Schneider <web@schneider.kim> * [ci] yarn format * Update astro-components.md Added code example, since github hickubs when only removing ';' * Added sidebar links (de) config.ts Added links to the first two sections of the German translation * Update config.ts Replaced Getting Started with 'Erste Schritte' * Update config.ts Replaced Themes with 'Vorlagen' * Update config.ts Changed Migration to 'Umstellung' * Fixing routing error((( * Fixing routing errors(( * reverse and fix routing errors((( Co-authored-by: Kim Schneider <web@schneider.kim> Co-authored-by: borisv <borisv@users.noreply.github.com> Co-authored-by: smplrtrn <smplrtrn@gmail.com>
This commit is contained in:
borisv
GitHub
parent
c6e4e2831e
commit
3a45925415
15 changed files with 1537 additions and 109 deletions
|
|
@ -40,9 +40,21 @@ export const SIDEBAR = {
|
||||||
{ text: 'Renderer Reference', link: 'reference/renderer-reference' },
|
{ text: 'Renderer Reference', link: 'reference/renderer-reference' },
|
||||||
],
|
],
|
||||||
de: [
|
de: [
|
||||||
{ text: 'Willkommen', header: true },
|
{ text: 'Setup', header: true },
|
||||||
{ text: 'Einführung', link: 'de/getting-started' },
|
{ text: 'Erste Schritte', link: 'getting-started' },
|
||||||
{ text: 'Schnellstart', link: 'de/quick-start' },
|
{ text: 'Schnellstart', link: 'quick-start' },
|
||||||
|
{ text: 'Installation', link: 'installation' },
|
||||||
|
{ text: 'Vorlagen', link: 'themes' },
|
||||||
|
{ text: 'Astro vs. X', link: 'comparing-astro-vs-other-tools' },
|
||||||
|
{ text: 'Umstellung auf v0.21', link: 'migration/0.21.0' },
|
||||||
|
|
||||||
|
{ text: 'Grundlagen', header: true },
|
||||||
|
{ text: 'Projekt-Struktur', link: 'core-concepts/project-structure' },
|
||||||
|
{ text: 'Komponenten-Syntax', link: 'core-concepts/astro-components' },
|
||||||
|
{ text: 'Seiten', link: 'core-concepts/astro-pages' },
|
||||||
|
{ text: 'Layouts', link: 'core-concepts/layouts' },
|
||||||
|
{ text: 'Routing', link: 'core-concepts/routing' },
|
||||||
|
{ text: 'Partial Hydration', link: 'core-concepts/component-hydration' },
|
||||||
],
|
],
|
||||||
nl: [
|
nl: [
|
||||||
{ text: 'Welkom', header: true },
|
{ text: 'Welkom', header: true },
|
||||||
|
|
|
||||||
9
docs/src/pages/de/404.astro
Normal file
9
docs/src/pages/de/404.astro
Normal file
|
|
@ -0,0 +1,9 @@
|
||||||
|
---
|
||||||
|
import SplashLayout from '../../layouts/SplashLayout.astro';
|
||||||
|
---
|
||||||
|
|
||||||
|
<SplashLayout title="Nicht gefunden">
|
||||||
|
<h1>404</h1>
|
||||||
|
<p>Diese Seite befindet sich nicht in unserem Sonnensystem.</p>
|
||||||
|
<a href="/">Bring mich nach Hause.</a>
|
||||||
|
</SplashLayout>
|
||||||
233
docs/src/pages/de/comparing-astro-vs-other-tools.md
Normal file
233
docs/src/pages/de/comparing-astro-vs-other-tools.md
Normal file
|
|
@ -0,0 +1,233 @@
|
||||||
|
---
|
||||||
|
layout: ~/layouts/MainLayout.astro
|
||||||
|
title: Vergleiche Astro
|
||||||
|
description: Vergleiche Astro mit anderen statischen Site-Renderern wie Gatsby, Next.js, Nuxt, Hugo, Eleventy und weiteren.
|
||||||
|
---
|
||||||
|
|
||||||
|
Wir werden oft gefragt, "Wie verhält sich Astro im Vergleich zu meinem bevorzugten Site-Renderer **\_\_\_\_**?" Diese Anleitung wurde verfasst, um diese Frage für verschiedene populäre Site-Renderer und Astro-Alternativen zu beantworten.
|
||||||
|
|
||||||
|
Falls dein bevorzugter Site-Renderer hier nicht aufgeführt ist, [frag uns danach in Discord](https://astro.build/chat).
|
||||||
|
|
||||||
|
## Projektstatus
|
||||||
|
|
||||||
|
Eine kurze Anmerkung zum Entwicklungsstand des Projektes: **Astro ist noch im Beta-Stadium.** Viele der Werkzeuge, die hier aufgeführt werden, sind sehr viel weiter fortgeschritten. Einige sind mehr als zwölf Jahre älter als Astro!
|
||||||
|
|
||||||
|
Einige Features sind noch nicht verfügbar und Teile der API noch nicht vollständig. Wie auch immer, das Projekt wird bezüglich seiner Fehleranfälligkeit als stabil angesehen und verschiedene Websites wurden schon für den produktiven Einsatz mit Astro umgesetzt. Dies ist ein wichtiger Punkt, wenn es um eine Entscheidung in Bezug auf den Einsatz von Astro geht.
|
||||||
|
|
||||||
|
## Docusaurus vs. Astro
|
||||||
|
|
||||||
|
[Docusaurus](https://docusaurus.io/) ist ein populärer Dokumentationssite-Renderer. Docusaurus verwendet React, um deine Website-UI zu generieren, während Astro in diesem Bereich React, Preact, Vue, Svelte, Solid und andere unterstützt - sowie auch eine an HTML angelehnte Komponenten-Syntax, die sich ähnlich verhält wie HTML + JSX.
|
||||||
|
|
||||||
|
Docusaurus wurde entwickelt, um Dokumentationswebsites zu erzeugen und bietet einige dokumentationsspezifische Features, über die Astro nicht verfügt. Stattdessen kannst du in Astro auf dokumentationsspezifische Features mittels einer offiziellen [`docs`](https://github.com/snowpackjs/astro/tree/main/examples/docs)-Vorlage zugreifen, die du für deine Site verwenden kannst. Diese Dokumentationswebsite wurde unter Verwendung dieser Vorlage erstellt!
|
||||||
|
|
||||||
|
### Leistungsvergleich Docusaurus vs. Astro
|
||||||
|
|
||||||
|
In den meisten Fällen werden Astro-Websites deutlich schneller laden als Docusaurus-Websites. Dies liegt vor allem daran, dass Astro unnötiges JavaScript vermeidet und nur diejenigen Komponenten einer Seite mit JavaScript anreichert, die dies benötigen. Dieses Feature wird [Partial Hydration](/core-concepts/component-hydration) genannt.
|
||||||
|
|
||||||
|
Docusaurus unterstützt Partial Hydration nicht. Stattdessen wird die gesamte Seite im Browser mit JavaScript angereichert, selbst wenn der größte Teil der Seite statisch ist. Dies führt zu längeren Ladezeiten und insgesamt schlechterer Leistung deiner Website. Es gibt keine Möglichkeit dieses Verhalten in Docusaurus abzuschalten.
|
||||||
|
|
||||||
|
### Fallstudie: Kompilieren einer Dokumentationswebsite
|
||||||
|
|
||||||
|
[docusaurus.io/docs](https://docusaurus.io/docs) ist die offizielle Docusaurus-Dokumentationswebsite - kompiliert mit Docusaurus. Die Website bietet ein ausreichend ähnliches Design und ausreichend ähnliche Funktionalität, um sie mit der offiziellen Astro-Dokumentationswebsite zu vergleichen. Dies ermöglicht uns einen **_grob realistischen_** Vergleich zwischen beiden Site-Renderern.
|
||||||
|
|
||||||
|
- **Docusaurus Leistungswert**: 61 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocusaurus.io%2Fdocs)
|
||||||
|
- **Astro Leistungswert**: 99 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
|
||||||
|
|
||||||
|
Ein wesentlicher Grund für diesen Leistungsunterschied liegt in Astros geringerer JavaScript-Last: [docusaurus.io/docs](https://docusaurus.io/docs) lädt **238kB** JavaScript mit dem ersten Seitenaufruf während [docs.astro.build](https://docs.astro.build) **78.7kB** (67% weniger JavaScript insgesamt) _nach_ dem ersten Seitenaufruf lädt.
|
||||||
|
|
||||||
|
## Elder.js vs. Astro
|
||||||
|
|
||||||
|
[Elder.js](https://elderguide.com/tech/elderjs/) ist ein Site-Renderer für Svelte mit stark ausgeprägten eigenen Vorstellungen.
|
||||||
|
|
||||||
|
Elder.js verwendet Svelte, um deine Website zu rendern. Astro ist hierin flexibler: Du kannst frei entscheiden mit welcher UI-Komponenten-Bibliothek du deine Oberfläche erzeugen willst (React, Preact, Vue, Svelte, Solid und andere), oder du verwendest die an HTML angelehnte Komponenten-Syntax von Astro, die sich ähnlich verhält wie HTML + JSX.
|
||||||
|
|
||||||
|
Elder.js hat eine besondere Stellung in dieser Auflistung, da es neben Astro der einzige Site-Renderer ist, der [Partial Hydration](/core-concepts/component-hydration) unterstützt. Sowohl Astro als auch Elder.js vermeiden automatisch unnötiges JavaScript auf der Seite und reichern nur die Komponenten damit an, die dies benötigen. Elders API für Partial Hydration unterscheidet sich etwas von der, die Astro verwendet. Und Astro unterstützt einige Features, über die Elder.js nicht verfügt (wie z. B. `client:media`). Wie auch immer, beide Werkzeuge erzeugen bezüglich der Leistung betrachtet sehr ähnliche Sites.
|
||||||
|
|
||||||
|
Elder.js verwendet eine spezifische Routing-Lösung, die für neue Entwickler ungewohnt erscheinen kann. Astro verwendet [dateibasiertes Routing](/core-concepts/routing), das sich für alle vertraut anfühlen sollte, die Erfahrung mit Next.js, SvelteKit oder auch anderen Site-Renderern wie Eleventy haben.
|
||||||
|
|
||||||
|
Elder.js wurde entwickelt, um große Websites zu erzeugen - und behauptet, es könne eine Website mit ca 20.000 Seiten in weniger als 10 Minuten rendern (auf einer durchschnittlichen VM). Zum Zeitpunkt der Erstellung dieses Textes rendert Astro ca 1.000 Seiten in 66 Sekunden, aber wurde noch nicht mit Projekten im Umfang von 20.000 Seiten getestet. Astro ist noch in einem frühen Beta-Stadium, und Elder.js Render-Geschwindigkeit zu erreichen ist ein Ziel für Astro v1.0.
|
||||||
|
|
||||||
|
Elder.js unterstützt sowohl statische Site-Generierung (SSG) als auch Server-seitiges Rendering (SSR). Zum jetzigen Zeitpunkt unterstützt Astro nur statische Site-Generierung (SSG).
|
||||||
|
|
||||||
|
## Eleventy vs. Astro
|
||||||
|
|
||||||
|
[Eleventy](https://www.11ty.dev/) ist ein beliebter statischer Site-Renderer auf der Grundlage von Node.js.
|
||||||
|
|
||||||
|
Eleventy verwendet verschiedene [ältere Sprachen für HTML-Templates](https://www.11ty.dev/docs/languages/), um deine Website zu rendern: Nunjucks, Liquid, Pug, EJS und andere. Astro erlaubt dir deine Websites mit deiner bevorzugten UI-Komponenten-Bibliothek (React, Preact, Vue, Svelte und andere) zu erzeugen, oder du verwendest die an HTML angelehnte Komponenten-Syntax von Astro, die sich ähnlich verhält wie HTML + JSX. Eleventy unterstützt keine modernen UI-Bibliotheken für die Erstellung von HTML-Templates.
|
||||||
|
|
||||||
|
### Leistungsvergleich Eleventy vs. Astro
|
||||||
|
|
||||||
|
Konzeptuell ist Eleventy auf Augenhöhe mit Astros "minimalistischem Einsatz von Client-seitigem JavaScript" bei der Web-Entwicklung. Eleventy und Astro bieten somit eine ähnliche Leistungsgrundlage durch ihre jeweilige Null-JavaScript-Strategie.
|
||||||
|
|
||||||
|
Eleventy erreicht dies, indem es dich dazu anhält JavaScript gänzlich zu vermeiden. Eleventy-Sites werden oft mit sehr wenig bis hin zu gar keinem JavaScript geschrieben. Dies wird allerdings dann zum Thema, wenn du tatsächlich Client-seitig JavaScript einsetzen musst. Es bleibt dann dir überlassen eine entsprechende Build-Pipeline für deine Skripte und weitere Elemente aufzubauen. Dies kann sich sehr zeitaufwendig gestalten, und es zwingt dich das Packen der Anwendung, sowie Minifizierung und weitere komplizierte Optimierungen von Hand aufzusetzen.
|
||||||
|
|
||||||
|
Im Gegensatz dazu kompiliert Astro automatisch dein Client-seitiges JavaScript & CSS für dich. Astro entfernt automatisch unnötiges JavaScript von der Seite und reichert nur die individuellen Komponenten damit an, die dies benötigen. Dieses Feature wird [Partial Hydration](/core-concepts/component-hydration) genannt. Während es dir natürlich möglich ist dieses Feature in Eleventy von Hand einzurichten, steht es dir in Astro bereits von vornherein zur Verfügung.
|
||||||
|
|
||||||
|
## Gatsby vs. Astro
|
||||||
|
|
||||||
|
[Gatsby](https://www.gatsbyjs.com/) ist eine beliebte Website- und Anwendungsbibliothek für React.
|
||||||
|
|
||||||
|
Gatsby verwendet React, um deine Website zu rendern. Astro ist hierin flexibler: Du kannst frei entscheiden mit welcher UI-Komponenten-Bibliothek du deine Oberfläche erzeugen willst (React, Preact, Vue, Svelte, Solid und andere), oder du verwendest die an HTML angelehnte Komponenten-Syntax von Astro, die sich ähnlich verhält wie HTML + JSX.
|
||||||
|
|
||||||
|
Gatsby v4 unterstützt statische Site-Generierung (Static Site Generation, SSG) mit inkrementellen Rebuilds sowie verzögerte statische Generierung (Deferred Static Generation, DSG), aber auch Server-seitiges Rendering (Server-Side Rendering, SSR). Zur Zeit unterstützt Astro nur statische Site-Generierung (SSG).
|
||||||
|
|
||||||
|
Gatsby erfordert für deine gesamte Arbeit mit Site-Inhalten eine eigene GraphQL-API. Während einige Entwicklerinnen und Entwickler an diesem Modell Gefallen finden, besteht eine häufig geäußerte Kritik an Gatsby darin, dass dieses Modell auf Dauer zu komplex und schwer aufrechtzuerhalten ist, insbesondere wenn Sites sehr umfangreich werden. Für die Arbeit mit Astro ist GraphQL nicht erforderlich, stattdessen bietet es gewohnte API (wie `fetch()` und `await` auf oberster Ebene), um Daten nah bei ihrer Anwendung zu laden.
|
||||||
|
|
||||||
|
### Leistungsvergleich Gatsby vs. Astro
|
||||||
|
|
||||||
|
In den meisten Fällen werden Astro-Websites deutlich schneller laden als Gatsby-Websites. Dies liegt vor allem daran, dass Astro unnötiges JavaScript vermeidet und nur diejenigen Komponenten einer Seite mit JavaScript anreichert, die dies benötigen. Dieses Feature wird [Partial Hydration](/core-concepts/component-hydration) genannt.
|
||||||
|
|
||||||
|
Gatsby unterstützt Partial Hydration nicht und lässt stattdessen den Browser die gesamte Seite erneut laden und mit JavaScript anreichern, selbst wenn der größte Teil der Seite statisch ist. Dies führt zu längeren Ladezeiten und schlechterer Leistung für deine Website. Gatsby verfügt über ein [Community Plugin](https://www.gatsbyjs.com/plugins/gatsby-plugin-no-javascript/), das sämtliches JavaScript von einer Seite entfernt, doch dies führt auch dazu, dass viele Websites nicht mehr wie beabsichtigt funktionieren. In Bezug auf Interaktivität auf einzelnen Seiten ist entprechend nur eine Entscheidung zwischen ganz oder gar nicht möglich.
|
||||||
|
|
||||||
|
Gatsby verfügt über ein großes Plugin-Ökosystem, was in Abhängigkeit von dem, was du benötigst, Gatsby zur besseren Wahl machen kann. [gatsby-plugin-image](https://www.gatsbyjs.com/plugins/gatsby-plugin-image/) z. B. ist ein beliebtes Plugin für Bildoptimierungen, das Gatsby zur besseren Wahl für bilderlastige Websites machen könnte.
|
||||||
|
|
||||||
|
### Fallstudie: Kompilieren einer Dokumentationswebsite
|
||||||
|
|
||||||
|
[gatsbyjs.com/docs](https://www.gatsbyjs.com/docs/quick-start/) ist die offizielle Gatsby-Dokumentationswebsite - kompiliert mit Gatsby. Die Website bietet ein ausreichend ähnliches Design und ausreichend ähnliche Funktionalität, um sie mit der offiziellen Astro-Dokumentationswebsite zu vergleichen. Dies ermöglicht uns einen **_grob realistischen_** Vergleich zwischen beiden Site-Renderern.
|
||||||
|
|
||||||
|
- **Gatsby Leistungswert**: 64 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fwww.gatsbyjs.com%2Fdocs%2Fquick-start%2F)
|
||||||
|
- **Astro Leistungswert**: 99 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
|
||||||
|
|
||||||
|
Ein wesentlicher Grund für diesen Leistungsunterschied liegt in Astros geringerer JavaScript-Last: [gatsbyjs.com/docs](https://www.gatsbyjs.com/docs/quick-start/) lädt **417kB** JavaScript mit dem ersten Seitenaufruf während [docs.astro.build](https://docs.astro.build) **78.7kB** (81% weniger JavaScript insgesamt) _nach_ dem ersten Seitenaufruf lädt.
|
||||||
|
|
||||||
|
## Hugo vs. Astro
|
||||||
|
|
||||||
|
[Hugo](https://gohugo.io/) ist ein beliebter statischer Site-Renderer auf der Grundlage von Go.
|
||||||
|
|
||||||
|
Hugo verwendet eine eigene [Templating Language](https://gohugo.io/templates/introduction/), um deine Website zu rendern. Astro erlaubt dir deine Websites mit deiner bevorzugten UI-Komponenten-Bibliothek (React, Preact, Vue, Svelte, Solid und andere) zu erzeugen, oder du verwendest die an HTML angelehnte Komponenten-Syntax von Astro, die sich ähnlich verhält wie HTML + JSX. Hugo unterstützt keine modernen UI-Bibliotheken für die Erstellung von HTML-Templates.
|
||||||
|
|
||||||
|
### Leistungsvergleich Hugo vs. Astro
|
||||||
|
|
||||||
|
Konzeptuell ist Hugo auf Augenhöhe mit Astros "minimalistischem Einsatz von Client-seitigem JavaScript" bei der Web-Entwicklung. Hugo und Astro bieten somit eine ähnliche Leistungsgrundlage durch ihre jeweilige Null-JavaScript-Strategie.
|
||||||
|
|
||||||
|
Sowohl Hugo als auch Astro bieten von vornherein Unterstützung beim Kompilieren, Packen und Minifizieren von JavaScript. Astro entfernt automatisch unnötiges JavaScript von der Seite und reichert nur die individuellen Komponenten damit an, die dies benötigen. Dieses Feature wird [Partial Hydration](/core-concepts/component-hydration) genannt. Während es dir natürlich möglich ist dieses Feature in Hugo von Hand einzurichten, steht es dir in Astro ebenfalls bereits von vornherein zur Verfügung.
|
||||||
|
|
||||||
|
## Jekyll vs. Astro
|
||||||
|
|
||||||
|
[Jekyll](https://jekyllrb.com/) ist ein beliebter statischer Site-Renderer auf der Grundlage von Ruby.
|
||||||
|
|
||||||
|
Jekyll verwendet eine ältere [Templating Language](https://jekyllrb.com/docs/liquid/) mit dem Namen Liquid, um deine Website zu rendern. Astro erlaubt dir deine Websites mit deiner bevorzugten UI-Komponenten-Bibliothek (React, Preact, Vue, Svelte, Solid und andere) zu erzeugen, oder du verwendest die an HTML angelehnte Komponenten-Syntax von Astro, die sich ähnlich verhält wie HTML + JSX. Jekyll unterstützt keine modernen UI-Bibliotheken für die Erstellung von HTML-Templates.
|
||||||
|
|
||||||
|
### Leistungsvergleich Jekyll vs. Astro
|
||||||
|
|
||||||
|
Konzeptuell ist Jekyll auf Augenhöhe mit Astros "minimalistischem Einsatz von Client-seitigem JavaScript" bei der Web-Entwicklung. Jekyll und Astro bieten somit eine ähnliche Leistungsgrundlage durch ihre jeweilige Null-JavaScript-Strategie.
|
||||||
|
|
||||||
|
Jekyll erreicht dies, indem es dich dazu anhält JavaScript gänzlich zu vermeiden. Jekyll-Sites werden oft mit sehr wenig bis hin zu gar keinem JavaScript geschrieben. Dies wird allerdings dann zum Thema, wenn du tatsächlich Client-seitig JavaScript einsetzen musst. Es bleibt dann dir überlassen eine entsprechende Build-Pipeline für deine Skripte und weitere Elemente aufzubauen. Dies kann sich sehr zeitaufwendig gestalten, und es zwingt dich das Packen der Anwendung, sowie Minifizierung und weitere komplizierte Optimierungen von Hand aufzusetzen.
|
||||||
|
|
||||||
|
Im Gegensatz dazu kompiliert Astro automatisch dein Client-seitiges JavaScript für dich. Astro sendet nur die minimal notwendige Menge an JavaScript an den Browser, minifiziert, gepackt und optimiert für die Veröffentlichung. Dieses Feature wird [Partial Hydration](/core-concepts/component-hydration) genannt. Während es dir natürlich möglich ist dieses Feature in Jekyll von Hand einzurichten, steht es dir in Astro bereits von vornherein zur Verfügung.
|
||||||
|
|
||||||
|
## SvelteKit vs. Astro
|
||||||
|
|
||||||
|
[SvelteKit](https://kit.svelte.dev/) ist eine beliebte Website- und Anwendungsbibliothek für Svelte.
|
||||||
|
|
||||||
|
SvelteKit verwendet Svelte, um deine Website zu rendern. Astro ist hierin flexibler: Du kannst frei entscheiden mit welcher UI-Komponenten-Bibliothek du deine Oberfläche erzeugen willst (React, Preact, Vue, Svelte, Solid und andere), oder du verwendest die an HTML angelehnte Komponenten-Syntax von Astro, die sich ähnlich verhält wie HTML + JSX.
|
||||||
|
|
||||||
|
Sowohl SvelteKit als auch Astro sind Bibliotheken für die Erzeugung von Websites. SvelteKit funktioniert am besten mit hochdynamischen Websites (wie Dashboards und Nachrichteneingängen), während Astro am besten mit größtenteils statischen Websites funktioniert (wie Content- und E-Commerce-Websites).
|
||||||
|
|
||||||
|
SvelteKit unterstützt sowohl statische Site-Generierung (Static Site Generation, SSG) als auch Server-seitiges Rendering (Server-Side Rendering, SSR). Zur Zeit unterstützt Astro nur statische Site-Generierung (SSG).
|
||||||
|
|
||||||
|
### Leistungsvergleich SvelteKit vs. Astro
|
||||||
|
|
||||||
|
In den meisten Fällen werden Astro-Websites schneller laden als SvelteKit-Websites. Dies liegt vor allem daran, dass Astro unnötiges JavaScript vermeidet und nur diejenigen Komponenten einer Seite mit JavaScript anreichert, die dies benötigen. Dieses Feature wird [Partial Hydration](/core-concepts/component-hydration) genannt.
|
||||||
|
|
||||||
|
SvelteKit unterstützt Partial Hydration nicht und lässt stattdessen den Browser die gesamte Seite erneut laden und mit JavaScript anreichern, selbst wenn der größte Teil der Seite statisch ist. Dies führt zu längeren Ladezeiten und schlechterer Leistung für deine Website. SvelteKit unterstützt mit [Page-Level Static und Zero-JavaScript Pages](https://kit.svelte.dev/docs#ssr-and-javascript-hydrate) das Entfernen von JavaScript per Seite oder für die gesamte Anwendung. Wie auch immer, eine Unterstützung für die Anreicherung individueller Komponenten einer Seite ist nicht geplant. In Bezug auf Interaktivität auf einzelnen Seiten ist entprechend nur eine Entscheidung zwischen ganz oder gar nicht möglich.
|
||||||
|
|
||||||
|
### Fallstudie: Kompilieren einer Dokumentationswebsite
|
||||||
|
|
||||||
|
[kit.svelte.dev](https://kit.svelte.dev/docs#ssr-and-javascript-hydrate) ist die offizielle SvelteKit-Dokumentationswebsite - kompiliert mit SvelteKit. Die Website bietet ein ausreichend ähnliches Design und ausreichend ähnliche Funktionalität, um sie mit der offiziellen Astro-Dokumentationswebsite zu vergleichen. Dies ermöglicht uns einen **_grob realistischen_** Vergleich zwischen beiden Site-Renderern.
|
||||||
|
|
||||||
|
Ein wichtiger zu beachtender Unterschied zwischen beiden Sites im Test: SveltKits Dokumentation wird als einzelne Seite ausgeliefert, während Astros Dokumentation in einzelne Seiten geteilt ausgeliefert wird. Diese höhere Content-Last dürfte einen leicht negativen Einfluss auf die Leistung haben und ist nicht auf das Werkzeug an sich zurückzuführen.
|
||||||
|
|
||||||
|
- **SvelteKit Leistungswert**: 92 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fkit.svelte.dev%2Fdocs)
|
||||||
|
- **Astro Leistungswert**: 99 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
|
||||||
|
|
||||||
|
Der Leistungswert von SvelteKit in diesem Test ist vergleichbar mit dem von Astro.
|
||||||
|
|
||||||
|
## Next.js vs. Astro
|
||||||
|
|
||||||
|
[Next.js](https://nextjs.org/) ist eine beliebte Website- und Anwendungsbibliothek für React.
|
||||||
|
|
||||||
|
Next.js verwendet React, um deine Website zu rendern. Astro ist hierin flexibler: Du kannst frei entscheiden mit welcher UI-Komponenten-Bibliothek du deine Oberfläche erzeugen willst (React, Preact, Vue, Svelte, Solid und andere), oder du verwendest die an HTML angelehnte Komponenten-Syntax von Astro, die sich ähnlich verhält wie HTML + JSX.
|
||||||
|
|
||||||
|
Sowohl Next.js als auch Astro sind Bibliotheken für die Erzeugung von Websites. Next.js funktioniert am besten mit hochdynamischen Websites (wie Dashboards und Nachrichteneingängen), während Astro am besten mit größtenteils statischen Websites funktioniert (wie Content- und E-Commerce-Websites).
|
||||||
|
|
||||||
|
Next.js unterstützt sowohl statische Site-Generierung (Static Site Generation, SSG) als auch Server-seitiges Rendering (Server-Side Rendering, SSR). Zur Zeit unterstützt Astro nur statische Site-Generierung (SSG).
|
||||||
|
|
||||||
|
### Leistungsvergleich Next.js vs. Astro
|
||||||
|
|
||||||
|
In den meisten Fällen werden Astro-Websites deutlich schneller laden als Next.js-Websites. Dies liegt vor allem daran, dass Astro unnötiges JavaScript vermeidet und nur diejenigen Komponenten einer Seite mit JavaScript anreichert, die dies benötigen. Dieses Feature wird [Partial Hydration](/core-concepts/component-hydration) genannt.
|
||||||
|
|
||||||
|
Next.js unterstützt Partial Hydration nicht und lässt stattdessen den Browser die gesamte Seite erneut laden und mit JavaScript anreichern, selbst wenn der größte Teil der Seite statisch ist. Dies führt zu längeren Ladezeiten und schlechterer Leistung für deine Website. Next.js verfügt über [Experimental Support](https://piccalil.li/blog/new-year-new-website/#heading-no-client-side-react-code) für vollständig statische, Null-JavaScript-Seiten. Wie auch immer, eine Unterstützung für die Anreicherung individueller Komponenten einer Seite ist nicht geplant. In Bezug auf Interaktivität auf einzelnen Seiten ist entprechend nur eine Entscheidung zwischen ganz oder gar nicht möglich.
|
||||||
|
|
||||||
|
Next.js verfügt über sehr gute integrierte Bildoptimierungen, was Next.js zur besseren Wahl für bilderlastige Websites machen könnte.
|
||||||
|
|
||||||
|
### Fallstudie: Kompilieren einer Dokumentationswebsite
|
||||||
|
|
||||||
|
[nextjs.org/docs](https://nextjs.org/docs/getting-started) ist die offizielle Next.js-Dokumentationswebsite - kompiliert mit Next.js. Die Website bietet ein ausreichend ähnliches Design und ausreichend ähnliche Funktionalität, um sie mit der offiziellen Astro-Dokumentationswebsite zu vergleichen. Dies ermöglicht uns einen **_grob realistischen_** Vergleich zwischen beiden Site-Renderern.
|
||||||
|
|
||||||
|
- **Next.js Leistungswert**: 59 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fnextjs.org%2Fdocs%2Fgetting-started)
|
||||||
|
- **Astro Leistungswert**: 99 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
|
||||||
|
|
||||||
|
Ein wesentlicher Grund für diesen Leistungsunterschied liegt in Astros geringerer JavaScript-Last: [nextjs.org/docs](https://nextjs.org/docs/getting-started) lädt **463kB** JavaScript mit dem ersten Seitenaufruf, während [docs.astro.build](https://docs.astro.build) **78.7kB** (83% weniger JavaScript insgesamt) _nach_ dem ersten Seitenaufruf lädt.
|
||||||
|
|
||||||
|
## Nuxt vs. Astro
|
||||||
|
|
||||||
|
[Nuxt](https://nuxtjs.org/) ist eine beliebte Website- und Anwendungsbibliothek für Vue. Es ist ähnlich aufgebaut wie Next.js.
|
||||||
|
|
||||||
|
Nuxt verwendet Vue, um deine Website zu rendern. Astro ist hierin flexibler: Du kannst frei entscheiden mit welcher UI-Komponenten-Bibliothek du deine Oberfläche erzeugen willst (React, Preact, Vue, Svelte, Solid und andere), oder du verwendest die an HTML angelehnte Komponenten-Syntax von Astro, die sich ähnlich verhält wie HTML + JSX.
|
||||||
|
|
||||||
|
Sowohl Nuxt als auch Astro sind Bibliotheken für die Erzeugung von Websites. Nuxt funktioniert am besten mit hochdynamischen Websites (wie Dashboards und Nachrichteneingängen), während Astro am besten mit größtenteils statischen Websites funktioniert (wie Content- und E-Commerce-Websites).
|
||||||
|
|
||||||
|
Nuxt unterstützt sowohl statische Site-Generierung (Static Site Generation, SSG) als auch Server-seitiges Rendering (Server-Side Rendering, SSR). Zur Zeit unterstützt Astro nur statische Site-Generierung (SSG).
|
||||||
|
|
||||||
|
### Leistungsvergleich Nuxt vs. Astro
|
||||||
|
|
||||||
|
In den meisten Fällen werden Astro-Websites deutlich schneller laden als Nuxt-Websites. Dies liegt vor allem daran, dass Astro unnötiges JavaScript vermeidet und nur diejenigen Komponenten einer Seite mit JavaScript anreichert, die dies benötigen. Dieses Feature wird [Partial Hydration](/core-concepts/component-hydration) genannt.
|
||||||
|
|
||||||
|
Nuxt unterstützt Partial Hydration nicht und lässt stattdessen den Browser die gesamte Seite erneut laden und mit JavaScript anreichern, selbst wenn der größte Teil der Seite statisch ist. Dies führt zu längeren Ladezeiten und schlechterer Leistung für deine Website. Es besteht keine Möglichkeit dieses Verhalten abzuschalten.
|
||||||
|
|
||||||
|
Nuxt verfügt über sehr gute integrierte Bildoptimierungen, was Nuxt zur besseren Wahl für bilderlastige Websites machen könnte.
|
||||||
|
|
||||||
|
### Fallstudie: Kompilieren einer Dokumentationswebsite
|
||||||
|
|
||||||
|
[nuxtjs.org/docs](https://nuxtjs.org/docs/2.x/get-started/installation) ist die offizielle Nuxt-Dokumentationswebsite - kompiliert mit Nuxt. Die Website bietet ein ausreichend ähnliches Design und ausreichend ähnliche Funktionalität, um sie mit der offiziellen Astro-Dokumentationswebsite zu vergleichen. Dies ermöglicht uns einen **_grob realistischen_** Vergleich zwischen beiden Site-Renderern.
|
||||||
|
|
||||||
|
- **Nuxt Leistungswert**: 48 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fnuxtjs.org%2Fdocs%2F2.x%2Fget-started%2Finstallation)
|
||||||
|
- **Astro Leistungswert**: 99 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
|
||||||
|
|
||||||
|
Ein wesentlicher Grund für diesen Leistungsunterschied liegt in Astros geringerer JavaScript-Last: [nuxtjs.org/docs](https://nuxtjs.org/docs/2.x/get-started/installation) lädt **469kb** JavaScript mit dem ersten Seitenaufruf, während [docs.astro.build](https://docs.astro.build) **78.7kB** (83% weniger JavaScript insgesamt) _nach_ dem ersten Seitenaufruf lädt.
|
||||||
|
|
||||||
|
## VuePress vs. Astro
|
||||||
|
|
||||||
|
[VuePress](https://vuepress.vuejs.org/guide/) ist ein populärer Dokumentationssite-Renderer auf der Grundlage von Vue. VuePress verwendet Vue, um deine Website-UI zu generieren, während Astro in diesem Bereich React, Preact, Vue, Svelte, Solid und andere unterstützt - sowie auch eine an HTML angelehnte Komponenten-Syntax, die sich ähnlich verhält wie HTML + JSX.
|
||||||
|
|
||||||
|
VuePress wurde entwickelt, um Dokumentationswebsites zu erzeugen und bietet einige dokumentationsspezifische Features, über die Astro nicht verfügt. Stattdessen verfügst du in Astro über dokumentationsspezifische Features mittels einer offiziellen [`docs`](https://github.com/snowpackjs/astro/tree/main/examples/docs)-Vorlage, die du für deine Site verwenden kannst. Diese Website wurde unter Verwendung dieser Vorlage erstellt!
|
||||||
|
|
||||||
|
Evan You (Erfinder von Vue) arbeitet zur Zeit an einer neuen Version von VuePress, genannt [VitePress](https://vitepress.vuejs.org/). Wenn du eine moderne Alternative zu VuePress suchst, [lies Evans Post](https://github.com/snowpackjs/astro/issues/1159#issue-974035962) darüber, warum VitePress hierfür eine bessere Option darstellen kann.
|
||||||
|
|
||||||
|
### Leistungsvergleich VuePress vs. Astro
|
||||||
|
|
||||||
|
In den meisten Fällen werden Astro-Websites deutlich schneller laden als VuePress-Websites. Dies liegt vor allem daran, dass Astro unnötiges JavaScript vermeidet und nur diejenigen Komponenten einer Seite mit JavaScript anreichert, die dies benötigen. Dieses Feature wird [Partial Hydration](/core-concepts/component-hydration) genannt.
|
||||||
|
|
||||||
|
VuePress unterstützt Partial Hydration nicht und lässt stattdessen den Browser die gesamte Seite erneut laden und mit JavaScript anreichern, selbst wenn der größte Teil der Seite statisch ist. Dies führt zu längeren Ladezeiten und schlechterer Leistung für deine Website. Es besteht keine Möglichkeit dieses Verhalten abzuschalten.
|
||||||
|
|
||||||
|
### Fallstudie: Kompilieren einer Dokumentationswebsite
|
||||||
|
|
||||||
|
[vuepress.vuejs.org](https://vuepress.vuejs.org/guide/) ist die offizielle VuePress-Dokumentationswebsite - kompiliert mit VuePress. Die Website bietet ein ausreichend ähnliches Design und ausreichend ähnliche Funktionalität, um sie mit der offiziellen Astro-Dokumentationswebsite zu vergleichen. Dies ermöglicht uns einen **_grob realistischen_** Vergleich zwischen beiden Site-Renderern.
|
||||||
|
|
||||||
|
- **Vuepress Leistungswert**: 63 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fvuepress.vuejs.org%2Fguide%2F)
|
||||||
|
- **Astro Leistungswert**: 99 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
|
||||||
|
|
||||||
|
Ein wesentlicher Grund für diesen Leistungsunterschied liegt in Astros geringerer JavaScript-Last: [vuepress.vuejs.org](https://vuepress.vuejs.org/guide/) lädt **166kb** JavaScript mit dem ersten Seitenaufruf, während [docs.astro.build](https://docs.astro.build) **78.7kB** (53% weniger JavaScript insgesamt) _nach_ dem ersten Seitenaufruf lädt.
|
||||||
|
|
||||||
|
## Zola vs. Astro
|
||||||
|
|
||||||
|
[Zola](https://www.getzola.org/) ist ein beliebter statischer Site-Renderer auf der Grundlage von Rust.
|
||||||
|
|
||||||
|
Zola verwendet [Tera](https://tera.netlify.app/), um deine Website zu rendern. Astro erlaubt dir deine Websites mit deiner bevorzugten UI-Komponenten-Bibliothek (React, Preact, Vue, Svelte, Solid und andere) zu erzeugen, oder du verwendest die an HTML angelehnte Komponenten-Syntax von Astro, die sich ähnlich verhält wie HTML + JSX. Zola unterstützt keine modernen UI-Bibliotheken für die Erstellung von HTML-Templates.
|
||||||
|
|
||||||
|
### Leistungsvergleich Zola vs. Astro
|
||||||
|
|
||||||
|
Konzeptuell ist Zola auf Augenhöhe mit Astros "minimalistischem Einsatz von Client-seitigem JavaScript" bei der Web-Entwicklung. Zola und Astro bieten somit eine ähnliche Leistungsgrundlage durch ihre jeweilige Null-JavaScript-Strategie.
|
||||||
|
|
||||||
|
Sowohl Zola als auch Astro bieten Unterstützung beim Kompilieren, Packen und Minifizieren von JavaScript. Zola benötigt hierfür ein zusätzliches Werkzeug wie Webpack, um JavaScript zu packen und zu verarbeiten. Astro entfernt automatisch unnötiges JavaScript von der Seite und reichert nur die individuellen Komponenten damit an, die dies benötigen. Dieses Feature wird [Partial Hydration](/core-concepts/component-hydration) genannt. Während es dir natürlich möglich ist dieses Feature in Zola von Hand einzurichten, steht es dir in Astro bereits von vornherein zur Verfügung.
|
||||||
386
docs/src/pages/de/core-concepts/astro-components.md
Normal file
386
docs/src/pages/de/core-concepts/astro-components.md
Normal file
|
|
@ -0,0 +1,386 @@
|
||||||
|
---
|
||||||
|
layout: ~/layouts/MainLayout.astro
|
||||||
|
title: Astro-Komponenten
|
||||||
|
description: Eine Einführung in die .astro-Komponenten-Syntax.
|
||||||
|
---
|
||||||
|
|
||||||
|
**Astro-Komponenten** (Dateien mit der Endung `.astro`) sind die Grundlage des Server-seitigen Templating in Astro. Du kannst dir die Astro-Komponenten-Syntax als HTML - erweitert um JavaScript - vorstellen.
|
||||||
|
|
||||||
|
Eine neue Syntax kann zu Beginn einschüchternd wirken, daher haben wir bei der Entwicklung der Astro-Komponenten-Syntax besonders darauf geachtet, dass sie sich für Web-Entwickler so vertraut wie möglich anfühlt. Sie lehnt sich sehr stark an Modelle an, die du wahrscheinlich schon kennst: Komponenten, Frontmatter, Props und JSX-Ausdrücke. Wir sind zuversichtlich, dass du mit Hilfe dieser Anleitung in kürzester Zeit Astro-Komponenten schreiben wirst, besonders wenn du bereits mit HTML & JavaScript vertraut bist.
|
||||||
|
|
||||||
|
## Syntax-Übersicht
|
||||||
|
|
||||||
|
Eine einzelne `.astro`-Datei repräsentiert eine einzelne Astro-Komponente in deinem Projekt. Dieses Modell wird als **Single-File Component (SFC)** bezeichnet. Sowohl Svelte (`.svelte`) als auch Vue (`.vue`) folgen ebenfalls diesem Modell.
|
||||||
|
|
||||||
|
Im Weiteren findest du eine eingehende Beschreibung der verschiedenen Elemente und Merkmale der Astro-Komponenten-Syntax. Du kannst sie von Anfang bis Ende durchlesen oder auch zwischen den Abschnitten springen.
|
||||||
|
|
||||||
|
### HTML-Template
|
||||||
|
|
||||||
|
Die Astro-Komponenten-Syntax ist eine Obermenge von HTML. **Wenn du HTML kennst, weißt du bereits genug, um deine erste Komponente zu schreiben.**
|
||||||
|
|
||||||
|
Zum Beispiel ist diese dreizeilige Datei eine gültige Astro-Komponente:
|
||||||
|
|
||||||
|
```html
|
||||||
|
<!-- Beispiel1.astro - statisches HTML ist eine gültige Astro-Komponente! -->
|
||||||
|
<div class="beispiel-1">
|
||||||
|
<h1>Hallo Welt!</h1>
|
||||||
|
</div>
|
||||||
|
```
|
||||||
|
|
||||||
|
Eine Astro-Komponente repräsentiert einen Schnipsel HTML in deinem Projekt. Dies kann eine mehrfach verwendbare Komponente sein, oder eine vollständige Seite HTML einschließlich `<html>`-, `<head>`- und `<body>`-Elementen. Lies auch unsere Anleitung zu [Astro-Seiten](/core-concepts/astro-pages), um zu lernen wie du deine erste vollständige HTML-Seite mit Astro erzeugen kannst.
|
||||||
|
|
||||||
|
**Jede Astro-Komponente muss ein HTML-Template beinhalten.** Auch wenn du deine Komponente auf vielfältige Weise erweitern kannst (siehe unten), bestimmt am Ende des Tages doch das HTML-Template, wie deine gerenderte Komponente aussehen wird.
|
||||||
|
|
||||||
|
### CSS-Styles
|
||||||
|
|
||||||
|
CSS-Regeln innerhalb eines `<style>`-Tag werden spezifisch nur auf diese Komponente angewendet. Das bedeutet auch, dass du Klassennamen über unterschiedliche Komponenten hinweg wiederholt verwenden kannst, ohne auf mögliche Konflikte achten zu müssen. Styles werden mit jedem Build automatisch extrahiert und optimiert, so dass du dir über das Laden der passenden Styles keine Gedanken machen musst.
|
||||||
|
|
||||||
|
Um dabei die besten Ergebnisse zu erzielen, solltest du nicht mehr als ein `<style>`-Tag pro Astro-Komponente verwenden. Dies ist keine zwingende Beschränkung, wird aber oftmals zu einer besseren Optimierung des CSS in einem Build führen. Wenn du mit kompletten Seiten arbeitest, kann das `<style>`-Tag innerhalb des `<head>`
|
||||||
|
-Blocks stehen. In alleinstehenden Komponenten kann ein `<style>`-Tag in der oberste Ebene eines Template gesetzt werden.
|
||||||
|
|
||||||
|
```html
|
||||||
|
<!-- Astro-Komponente CSS-Beispiel -->
|
||||||
|
<style>
|
||||||
|
.kreis {
|
||||||
|
background-color: red;
|
||||||
|
border-radius: 999px;
|
||||||
|
height: 50px;
|
||||||
|
width: 50px;
|
||||||
|
}
|
||||||
|
</style>
|
||||||
|
<div class="kreis"></div>
|
||||||
|
```
|
||||||
|
|
||||||
|
```html
|
||||||
|
<!-- Astro-Seite CSS-Beispiel -->
|
||||||
|
<html>
|
||||||
|
<head>
|
||||||
|
<style>
|
||||||
|
.kreis {
|
||||||
|
background-color: red;
|
||||||
|
border-radius: 999px;
|
||||||
|
height: 50px;
|
||||||
|
width: 50px;
|
||||||
|
}
|
||||||
|
</style>
|
||||||
|
</head>
|
||||||
|
<body>
|
||||||
|
...
|
||||||
|
</body>
|
||||||
|
</html>
|
||||||
|
```
|
||||||
|
|
||||||
|
Die Verwendung von `<style global>` schaltet die ausschließlich spezifische Anwendung auf die enthaltende Komponente oder Seite für jede CSS-Regel im `<style>`-Block aus. Diese Umgehung sollte wann immer möglich vermieden werden, kann aber nützlich sein, wenn du zum Beispiel das Styling von HTML-Elementen aus einer externen Bibliothek ändern musst.
|
||||||
|
|
||||||
|
Sass (eine Alternative zu CSS) ist ebenfalls verfügbar via `<style lang="scss">`.
|
||||||
|
|
||||||
|
📚 Lies unsere vollständige Anleitung zum [Styling von Komponenten](/guides/styling), um mehr zu erfahren.
|
||||||
|
|
||||||
|
### Frontmatter-Skript
|
||||||
|
|
||||||
|
Um dynamische Komponenten zu erzeugen, bringen wir die Idee eines Frontmatter-Komponenten-Skripts ein. [Frontmatter](https://jekyllrb.com/docs/front-matter/) ist ein in Markdown übliches Muster, bei dem Konfigurations- und Metadaten innerhalb einer Code-Begrenzung (`---`) am Anfang der Datei stehen. Astro bietet etwas Vergleichbares, jedoch mit vollständiger Unterstützung für JavaScript & TypeScript innerhalb deiner Komponenten.
|
||||||
|
|
||||||
|
Bedenke dass Astro eine Server-seitige Template-Sprache ist, also wird dein Komponenten-Skript während des Build ausgeführt, aber für den Browser wird nur das HTML gerendert. Um auch JavaScript an den Browser zu senden, kannst du ein `<script>`-Tag in deinem HTML-Template verwenden - oder du [konvertierst deine Komponente für die Verwendung einer bestimmten Frontend-Bibliothek](/core-concepts/component-hydration) wie React, Svelte, Vue etc.
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
// Alles innnerhalb der `---`-Code-Begrenzung ist dein Komponenten-Skript.
|
||||||
|
// Dieser JavaScript-Code wird während des Build ausgeführt.
|
||||||
|
// Siehe weiter unten, was du damit machen kannst.
|
||||||
|
console.log('Dies hier wird mit dem Build ausgeführt - ist in der CLI-Ausgabe zu sehen');
|
||||||
|
// Tipp: TypeScript wird ebenfalls direkt unterstützt!
|
||||||
|
const thisWorks: number = 42;
|
||||||
|
---
|
||||||
|
<div class="example-1">
|
||||||
|
<h1>Hallo Welt!</h1>
|
||||||
|
</div>
|
||||||
|
```
|
||||||
|
|
||||||
|
### Komponenten-Importe
|
||||||
|
|
||||||
|
Eine Astro-Komponente kann andere Astro-Komponenten innerhalb des eigenen HTML-Template wiederverwenden. Dies legt den Grundstein für unser Komponenten-System: Erzeuge neue Komponenten und verwende sie anschließend überall in deinem Projekt.
|
||||||
|
|
||||||
|
Um eine Astro-Komponente in deinem Projekt zu verwenden, musst du sie zunächst im Frontmatter-Komponenten-Skript importieren. Eine Astro-Komponente ist immer der Standard-Import der Datei.
|
||||||
|
|
||||||
|
Einmal importiert, kannst du sie wie jedes andere HTML-Element in deinem Template verwenden. Beachte dass eine Astro-Komponente mit einem Großbuchstaben beginnen **MUSS**. Astro nutzt dies, um zwischen nativen HTML-Elementen (`form`, `input`, etc.) und deinen eigenen Astro-Komponenten zu unterscheiden.
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
// Importiere deine Komponenten in deinem Komponenten-Skript...
|
||||||
|
import EineKomponente from './EineKomponente.astro';
|
||||||
|
---
|
||||||
|
<!-- ... und verwende sie dann in deinem HTML! -->
|
||||||
|
<div>
|
||||||
|
<EineKomponente />
|
||||||
|
</div>
|
||||||
|
```
|
||||||
|
|
||||||
|
📚 Du kannst auch Komponenten aus anderen Frontend-Bibliotheken wie React, Svelte, Vue und anderen importieren und verwenden. Lies unsere Anleitung zu [Partial Hydration](/core-concepts/component-hydration), um mehr zu erfahren.
|
||||||
|
|
||||||
|
### Dynamische JSX-Ausdrücke
|
||||||
|
|
||||||
|
Anstatt für dynamisches Templating unsere eigene Syntax zu entwickeln, geben wir dir den direkten Zugriff auf JavaScript innerhalb deines HTML, indem wir etwas verwenden, das sich wie [JSX](https://reactjs.org/docs/introducing-jsx.html) anfühlt.
|
||||||
|
|
||||||
|
Astro-Komponenten können lokale Variablen innerhalb des Frontmatter-Skriptes definieren. Jedes Skript-Variable ist anschließend automatisch im HTML-Template darunter verfügbar.
|
||||||
|
|
||||||
|
#### Dynamische Werte
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
const name = "Dein Name hier";
|
||||||
|
---
|
||||||
|
<div>
|
||||||
|
<h1>Hallo {name}!</h1>
|
||||||
|
</div>
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Dynamische Attribute
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
const name = "Dein Name hier";
|
||||||
|
---
|
||||||
|
<div>
|
||||||
|
<div data-name={name}>Attribut-Ausdrücke unterstützt</div>
|
||||||
|
<div data-hint={`Verwende Template Literals, um ${"variables"} zu mischen.`}>So gut!</div>
|
||||||
|
</div>
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Dynamisches HTML
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
const items = ["Hund", "Katze", "Schnabeltier"];
|
||||||
|
---
|
||||||
|
<ul>
|
||||||
|
{items.map((item) => (
|
||||||
|
<li>{item}</li>
|
||||||
|
))}
|
||||||
|
</ul>
|
||||||
|
```
|
||||||
|
|
||||||
|
### Komponenten-Eigenschaften (Props)
|
||||||
|
|
||||||
|
Eine Astro-Komponente kann Eigenschaften definieren und annehmen. Eigenschaften sind über die `Astro.props` global in deinem Frontmatter-Skript verfügbar.
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
// Beispiel: <EineKomponente greeting="(Optional) Hallo" name="Erforderlicher Name" />
|
||||||
|
const { greeting = 'Hallo', name } = Astro.props;
|
||||||
|
---
|
||||||
|
<div>
|
||||||
|
<h1>{greeting}, {name}!</h1>
|
||||||
|
</div>
|
||||||
|
```
|
||||||
|
|
||||||
|
Du kannst deine Eigenschaften mit TypeScript definieren, indem du eine `Props`-Type-Schnittstelle exportierst. Astro wird automatisch jede exportierte `Props`-Type-Schnittstelle erfassen und Type-Warnungen/Errors für dein Projekt generieren und ausgeben.
|
||||||
|
|
||||||
|
Stelle sicher, dass du alle `import`- und `export`-Anweisungen oben in der Komponente angibst - vor jeder weiteren JavaScript- oder TypeScript-Logik!
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
// Gib `import`- und `export`-Anweisungen zuerst
|
||||||
|
// Beispiel: <EineKomponente /> (WARNUNG: "name"-Prop ist erforderlich)
|
||||||
|
export interface Props {
|
||||||
|
name: string;
|
||||||
|
greeting?: string;
|
||||||
|
}
|
||||||
|
|
||||||
|
// Nachdem alle `import`- und `export`-Anweisungen gemacht sind, gib den Rest der Komponenten-Logik hier an
|
||||||
|
const { greeting = 'Hallo', name } = Astro.props;
|
||||||
|
---
|
||||||
|
<div>
|
||||||
|
<h1>{greeting}, {name}!</h1>
|
||||||
|
</div>
|
||||||
|
```
|
||||||
|
|
||||||
|
Anschließend kannst du die Komponenten-Eigenschaften folgendermaßen weiterreichen:
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
// EineAndereKomponente.astro
|
||||||
|
import EineKomponente from "./EineKomponente.astro";
|
||||||
|
let firstName = "Welt!";
|
||||||
|
---
|
||||||
|
<EineKomponente name={firstName}/>
|
||||||
|
```
|
||||||
|
|
||||||
|
### Slots
|
||||||
|
|
||||||
|
`.astro`-Dateien verwenden das [`<slot>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/slot)-Tag, um Komponenten-Zusammenstellungen zu ermöglichen. Wenn du von React oder Preact kommst, entspricht dies dem Konzept der `children`. Du kannst dir das `<slot>`-Element als einen Platzhalter für Markup vorstellen, das von außerhalb der Komponente hinzugefügt wird.
|
||||||
|
|
||||||
|
```astro
|
||||||
|
<!-- Beispiel: MeineKomponente.astro -->
|
||||||
|
<div id="meine-komponente">
|
||||||
|
<slot /> <!-- untergeordnete Elemente landen hier -->
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<!-- Verwendung -->
|
||||||
|
<MeineKomponente>
|
||||||
|
<h1>Hallo Welt!</h1>
|
||||||
|
</MeineKomponente>
|
||||||
|
```
|
||||||
|
|
||||||
|
Beachte dass, wenn der `<slot>`-Tag in einem HTML-Template nicht verwendet wird, alle untergeordneten Elemente, die an die Komponente übergeben werden, nicht gerendert werden.
|
||||||
|
|
||||||
|
Slots werden sogar noch mächtiger, wenn **benannte Slots** verwendet werden. Anders als ein einzelnes `<slot>`-Element, das _alle_ untergeordneten Elemente rendert, erlauben benannte Slots mehrere Orte zu bestimmen, an denen untergeordnete Elemente plaziert werden sollen.
|
||||||
|
|
||||||
|
> **Beachte:** Das `slot`-Attribut ist nicht auf reines HTML beschränkt, Komponenten können `slot` ebenfalls verwenden!
|
||||||
|
|
||||||
|
```astro
|
||||||
|
<!-- Beispiel: MeineKomponente.astro -->
|
||||||
|
<div id="meine-komponente">
|
||||||
|
<header>
|
||||||
|
<!-- Untergeordnete Elemente mit dem `slot="header"`-Attribut landen hier -->
|
||||||
|
<slot name="header" />
|
||||||
|
</header>
|
||||||
|
<main>
|
||||||
|
<!-- Untergeordnete Elemente ohne `slot`- oder mit dem `slot="default"`-Attribut landen hier -->
|
||||||
|
<slot />
|
||||||
|
</main>
|
||||||
|
<footer>
|
||||||
|
<!-- Untergeordnete Elemente mit dem `slot="footer"`-Attribut landen hier -->
|
||||||
|
<slot name="footer" />
|
||||||
|
</footer>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<!-- Verwendung -->
|
||||||
|
<MeineKomponente>
|
||||||
|
<h1 slot="header">Hallo Welt!</h1>
|
||||||
|
<p>Lorem ipsum ...</p>
|
||||||
|
<FooterKomponente slot="footer" />
|
||||||
|
</MeineKomponente>
|
||||||
|
```
|
||||||
|
|
||||||
|
Slots können auch **Rückfall-Platzhalter** rendern. Wenn keine passenden untergeordneten Elemente an einen `<slot>` weitergereicht werden, wird dieses `<slot>`-Element seine eigenen untergeordneten Platzhalter-Elemente rendern.
|
||||||
|
|
||||||
|
```astro
|
||||||
|
<!-- MeineKomponente.astro -->
|
||||||
|
<div id="meine-komponente">
|
||||||
|
<slot>
|
||||||
|
<h1>Ich werde gerendert, wenn dieser Slot keine untergeordneten Elemente hat!</h1>
|
||||||
|
</slot>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<!-- Verwendung -->
|
||||||
|
<MeineKomponente />
|
||||||
|
```
|
||||||
|
|
||||||
|
### Fragmente & Mehrfache Elemente
|
||||||
|
|
||||||
|
Ein Astro-Komponenten-Template kann so viele Elemente in der obersten Ebene rendern, wie du willst. Anders als bei anderen UI-Komponenten-Bibliotheken musst du nicht alles mit einzelnen `<div>`-Elementen umschließen, wenn du das nicht bevorzugst.
|
||||||
|
|
||||||
|
```html
|
||||||
|
<!-- Eine Astro-Komponente kann mehrere Elemente in der obersten Ebene beinhalten: -->
|
||||||
|
<div id="a" />
|
||||||
|
<div id="b" />
|
||||||
|
<div id="c" />
|
||||||
|
```
|
||||||
|
|
||||||
|
Allerdings musst du innerhalb eines JSX-Ausdrucks mehrere Elemente immer mit einem **Fragment** umschließen. Fragmente lassen dich auf einmal mehrere Elementen rendern, ohne dem DOM zusätzliche Nodes hinzuzufügen. Dies wird bei JSX-Ausdrücken auf Grund einer Beschränkung in JavaScript vorausgesetzt: Du kannst niemals mehr als ein Element in einem JavaScript-Ausdruck oder einer JavaScript-Funktion `zurückgeben`. Die Verwendung eines Fragments löst dieses Problem.
|
||||||
|
|
||||||
|
Ein Fragment muss mit `<>` öffnen und mit `</>` schließen. Keine Sorge, wenn du es vergisst, wird dich der Astro-Kompilierer daran erinnern.
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
const items = ["Hund", "Katze", "Schnabeltier"];
|
||||||
|
---
|
||||||
|
<ul>
|
||||||
|
{items.map((item) => (
|
||||||
|
<>
|
||||||
|
<li>Rot {item}</li>
|
||||||
|
<li>Blau {item}</li>
|
||||||
|
<li>Grün {item}</li>
|
||||||
|
</>
|
||||||
|
))}
|
||||||
|
</ul>
|
||||||
|
```
|
||||||
|
|
||||||
|
### Priorisierte Skripte
|
||||||
|
|
||||||
|
Standardmäßig macht Astro keine Annahmen dazu, wie deine Skripte bereitgestellt werden sollen. Wenn du also einer Seite oder einer Komponente ein `<script>`-Tag hinzufügst, wird es nicht angerührt.
|
||||||
|
|
||||||
|
Wenn du jedoch die Skripte aus der Komponente lösen und an den Anfang der Seite verschieben und anschließend für die Veröffentlichung gebündelt haben möchtest, kannst du das mit priorisierten Skripten machen.
|
||||||
|
|
||||||
|
Ein **priorisiertes Skript** sieht so aus:
|
||||||
|
|
||||||
|
```astro
|
||||||
|
<script hoist>
|
||||||
|
// Ein Inline-Skript
|
||||||
|
</script>
|
||||||
|
```
|
||||||
|
|
||||||
|
Oder es kann auf eine externe Skript-Datei verweisen:
|
||||||
|
|
||||||
|
```astro
|
||||||
|
<script src={Astro.resolve('./meine-komponente.js')} hoist></script>
|
||||||
|
```
|
||||||
|
|
||||||
|
Ein priorisiertes Skript kann innerhalb einer Seite oder Komponente stehen, und unabhängig davon wie oft die Komponente verwendet wird, das Skript wird nur einmal hinzugefügt:
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
import TwitterTimeline from '../components/TwitterTimeline.astro';
|
||||||
|
---
|
||||||
|
|
||||||
|
<-- Das Skript wird nur einmal in den `head`-Block eingefügt. -->
|
||||||
|
<TwitterTimeline />
|
||||||
|
<TwitterTimeline />
|
||||||
|
<TwitterTimeline />
|
||||||
|
```
|
||||||
|
|
||||||
|
## Vergleich `.astro` vs. `.jsx`
|
||||||
|
|
||||||
|
`.astro`-Dateien können im Laufe der Entwicklung `.jsx`-Dateien sehr ähnlich werden, aber es gibt einige wesentliche Unterschiede. Hier ein Vergleich beider Formate.
|
||||||
|
|
||||||
|
| Merkmal | Astro | JSX |
|
||||||
|
| ------------------------------ | --------------------------------------------------- | ----------------------------------------------------- |
|
||||||
|
| Dateiendungen | `.astro` | `.jsx` or `.tsx` |
|
||||||
|
| Selbstdefinierte Komponenten | `<Großschreibung>` | `<Großschreibung>` |
|
||||||
|
| Syntax Ausdruck | `{}` | `{}` |
|
||||||
|
| Spread-Attribute | `{...props}` | `{...props}` |
|
||||||
|
| Boolsche Attribute | `autocomplete` === `autocomplete={true}` | `autocomplete` === `autocomplete={true}` |
|
||||||
|
| Inline-Funktionen | `{items.map(item => <li>{item}</li>)}` | `{items.map(item => <li>{item}</li>)}` |
|
||||||
|
| IDE-Unterstützung | WIP - [VS Code][code-ext] | Phänomenal |
|
||||||
|
| Benötigt JS-Import | Nein | Ja, (`React` oder `h`) müssen im Geltungsbereich sein |
|
||||||
|
| Fragmente | Autom. oberste Ebene, `<>` innerhalb von Funktionen | Einfassen mit `<Fragment>` oder `<>` |
|
||||||
|
| Mehrere Bibliotheken pro Datei | Ja | Nein |
|
||||||
|
| Änderungen von `<head>` | Einfach `<head>` verwenden | Je nach Bibliothek (`<Head>`, `<svelte:head>`, etc.) |
|
||||||
|
| Kommentarstil | `<!-- HTML -->` | `{/* JavaScript */}` |
|
||||||
|
| Spezielle Zeichen | ` ` | `{'\xa0'}` oder `{String.fromCharCode(160)}` |
|
||||||
|
| Attribute | `dash-case` | `camelCase` |
|
||||||
|
|
||||||
|
## URL-Auflösung
|
||||||
|
|
||||||
|
Es ist wichtig zu verstehen, dass Astro HTML-Referenzen **nicht** transformiert. Zum Beispiel in einem `<img>`-Tag mit einem relativen `src`-Attribut in `src/pages/about.astro`:
|
||||||
|
|
||||||
|
```html
|
||||||
|
<!-- ❌ Inkorrekt: wird versuchen `/about/thumbnail.png` zu laden -->
|
||||||
|
<img src="./thumbnail.png" />
|
||||||
|
```
|
||||||
|
|
||||||
|
Da `src/pages/about.astro` als `/about/index.html` gespeichert wird, wird es dich möglicherweise überraschen, dass das Bild nach `/about/thumbnail.png` gespeichert wird. Um Konflikte zu vermeiden, wähle eine der zwei folgenden Optionen:
|
||||||
|
|
||||||
|
#### Option 1: Absolute URL
|
||||||
|
|
||||||
|
```html
|
||||||
|
<!-- ✅ Korrekt: referenziert public/thumbnail.png -->
|
||||||
|
<img src="/thumbnail.png" />
|
||||||
|
```
|
||||||
|
|
||||||
|
Der empfohlene Ansatz ist Dateien innerhalb von `public/*` zu speichern. Dies referenziert eine Datei unter `public/thumbnail.png`, welche nach dem Build zu `/thumbnail.png` aufgelöst wird (da `public/` dabei unter `/` endet).
|
||||||
|
|
||||||
|
#### Option 2: Asset-Import-Referenzen
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
// ✅ Korrekt: referenziert src/thumbnail.png
|
||||||
|
import thumbnailSrc from './thumbnail.png';
|
||||||
|
---
|
||||||
|
|
||||||
|
<img src={thumbnailSrc} />
|
||||||
|
```
|
||||||
|
|
||||||
|
Falls du bevorzugst Assets gemeinsam mit Astro-Komponenten zu verwalten, kannst du die Datei mit JavaScript innerhalb des Komponenten-Skriptes importieren. Dies wird wie beabsichtigt funktionieren, erschwert jedoch die Referenzierung von `thumnail.png` an anderen Stellen innerhalb der Anwendung, da die finale URL nur schwer vorhersagbar ist (anders als mit Assets in `public/*`, wo sich die Adresse garantiert nie ändern wird).
|
||||||
|
|
||||||
|
[code-ext]: https://marketplace.visualstudio.com/items?itemName=astro-build.astro-vscode
|
||||||
67
docs/src/pages/de/core-concepts/astro-pages.md
Normal file
67
docs/src/pages/de/core-concepts/astro-pages.md
Normal file
|
|
@ -0,0 +1,67 @@
|
||||||
|
---
|
||||||
|
layout: ~/layouts/MainLayout.astro
|
||||||
|
title: Seiten
|
||||||
|
description: Eine Einführung in Astro-Seiten, Komponenten die wie komplette Seiten funktionieren.
|
||||||
|
---
|
||||||
|
|
||||||
|
**Seiten** sind eine spezielle Art der [Astro-Komponente](/core-concepts/astro-components), die das Routing, das Laden von Daten und das Templating für eine Seite deiner Website erledigt. Du kannst sie dir wie eine einfache Astro-Komponente vorstellen - jedoch mit erweiterter Zuständigkeit.
|
||||||
|
|
||||||
|
Astro unterstützt Markdown für Content-lastige Seiten, wie Blog-Posts und Dokumentationen. Lies [Markdown-Inhalte](/guides/markdown-content), um mehr über das Schreiben von Seiten mit Markdown zu erfahren.
|
||||||
|
|
||||||
|
## Dateibasiertes Routing
|
||||||
|
|
||||||
|
Astro verwendet Seiten für etwas das **dateibasiertes Routing** genannt wird. Jede Datei in deinem `src/pages`-Verzeichnis wird eine Seite deiner Website - unter Verwendung des Dateinamens für die Festlegung der endgültigen Route.
|
||||||
|
|
||||||
|
Astro-Komponenten (`.astro`) und Markdown-Dateien (`.md`) sind die einzigen Seitenformate, die in Astro unterstützt werden. Andere Seitentypen (wie z. B. `.jsx`-React-Komponenten) werden nicht unterstützt, aber du kannst andere Formate als UI-Komponenten _innerhalb_ einer `.astro`-Seite verwenden, um ein vergleichbares Ergebnis zu erhalten.
|
||||||
|
|
||||||
|
```
|
||||||
|
src/pages/index.astro -> meinesite.com/
|
||||||
|
src/pages/about.astro -> meinesite.com/about
|
||||||
|
src/pages/about/index.astro -> meinesite.com/about
|
||||||
|
src/pages/about/me.astro -> meinesite.com/about/me
|
||||||
|
src/pages/posts/1.md -> meinesite.com/posts/1
|
||||||
|
```
|
||||||
|
|
||||||
|
## Seiten-Templating
|
||||||
|
|
||||||
|
Alle Astro-Komponenten geben HTML aus. Astro-Seiten geben ebenfalls HTML aus, müssen zusätzlich jedoch die besondere Aufgabe erfüllen eine vollständige _Seitenantwort_ zu liefern - einschließlich `<html>...</html>`, `<head>` ([MDN<span class="sr-only">- head</span>](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/head)) und `<body>` ([MDN<span class="sr-only">- body</span>](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/body)).
|
||||||
|
|
||||||
|
`<!doctype html>` ist optional - es wird automatisch hinzugefügt.
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
// Beispiel: HTML-Seite Grundgerüst
|
||||||
|
---
|
||||||
|
<!doctype html>
|
||||||
|
<html>
|
||||||
|
<head>
|
||||||
|
<title>Titel des Dokuments</title>
|
||||||
|
</head>
|
||||||
|
<body>
|
||||||
|
<h1>Hallo, Welt!</h1>
|
||||||
|
</body>
|
||||||
|
</html>
|
||||||
|
```
|
||||||
|
|
||||||
|
## Laden von Daten
|
||||||
|
|
||||||
|
Astro-Seiten können Daten abrufen, die benötigt werden, um deine Seiten zu generieren. Astro stellt dir zwei verschiedene Werkzeuge dafür zur Verfügung, die dabei helfen: **fetch()** und **top-level await**.
|
||||||
|
|
||||||
|
📚 Lies unsere [vollständige Anleitung](/guides/data-fetching) über das Abrufen von Daten, um mehr zu erfahren.
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
// Beispiel: Astro-Komponenten-Skripte, werden ausgeführt während des Build-Prozesses
|
||||||
|
const response = await fetch('http://beispiel.de/filme.json');
|
||||||
|
const data = await response.json();
|
||||||
|
console.log(data);
|
||||||
|
---
|
||||||
|
<!-- Ausgabe des Ergebnisses auf der Seite -->
|
||||||
|
<div>{JSON.stringify(data)}</div>
|
||||||
|
```
|
||||||
|
|
||||||
|
## Eigene 404-Fehlerseite
|
||||||
|
|
||||||
|
Um eine eigene allgemeine 404-Fehlerseite zu erhalten, erzeuge eine `404.astro`-Datei in `/src/pages`. Diese Datei kompiliert zu einer `404.html`-Seite. Die meisten [Veröffentlichungsdienste](/guides/deploy) können diese Seite aufgreifen und verwenden sie entsprechend.
|
||||||
|
|
||||||
|
Dieses Verhalten unterscheidet sich von dem standardmäßigen Verhalten beim Kompilieren von `page.astro` (oder `page/index.astro`) zu `page/index.html`.
|
||||||
114
docs/src/pages/de/core-concepts/component-hydration.md
Normal file
114
docs/src/pages/de/core-concepts/component-hydration.md
Normal file
|
|
@ -0,0 +1,114 @@
|
||||||
|
---
|
||||||
|
layout: ~/layouts/MainLayout.astro
|
||||||
|
title: Partial Hydration in Astro
|
||||||
|
description: Lerne wie Partial Hydration unter Verwendung der "Insel-Architektur" in Astro funktioniert.
|
||||||
|
---
|
||||||
|
|
||||||
|
**Astro generiert jede Website standardmäßig mit Null Client-seitigem JavaScript.** Verwende irgendeine Frontend-UI-Bibliothek, die dir gefällt (React, Svelte, Vue etc.), und Astro wird deine Arbeit im Build-Prozess automatisch als HTML rendern und sämtliches JavaScript entfernen. Dies führt dazu, dass jede Seite standardmäßig schnell lädt.
|
||||||
|
|
||||||
|
Doch manchmal wird Client-seitiges JavaScript zwingend benötigt. Diese Anleitung zeigt, wie interaktive Komponenten in Astro funktionieren - unter Verwendung einer Technik die Partial Hydration (Partielle Anreicherung) genannt wird.
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
// Beispiel: Eine React-Komponente importieren und anschließend verwenden.
|
||||||
|
// Standardmäßig rendert Astro die Komponente als HTML und CSS während deines Build
|
||||||
|
// - ohne Client-seitiges JavaScript.
|
||||||
|
// (Du brauchst Client-seitiges JavaScript? Lies weiter...)
|
||||||
|
import MeineReactKomponente from '../components/MeineReactKomponente.jsx';
|
||||||
|
---
|
||||||
|
<!-- 100% HTML, Null JavaScript! -->
|
||||||
|
<MeineReactKomponente />
|
||||||
|
```
|
||||||
|
|
||||||
|
## Konzept: Partial Hydration
|
||||||
|
|
||||||
|
Es gibt viele Fälle in denen du eine interaktive UI-Komponente benötigst, die im Browser ausgeführt wird:
|
||||||
|
|
||||||
|
- Ein Bilder-Karussel
|
||||||
|
- Eine Suche mit Auto-Vervollständigung
|
||||||
|
- Ein Toggle-Button zum Öffnen und Schließen einer Sidebar
|
||||||
|
- Ein "Jetzt kaufen"-Button
|
||||||
|
|
||||||
|
In Astro ist es deine Aufgabe als Entwicklerin oder Entwickler innerhalb einer Seite die Ausführbarkeit von Komponenten im Browser ausdrücklich zu "deklarieren". Astro kann anschließend diese Information verwenden, um herauszufinden welches JavaScript benötigt wird - und die Seite um exakt das anreichern, was benötigt wird. Diese Technik wird als Partial Hydration bezeichnet.
|
||||||
|
|
||||||
|
**Partial Hydration** -- das ausschließliche Anreichern der Komponenten, die JavaScript benötigen, während der Rest der Seite statisches HTML bleibt -- klingt eigentlich sehr einfach - und das sollte es auch sein! Websites wurden über Jahrzehnte so gebaut. Erst in den letzten Jahren erschienen immer mehr so genannte Single-Page-Anwendungen (SPAs), die die Idee ins Spiel brachten, dass deine gesamte Website in JavaScript geschrieben werden und das Ganze schließlich von jeder einzelnen Nutzerin und jedem einzelnen Nutzer im Browser kompiliert und ausgeführt werden könne.
|
||||||
|
|
||||||
|
_Beachte: Partial Hydration (Partielle Anreicherung) wird manchmal auch als “Progressive Enhancement” oder “Progressive Hydration.” bezeichnet. Während durchaus leichte Unterschiede zwischen den Begriffen bestehen, kannst du sie für unsere Zwecke als verschiedene Synonyme des selben Konzeptes betrachten._
|
||||||
|
|
||||||
|
**Partial Hydration ist das Geheimnis hinter der Geschichte von der standardmäßigen Schnelligkeit von Astro.** Next.js, Gatsby und andere JavaScript-Bibliotheken können Partial Hydration nicht unterstützen, da sie deine gesamte Website als eine einzelne JavaScript-Anwendung betrachten.
|
||||||
|
|
||||||
|
## Konzept: Islands Architecture
|
||||||
|
|
||||||
|
**Islands Architecture** ist die Idee Partial Hydration zu verwenden, um komplette Websites zu erzeugen. Islands Architecture ist eine Alternative zu der beliebten Idee deine gesamte Website in eine Client-seitige JavaScript-Anwendung zu packen, welche von den Nutzerinnen und Nutzern heruntergeladen werden muss.
|
||||||
|
|
||||||
|
Um Jason Miller zu zitieren, der [den Begriff aufgebracht hat](https://jasonformat.com/islands-architecture/):
|
||||||
|
|
||||||
|
> In einem Modell aus "Inseln" ist Server-seitiges Rendering nicht die angeflanschte Optimierung, die darauf abzielt die SEO- oder UX-Werte zu verbessern. Stattdessen ist es die grundlegende Methode mit der Seiten an den Browser ausgeliefert werden. Das HTML das als Antwort auf eine Navigation zurückgegeben wird, enthält eine bedeutsame und unmittelbar gerenderte Repräsentation des Inhaltes, den die Nutzerin oder der Nutzer angefordert hat.
|
||||||
|
|
||||||
|
Neben den offensichtlichen Leistungsvorteilen, wenn weniger JavaScript an den Browser geschickt und dort ausgeführt wird, verfügt eine Islands Architecture über zwei wesentliche Vorteile:
|
||||||
|
|
||||||
|
- **Komponenten laden einzeln.** Eine leichtgewichtige Komponente (wie ein Sidebar-Toggle) wird schnell laden und rendern ohne von den schwereren Komponenten auf der Seite blockiert zu werden.
|
||||||
|
- **Komponenten laden isoliert voneinander.** Jeder Teil einer Seite ist eine isolierte Einheit, und ein Leistungsproblem einer Einheit hat keinen direkten Einfluss auf die anderen.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## Interaktive Komponenten anreichern
|
||||||
|
|
||||||
|
Astro rendert jede Komponente auf dem Server **während des Build-Prozesses**, solange nicht [client:only](#mycomponent-clientonly-) verwendet wird. Um Komponenten Client-seitig **während der Laufzeit** anzureichern, kannst du jede der folgenden `client:*`-Direktiven verwenden. Eine Direktive ist das Attribut einer Komponente (getrennt durch einen `:`), das Astro mitteilt, wie deine Komponente gerendert werden sollte.
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
// Beispiel: eine React-Komponente im Browser anreichern.
|
||||||
|
import MeineReactKomponente from '../components/MeineReactKomponente.jsx';
|
||||||
|
---
|
||||||
|
<!-- "client:visible" bedeutet, die Komponente lädt solange kein
|
||||||
|
Client-seitiges JavaScript, bis sie im Browser sichtbar wird. -->
|
||||||
|
<MeineReactKomponente client:visible />
|
||||||
|
```
|
||||||
|
|
||||||
|
### `<MeineKomponente client:load />`
|
||||||
|
|
||||||
|
Reichere die Komponente beim Laden der Seite an.
|
||||||
|
|
||||||
|
### `<MeineKomponente client:idle />`
|
||||||
|
|
||||||
|
Reichere die Komponente an, sobald der Haupt-Thread frei ist (verwendet [requestIdleCallback()][mdn-ric]).
|
||||||
|
|
||||||
|
### `<MeineKomponente client:visible />`
|
||||||
|
|
||||||
|
Reichere die Komponente an, sobald das Element im Viewport der Nutzerin bzw. des Nutzers sichtbar wird (verwendet [IntersectionObserver][mdn-io]). Nützlich für Inhalte weiter unten auf der Seite.
|
||||||
|
|
||||||
|
### `<MeineKomponente client:media={QUERY} />`
|
||||||
|
|
||||||
|
Reichere die Komponente an, wenn der Browser der vorgegebenen Media-Query entspricht (verwendet [matchMedia][mdn-mm]). Nützlich für Sidebar-Toggles oder andere Elemente, die nur auf Mobil- oder nur auf Desktop-Geräten angezeigt werden sollen.
|
||||||
|
|
||||||
|
### `<MeineKomponente client:only />`
|
||||||
|
|
||||||
|
Reichert die Komponente beim Laden der Seite an, ähnlich wie `client:load`. Die Komponente wird während des Build-Prozessses **ausgelassen**, nützlich für Komponenten die vollständig von Client-seitigen API abhängig sind. Diese Direktive sollte am besten vermieden werden, solange sie nicht unbedingt benötigt wird. In den meisten Fällen ist es am besten, Server-seitig Platzhalter-Inhalte zu rendern und etwaige API-Aufrufe im Browser solange zu verzögern, bis die Komponente im Browser angereichert wurde.
|
||||||
|
|
||||||
|
Falls mehr als ein Renderer in der Astro-[Konfiguration](/reference/configuration-reference) angegeben werden, benötigt `client:only` einen Hinweis, um zu wissen, welcher Renderer für die Komponente eingesetzt werden soll. Zum Beispiel würde `client:only="react"` sicherstellen, dass die Komponente im Browser mit dem React-Renderer angereichert wird. Bei eigenen Renderern, die nicht über `@astrojs` bereitgestellt werden, verwende den vollen Namen, so wie er in der Astro-Konfiguration erscheint, z. B. `<client:only="mein-eigener-renderer" />`.
|
||||||
|
|
||||||
|
## Kann ich Astro-Komponenten anreichern?
|
||||||
|
|
||||||
|
[Astro-Komponenten](./astro-components) (`.astro`-Dateien) sind reine HTML-Templating-Komponenten ohne Client-seitige Laufzeit. Wenn du versuchst eine Astro-Komponente über einem `client`-Modifikator anzureichern, wird ein Fehler ausgegeben.
|
||||||
|
|
||||||
|
Um deine Astro-Komponente interaktiv zu machen, musst du sie zu einer Frontend-Bibliothek deiner Wahl konvertieren: React, Svelte, Vue etc. Für den Fall, dass du keine bestimmte Bibliothek bevorzugst, empfehlen wir React oder Preact, da sie am meisten Ähnlichkeit mit Astros Syntax aufweisen.
|
||||||
|
|
||||||
|
Alternativ hierzu könntest du auch ein `<script>`-Tag zu deiner Astro-Komponente hinzufügen und auf diesem Weg JavaScript an den Browser senden. Das kann bei einfachen Funktionen noch ein guter Weg sein, bei komplexeren oder interaktiven Komponenten empfehlen wir eine Frontend-Bibliothek zu verwenden.
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
// Beispiel: Astro mit script-Tags verwenden
|
||||||
|
---
|
||||||
|
<h1>Nicht geklickt</h1>
|
||||||
|
<button>Klicke, um die Überschrift zu ändern</button>
|
||||||
|
<script>
|
||||||
|
document.querySelector("button").addEventListener("click",() => {
|
||||||
|
document.querySelector("h1").innerText = "geklickt"
|
||||||
|
})
|
||||||
|
</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/de/core-concepts/layouts.md
Normal file
155
docs/src/pages/de/core-concepts/layouts.md
Normal file
|
|
@ -0,0 +1,155 @@
|
||||||
|
---
|
||||||
|
layout: ~/layouts/MainLayout.astro
|
||||||
|
title: Layouts
|
||||||
|
description: Eine Einführung in Layouts - eine Art Astro-Komponente, die für gemeinsame Layouts auf verschiedenen Seiten verwendet wird.
|
||||||
|
---
|
||||||
|
|
||||||
|
**Layouts** sind eine besondere Art der [Komponente](/core-concepts/astro-components) - sie können dir helfen gemeinsame Seiten-Layouts über dein Projekt verteilt zu nutzen.
|
||||||
|
|
||||||
|
Layouts verhalten sich so, wie andere mehrfach verwendbare Astro-Komponenten auch. Es gibt keine neue Syntax oder API zu erlernen. Allerdings sind mehrfach verwendbare Layouts ein so weit verbreitetes Modell im Bereich der Web-Entwicklung, dass wir diese Anleitung verfasst haben, um dich bei der Verwendung zu unterstützen.
|
||||||
|
|
||||||
|
## Anwendung
|
||||||
|
|
||||||
|
Astro-Layouts unterstützen Props, Slots und alle anderen Merkmale von Astro-Komponenten. Layouts sind letztendlich einfach normale Komponenten!
|
||||||
|
|
||||||
|
Anders als andere Komponenten enthalten Layouts allerdings oft auch die einfassenden Seitenelemente `<html>`, `<head>` und `<body>` (die so genannte **Page Shell**).
|
||||||
|
|
||||||
|
Es ist ein allgemein übliches Verfahren alle Layout-Komponenten unter einem einzigen `src/layouts`-Verzeichnis anzulegen.
|
||||||
|
|
||||||
|
## Beispiel
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
// src/layouts/BasisLayout.astro
|
||||||
|
const {title} = Astro.props;
|
||||||
|
---
|
||||||
|
<html>
|
||||||
|
<head>
|
||||||
|
<title>Beispiel-Layout: {title}</title>
|
||||||
|
</head>
|
||||||
|
<body>
|
||||||
|
<!-- Fügt jeder Seite eine Navigationsleiste hinzu. -->
|
||||||
|
<nav>
|
||||||
|
<a href="#">Home</a>
|
||||||
|
<a href="#">Posts</a>
|
||||||
|
<a href="#">Kontakt</a>
|
||||||
|
</nav>
|
||||||
|
<!-- slot: Deine Seiteninhalte werden hier eingefügt. -->
|
||||||
|
<slot />
|
||||||
|
</body>
|
||||||
|
</html>
|
||||||
|
```
|
||||||
|
|
||||||
|
📚 Über das `<slot />`-Element lässt sich in Astro definieren, wo untergeordnete Elemente (die an das Layout übergeben werden) erscheinen sollen. Erfahre mehr darüber wie `<slot />` funktioniert in unserer [Anleitung zu Astro-Komponenten](/core-concepts/astro-components).
|
||||||
|
|
||||||
|
Sobald du dein erstes Layout erstellt hast, kannst du es so verwenden, wie du jede andere Komponente in einer Seite verwenden würdest. Denke daran, dass dein Layout den gesamten Seitenaufbau enthält: `<html>`, `<head>`, und `<body>`. Du musst nur den Seiteninhalt hinzufügen.
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
// src/pages/index.astro
|
||||||
|
import BasisLayout from '../layouts/BasisLayout.astro'
|
||||||
|
---
|
||||||
|
<BasisLayout title="Homepage">
|
||||||
|
<h1>Hallo Welt!</h1>
|
||||||
|
<p>Dies ist mein Seiteninhalt, er wird innerhalb eines Layouts ausgegeben.</p>
|
||||||
|
</BasisLayout>
|
||||||
|
```
|
||||||
|
|
||||||
|
## Verschachtelte Layouts
|
||||||
|
|
||||||
|
Du kannst Layouts ineinander verschachteln, wenn du vom Basis-Layout abweichende Layout-Elemente auf einzelnen Seiten einsetzen willst, ohne dabei jedes Mal das gesamte Layout zu wiederholen. Es ist ein übliches Verfahren in Astro ein generisches `BasisLayout` zu verwenden und auf diesem weitere spezifische Layouts (`PostLayout`, `ProduktLayout` etc.) aufzusetzen, die das `BasisLayout` als Grundlage verwenden.
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
// src/layouts/PostLayout.astro
|
||||||
|
import BasisLayout from '../layouts/BasisLayout.astro'
|
||||||
|
const {title, author} = Astro.props;
|
||||||
|
---
|
||||||
|
<!-- Dieses Layout verwendet das Basis-Layout (siehe obiges Beispiel): -->
|
||||||
|
<BasisLayout title={title}>
|
||||||
|
<!-- Fügt neue Post-spezifische Inhalte zu jeder Seite hinzu. -->
|
||||||
|
<div>Post-Autor/Autorin: {author}</div>
|
||||||
|
<!-- slot: Deine Seiteninhalte werden hier eingefügt. -->
|
||||||
|
<slot />
|
||||||
|
</BasisLayout>
|
||||||
|
```
|
||||||
|
|
||||||
|
## Layouts zusammenstellen
|
||||||
|
|
||||||
|
Manchmal benötigst du detailliertere Kontrolle über deine Seiten. Zum Beispiel willst du vielleicht SEO- oder Social-Media-`meta`-Tags auf bestimmten Seiten hinzufügen, auf anderen aber nicht. Das kannst du mit Props in deinem Layout erreichen (`<BasisLayout addMeta={true} ...`) - ab einem bestimmten Punkt ist es möglicherweise jedoch leichter deine Layouts nicht zu verschachteln.
|
||||||
|
|
||||||
|
Anstatt deine gesamte `<html>`-Seite als ein einziges großes Layout zu definieren, kannst du die `head`- und `body`-Inhalte als kleinere, getrennte Komponenten definieren. Hierdurch kannst du verschiedene Layouts auf jeder Seite zusammenstellen.
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
// src/layouts/BasisHead.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">
|
||||||
|
```
|
||||||
|
|
||||||
|
Beachte dass dieses Layout deine **page shell** nicht mit einschließt und nur einige generische Elemente auflistet, die in deinem `<head>`-Block erscheinen sollen. Du hast mehr Kontrolle über die Struktur der einzelnen Seite und kannst mehrere Layout-Komponenten kombinieren.
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
// src/pages/index.astro
|
||||||
|
import BasisHead from '../layouts/BasisHead.astro';
|
||||||
|
import OpenGraphMeta from '../layouts/OpenGraphMeta.astro';
|
||||||
|
---
|
||||||
|
<html>
|
||||||
|
<head>
|
||||||
|
<!-- Nun hast du volle Kontrole über `head` - pro Seite. -->
|
||||||
|
<BasisHead title="Title der Seite" description="Beschreibung der Seite" />
|
||||||
|
<OpenGraphMeta />
|
||||||
|
<!-- Du kannst je nach Bedarf sogar eigene einmalig benötigte Elemente hinzufügen. -->
|
||||||
|
<link rel="alternate" type="application/rss+xml" href="/feed/posts.xml">
|
||||||
|
</head>
|
||||||
|
<body>
|
||||||
|
<!-- ... -->
|
||||||
|
</body>
|
||||||
|
</html>
|
||||||
|
```
|
||||||
|
|
||||||
|
Der Nachteil bei diesem Ansatz ist, dass du die `<html>`-, `<head>`- und `<body>`-Elemente dabei auf jeder Seite definieren musst. Diese werden benötigt, um die Seite vollständig zusammenzustellen, da die Layout-Komponenten nicht mehr die gesamte **Page Shell** beinhalten.
|
||||||
|
|
||||||
|
## Markdown-Layouts
|
||||||
|
|
||||||
|
Für Markdown-Dateien ist ein Layout unerlässlich. Markdown-Dateien können ein bestimmtes Layout im Frontmatter aufrufen. Jede Markdown-Datei wird als HTML gerendert und anschließend an der Stelle in den `<slot />` eingespeist, wo dieser im Layout definiert ist.
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
---
|
||||||
|
title: Blog-Post
|
||||||
|
layout: ../layouts/PostLayout.astro
|
||||||
|
---
|
||||||
|
|
||||||
|
Dieser Blog-Post wird innerhalb des `<PostLayout />`-Layout **gerendert**.
|
||||||
|
```
|
||||||
|
|
||||||
|
Markdown-Seiten übergeben immer eine oder mehrere `content`-Eigenschaften an ihr Layout. Dies ist sehr hilfreich, um Informationen über die Seite, einen Titel, Metadaten, eine Index-Tabelle, Kopfzeilen und anderes für die Seite zur Verfügung zu haben.
|
||||||
|
|
||||||
|
```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: Markdown-Inhalte erscheinen hier! -->
|
||||||
|
<slot />
|
||||||
|
</article>
|
||||||
|
</body>
|
||||||
|
</html>
|
||||||
|
```
|
||||||
|
|
||||||
|
📚 Lerne mehr über die Verwendung von Markdown in Astro in unserer [Markdown-Anleitung](/guides/markdown-content).
|
||||||
58
docs/src/pages/de/core-concepts/project-structure.md
Normal file
58
docs/src/pages/de/core-concepts/project-structure.md
Normal file
|
|
@ -0,0 +1,58 @@
|
||||||
|
---
|
||||||
|
layout: ~/layouts/MainLayout.astro
|
||||||
|
title: Projektstruktur
|
||||||
|
description: Lerne mit Astro ein Projekt zu strukturieren.
|
||||||
|
---
|
||||||
|
|
||||||
|
Astro verwendet eine dogmatische Verzeichnisstruktur für dein Projekt. Jedes Astro-Projekt muss die folgenden Verzeichnisse und Dateien enthalten:
|
||||||
|
|
||||||
|
- `src/*` - Dein Source-Code (Komponenten, Seiten etc.)
|
||||||
|
- `public/*` - Deine Nicht-Code-Assets (Schriften, Icons etc.)
|
||||||
|
- `package.json` - Ein Projekt-Manifest
|
||||||
|
|
||||||
|
Der einfachste Weg dein neues Projekt aufzusetzen, ist mittels `npm init astro`. Lies unsere [Installationsanleitung](/quick-start), um einen vollständigen Überblick darüber zu erhalten, wie ein Projekt automatisch (mit `npm init astro`) oder manuell aufgesetzt werden kann.
|
||||||
|
|
||||||
|
## Projektstruktur
|
||||||
|
|
||||||
|
```
|
||||||
|
├── src/
|
||||||
|
│ ├── components/
|
||||||
|
│ ├── layouts/
|
||||||
|
│ └── pages/
|
||||||
|
│ └── index.astro
|
||||||
|
├── public/
|
||||||
|
└── package.json
|
||||||
|
```
|
||||||
|
|
||||||
|
### `src/`
|
||||||
|
|
||||||
|
Das `src`-Verzeichnis beinhaltet den Großteil des Source-Code zu deinem Projekt. Dazu zählen:
|
||||||
|
|
||||||
|
- [Astro-Komponenten](/core-concepts/astro-components)
|
||||||
|
- [Seiten](/core-concepts/astro-pages)
|
||||||
|
- [Layoute](/core-concepts/layouts)
|
||||||
|
- [Frontend-JS-Komponenten](/core-concepts/component-hydration)
|
||||||
|
- [Styling (CSS, Sass)](/guides/styling)
|
||||||
|
- [Markdown](/guides/markdown-content)
|
||||||
|
|
||||||
|
Astro hat vollständige Kontrolle darüber, wie diese Dateien verarbeitet, optimiert und in deinem abschließenden Website-Build gepackt werden. Einige Dateien (wie Astro-Komponenten) kommen niemals direkt im Browser an - sie werden stattdessen als HTML gerendert und ausgegeben. Andere Dateien (wie CSS) werden an den Browser gesendet, werden möglicherweise aber gepackt - in Abhängigkeit davon, wie deine Site sie einsetzt.
|
||||||
|
|
||||||
|
### `src/components`
|
||||||
|
|
||||||
|
[Komponenten](/core-concepts/astro-components) sind mehrfach verwendbare Einheiten der UI deiner Seiten. Es wird empfohlen (aber dies ist nicht zwingend notwendig), Komponenten in diesem Verzeichnis anzulegen. Wie diese darin strukturiert sind, kannst du frei entscheiden.
|
||||||
|
|
||||||
|
Deine Nicht-Astro-Komponenten (React, Preact, Svelte, Vue etc.) können ebenfalls im `src/components`-Verzeichnis abgelegt werden. Astro wird automatisch alle Komponeneten als HTML rendern, solange du nicht mittels [partieller Anreicherung](/core-concepts/component-hydration) eine bestimmte Frontend-Komponente aktiviert hast.
|
||||||
|
|
||||||
|
### `src/layouts`
|
||||||
|
|
||||||
|
[Layouts](/core-concepts/layouts) sind mehrfach verwendbare Komponenten für die Gestaltung einzelner Seiten. Es wird empfohlen (aber dies ist nicht zwingend notwendig) Layout-Komponenten in diesem Verzeichnis anzulegen. Wie diese darin strukturiert sind, kannst du frei entscheiden.
|
||||||
|
|
||||||
|
### `src/pages`
|
||||||
|
|
||||||
|
[`src/pages`](/core-concepts/astro-pages) enthält alle Seiten (`.astro` und `.md` werden unterstützt) für deine Website. Es ist **zwingend** notwendig, dass du deine Seiten in diesem Verzeichnis anlegst.
|
||||||
|
|
||||||
|
### `public/`
|
||||||
|
|
||||||
|
Bei den meisten Nutzerinnen und Nutzern, wird der Großteil der Dateien innerhalb des `src`-Verzeichnisses liegen, so dass Astro sie in der richtigen Art und Weise während des Build-Prozesses verarbeiten und optimieren kann. Im Gegensatz dazu ist das `public`-Verzeichnis der passende Ort für alle Dateien, die nicht von Astros Build-Prozess abhängig sind.
|
||||||
|
|
||||||
|
Wenn du eine Datei im `public`-Verzeichnis ablegst, wird diese von Astro nicht bearbeitet. Stattdessen wird sie unverändert in das `build`-Verzeichnis kopiert. Dies kann nützlich sein bei Assets von Bildern und Schriften - oder wenn du spezielle Dateien wie `robots.txt` oder `manifest.webmanifest` unverändert im Build verwenden willst.
|
||||||
102
docs/src/pages/de/core-concepts/routing.md
Normal file
102
docs/src/pages/de/core-concepts/routing.md
Normal file
|
|
@ -0,0 +1,102 @@
|
||||||
|
---
|
||||||
|
layout: ~/layouts/MainLayout.astro
|
||||||
|
title: Routing
|
||||||
|
description: Eine Einführung in das Routing mit Astro.
|
||||||
|
---
|
||||||
|
|
||||||
|
Astro verwendet **Datei-basiertes Routing**, um während des Build-Prozesses - entsprechend der Datei-Struktur im `src/pages`-Verzeichnis deines Projekts - die gültigen Routen und URL festzulegen. Wenn eine Datei zum `src/pages`-Verzeichnis deines Projekts hinzugefügt wird, ist sie basierend auf ihrem Dateinmanen automatisch über die entsprechende Route mit der entsprechenden URL erreichbar.
|
||||||
|
|
||||||
|
## Statische Routen
|
||||||
|
|
||||||
|
Astro-Komponenten (`.astro`) und Markdown-Dateien (`.md`) im `src/pages`-Verzeichnis werden zu Seiten deiner Website. Die Route zu jeder Seite wird zusammengesetzt aus den Dateinamen und dem Pfad zu den Dateien innerhalb des `src/pages`-Verzeichnisses. Das bedeutet, dass in einem Astro-Projekt keine separate Routing-Konfiguration verwaltet werden muss.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Beispiel: Statische Routen
|
||||||
|
src/pages/index.astro -> meinesite.com/
|
||||||
|
src/pages/about.astro -> meinesite.com/about
|
||||||
|
src/pages/about/index.astro -> meinesite.com/about
|
||||||
|
src/pages/about/me.astro -> meinesite.com/about/me
|
||||||
|
src/pages/posts/1.md -> meinesite.com/posts/1
|
||||||
|
```
|
||||||
|
|
||||||
|
## Dynamische Routen
|
||||||
|
|
||||||
|
Manchmal musst du zu einer einzelnen Page-Komponente mehrere URLs generieren. Astro verwendet Datei-basiertes Routing, um **dynamische Routing-Parameter** zu unterstützen, so dass eine Seite - basierend auf einem Filter - zu verschiedenen dynamischen Routen passt.
|
||||||
|
|
||||||
|
Es ist wichtig dabei zu beachten, dass Astro statische Seiten generiert. Es gibt keinen Astro-Server, der die Seiten auf Anfrage generiert und ausliefert. Dies bedeutet, dass jede Seite vorab erzeugt werden muss. Seiten die dynamische Routen verwenden, müssen daher eine `getStaticPaths()`-Funktion exportieren, die Astro genau vorgibt, welche Seiten generiert werden müssen. Du erfährst mehr darüber in der vollständigen [API-Referenz](/reference/api-reference#getstaticpaths).
|
||||||
|
|
||||||
|
### Benannte Parameter
|
||||||
|
|
||||||
|
Dynamische Parameter werden im Dateinamen unter Verwendung der `[Klammer]`-Schreibweise kodiert:
|
||||||
|
|
||||||
|
- `pages/blog/[slug].astro` → `/blog/:slug` (`/blog/hallo-welt`, `/blog/post-2` etc.)
|
||||||
|
- `pages/[username]/einstellungen.astro` → (`/fred/einstellungen`, `/drew/einstellungen` etc.)
|
||||||
|
- `pages/[lang]-[version]/info.astro` → (`/en-v1/info`, `/fr-v2/info` etc.)
|
||||||
|
|
||||||
|
#### Beispiel: Benannte Parameter
|
||||||
|
|
||||||
|
Angenommen du hast eine Seite `pages/post/[pid].astro`:
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
// Beispiel: src/pages/post/[pid].astro
|
||||||
|
const {pid} = Astro.request.params;
|
||||||
|
---
|
||||||
|
<p>Post: {pid}</p>
|
||||||
|
```
|
||||||
|
|
||||||
|
Allen Routen mit z. B. `/post/1`, `/post/abc` etc. werden `pages/post/[pid].astro` entsprechen. Jeder passende Pfad-Parameter wird an die Page-Komponente unter `Astro.request.params` weitergegeben.
|
||||||
|
|
||||||
|
Zum Beispiel wird die Route `/post/abc` das folgende `Astro.request.params`-Objekt zur Verfügung halten:
|
||||||
|
|
||||||
|
```json
|
||||||
|
{ "pid": "abc" }
|
||||||
|
```
|
||||||
|
|
||||||
|
Es können mehrere dynamische Routen-Abschnitte kombiniert werden, und sie funktionieren in der gleichen Weise. Die Seite `pages/post/[pid]/[kommentar].astro` wird der Route `/post/abc/ein-kommentar` entsprechen, und ihr `query`-Objekt wird entsprechend lauten:
|
||||||
|
|
||||||
|
```json
|
||||||
|
{ "pid": "abc", "kommentar": "ein-kommentar" }
|
||||||
|
```
|
||||||
|
|
||||||
|
### Rest-Parameter
|
||||||
|
|
||||||
|
Falls du beim URL-Routing mehr Flexibilität benötigst, kannst du den Rest-Parameter als universalen Fänger verwenden. Dies erreichst du, indem du in den eckigen Klammern deinem Parameter drei Punkte (`...`) voranstellst. Zum Beispiel:
|
||||||
|
|
||||||
|
- `pages/post/[...slug].astro` → (`/post/a`, `/post/a/b`, `/post/a/b/c`, etc.)
|
||||||
|
|
||||||
|
Passende Parameter werden als `query`-Parameter (`slug` in diesem Beispiel) an die Seite übergeben. Dem obigen Beispiel folgend heißt das dem Pfad `post/a/b/c` entsprechende `query`-Objekt:
|
||||||
|
|
||||||
|
```json
|
||||||
|
{ "slug": "a/b/c" }
|
||||||
|
```
|
||||||
|
|
||||||
|
Du kannst auch andere Benennungen als `slug` verwenden, z. B.: `[...param]` oder `[...name]`.
|
||||||
|
|
||||||
|
Rest-Parameter sind standardmäßig optional, `pages/post/[...slug]` würde also auch `/post/` entsprechen.
|
||||||
|
|
||||||
|
#### Beispiel: Rest-Parameter
|
||||||
|
|
||||||
|
Für ein `real-world`-Beispiel würdest du den `Github File Viewer` folgendermaßen implementieren:
|
||||||
|
|
||||||
|
```
|
||||||
|
/[org]/[repo]/tree/[branch]/[...file]
|
||||||
|
```
|
||||||
|
|
||||||
|
In diesem Beispiel würde eine Abfrage von `/snowpackjs/astro/tree/main/docs/public/favicon.svg` folgende Parameter für die Seite verfügbar machen:
|
||||||
|
|
||||||
|
```js
|
||||||
|
{
|
||||||
|
org: 'snowpackjs',
|
||||||
|
repo: 'astro',
|
||||||
|
branch: 'main',
|
||||||
|
file: 'docs/public/favicon.svg'
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Warnungen
|
||||||
|
|
||||||
|
- Statische Routen ohne Pfad-Parameter haben stets Vorrang vor allen anderen Routen, und Routen mit benannten Pfad-Parametern haben Vorrang vor Routen mit Rest-Parametern. Schau dir folgende Beispiele an:
|
||||||
|
- `pages/post/create.astro` - wird `/post/create` entsprechen
|
||||||
|
- `pages/post/[pid].astro` - wird `/post/1`, `/post/abc` etc. entsprechen, aber nicht `/post/create`
|
||||||
|
- `pages/post/[...slug].astro` - wird `/post/1/2`, `/post/a/b/c` etc. entsprechen, aber nicht `/post/create`, `/post/abc`
|
||||||
|
|
@ -1,67 +1,75 @@
|
||||||
---
|
---
|
||||||
layout: ~/layouts/MainLayout.astro
|
layout: ~/layouts/MainLayout.astro
|
||||||
title: Einführung
|
title: Einführung
|
||||||
|
description: Eine einfache Einführung in Astro
|
||||||
lang: de
|
lang: de
|
||||||
---
|
---
|
||||||
|
|
||||||
Astro ist ein moderner Generator für statische Webseiten (SSG). Um mehr über Astro zu erfahren, schau Dir [unsere Homepage](https://astro.build/) an, und lies [unseren Release Blogpost](https://astro.build/blog/introducing-astro).
|
Astro ist ein moderner Static-Site-Renderer (auch SSG - Static-Site-Generator). Erfahre worum es bei Astro eigentlich geht auf [unserer Homepage](https://astro.build/), oder lies [unseren Release Blogpost](https://astro.build/blog/introducing-astro).
|
||||||
|
|
||||||
Diese Seite dient als Übersicht der Astro-Dokumentation und alle damit verbundenen Ressourcen.
|
Diese Seite dient als Übersicht für die Astro-Dokumentation und alle damit verbundenen Ressourcen.
|
||||||
|
|
||||||
## Astro ausprobieren
|
## Astro ausprobieren
|
||||||
|
|
||||||
Der einfachste Weg, Astro auszuprobieren, ist `npm init astro` in einem neuen Verzeichnis deiner Wahl auszuführen. Der CLI-Wizard hilft Dir dabei, ein neues Astro-Projekt aufzusetzen.
|
Der einfachste Weg Astro auszuprobieren ist `npm init astro` in einem neuen Verzeichnis auf deinem Rechner auszuführen. Der CLI-Wizard wird dir helfen ein neues Astro-Projekt aufzusetzen.
|
||||||
|
|
||||||
Um mit Astro in fünf einfachen Schritten loszulegen, lies [unsere Schnellstart Anleitung](/de/quick-start).
|
Um in fünf einfachen Schritten mit Astro loszulegen, lies [unsere Schnellstart-Anleitung](/de/quick-start).
|
||||||
|
|
||||||
Alternativ kannst Du unsere [Installations Anleitung](/de/installation) für eine ausführliche Beschreibung des Installationsprozesses lesen.
|
Alternativ kannst du unsere [Installationsanleitung](/de/installation) lesen, um eine ausführlichere Schritt-für-Schritt-Anleitung zu erhalten.
|
||||||
|
|
||||||
### Online-Spielplätze
|
### Beispiel-Projekte
|
||||||
|
|
||||||
Falls Du lieber erst einmal mit Astro in Deinem Browser herumspielen willst, kannst Du einen Online-Code-Spielplatz benutzen. Probiere unsere »Hello World«-Vorlage auf [CodeSandbox](https://codesandbox.io/s/astro-template-hugb3).
|
Falls du Astro lieber anhand von Beispielen kennenlernen möchtest, sieh dir unsere [vollständige Beispiel-Bibliothek](https://github.com/snowpackjs/astro/tree/main/examples) auf GitHub an.
|
||||||
|
|
||||||
_Hinweis: Einige Funktionen (z.B. Fast Refresh) funktionieren aktuell nur begrenzt auf CodeSandbox._
|
Du kanst jedes dieser Beispiele lokal auf deinem Rechner ausprobieren, indem du `npm init astro` mit der CLI-Kennzeichnung `--template` im Terminal aufrufst. Die Kennzeichnung `--template` unterstützt auch externe Vorlagen und Vorlagen der Community.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Rufe den Wizard zur Initialisierung auf und verwende diese offizielle Vorlage
|
||||||
|
npm init astro -- --template [OFFIZIELLES_BEISPIEL_NAME]
|
||||||
|
# Rufe den Wizard zur Initialisierung auf und verwende diese Community-Vorlage
|
||||||
|
npm init astro -- --template [GITHUB_NAME]/[REPO_NAME]
|
||||||
|
npm init astro -- --template [GITHUB_NAME]/[REPO_NAME]/pfad/zur/vorlage
|
||||||
|
```
|
||||||
|
|
||||||
|
### Online-Playgrounds
|
||||||
|
|
||||||
|
Falls du Astro gerne in deinem Browser ausprobieren willst, kannst du einen Online-Code-Editor wie z. B. Stackblitz, CodeSandbox, Gitpod oder GitHub Codespaces verwenden. Nutze den "Open in Stackblitz"-Link zu einem beliebigen Besipiel aus unserer [Beispiel-Bibliothek](https://github.com/snowpackjs/astro/tree/main/examples), oder [klicke hier](https://stackblitz.com/fork/astro), um ein neues Projekt in [Stackblitz](https://stackblitz.com/fork/astro) aufzusetzen.
|
||||||
|
|
||||||
## Astro lernen
|
## Astro lernen
|
||||||
|
|
||||||
Es kommen eine Menge verschiedener Menschen mit unterschiedlichen Hintergründen und anderen Lernweisen zu Astro. Unabhängig davon, ob Du lieber theoretisch oder praktisch lernst, hoffen wir, dass Dir dieser Abschnitt weiterhilft.
|
Verschiedene Menschen mit unterschiedlichen Hintergründen und unterschiedlichen Lernansätzen kommen zu Astro. Gleichgültig ob du einen theoretischen oder einen praktischen Ansatz bevorzugst, wir hoffen, dass dieser Abschnitt hilfreich für dich ist.
|
||||||
|
|
||||||
- Falls Du lieber **praktisch lernst**, suche Dir ein Beispiel aus unserer [Beispiel Liste](https://github.com/withastro/astro/tree/main/examples) aus und fange direkt an.
|
- Falls du **praktisches Lernen** bevorzugst, starte direkt mit ein Beispiel aus unserer [Beispiel-Liste](https://github.com/snowpackjs/astro/tree/main/examples).
|
||||||
|
- Falls du bevorzugst **Schritt für Schritt zu lernen**, starte mit unseren [grundlegenden Konzepten und Anleitungen](/core-concepts/project-structure).
|
||||||
|
|
||||||
- Falls Du lieber **theoretisch lernst**, kannst Du mit unseren [grundlegenden Konzepten und Anleitungen](/core-concepts/project-structure) beginnen.
|
Wie jede unbekannte Technik, bringt Astro eine gewisse Lernkurve mit sich. Wir sind jedoch sicher, dass du mit ein bisschen Übung und Geduld schnell lernen _wirst_, wie Astro funktioniert.
|
||||||
|
|
||||||
Wie alle unbekannten Technologien, hat auch Astro eine leichte Lernkurve. Mit ein bisschen Übung und Geduld, sind wir aber _sicher_, dass Du schnell lernst, wie Du mit Astro umgehen kannst.
|
|
||||||
|
|
||||||
### Lerne die `.astro`-Syntax
|
### Lerne die `.astro`-Syntax
|
||||||
|
|
||||||
When du mit Astro anfängst, wirst Du schnell Dateien mit der Dateiendung `.astro` finden. Das ist die **Astro-Komponenten-Syntax**: ein spezielles, HTML-ähnliches Dateiformat, welches Astro für Vorlagen benutzt. Es wurde angelehnt an HTML und JSX entworfen und sollte jedem, der damit Erfahrung hat, direkt bekannt vorkommen.
|
Wenn du anfängst mit Astro zu arbeiten, wirst du viele Dateien mit der Dateiendung `.astro` sehen. Das ist **Astros Komponenten-Syntax**: ein spezielles, HTML-ähnliches Dateiformat, welches Astro für Vorlagen benutzt. Es wurde in Anlehnung an HTML und JSX entworfen und sollte allen, die mit diesen Formaten Erfahrung haben, bekannt vorkommen.
|
||||||
|
|
||||||
Unsere Anleitung zu [Astro-Komponenten](/core-concepts/astro-components) sollte eine gute Einführung in die Astro-Syntax sein und ist der beste Weg, um diese zu lernen.
|
Unsere unterstützende Anleitung zu [Astro-Komponenten](/core-concepts/astro-components) ist eine gute Einführung in die Astro-Syntax - und der beste Weg sie zu lernen.
|
||||||
|
|
||||||
### API Dokumentation
|
### API-Referenz
|
||||||
|
|
||||||
Dieser Dokumentationsabschnitt sollte für Dich nützlich sein, wenn Du mehr Details über eine bestimme Astro-API erfahren möchtest.
|
Dieser Abschnitt der Dokumentation ist nützlich, wenn du weitere Details zu einer bestimmen Astro-API erhalten möchtest. Zum Besipiel listet die [Referenz zur Konfiguration](/reference/configuration-reference) alle möglichen Konfigurationseigenschaften auf, die dir zur Verfügung stehen. Die [Referenz zu integrierten Komponenten](/reference/builtin-components) listet alle verfügbaren Kernkomponenten wie z. B. `<Markdown />` und `<Code />` auf.
|
||||||
|
|
||||||
So listet z.B. die [Konfigurationsdokumentation](/reference/configuration-reference) alle möglichen Konfigurationseigenschaften auf, die Dir zur Verfügung stehen. In der [Dokumentation über eingebaute Komponenten](/reference/builtin-components) findest Du alle verfügbaren Kernkomponenten wie `<Markdown />` und `<Code />`.
|
### Versionsdokumentation
|
||||||
|
|
||||||
### Versionierte Dokumentation
|
Diese Dokumentation ist immer auf dem Stand der letzten _stabilen_ Version von Astro. Sobald wir den v1.0-Meilenstein erreicht haben, werden wir auch die Möglichkeit anbieten eine versionsspezifische Dokumentation einzusehen.
|
||||||
|
|
||||||
Diese Dokumentation ist immer auf dem Stand der letzten _stable_ Version von Astro. Sobald wir den Meilenstein der Version v1.0 erreicht haben, wollen wir versionierte Dokumentation einführen.
|
## Auf dem Laufenden bleiben
|
||||||
|
|
||||||
## Bleib auf dem Laufenden
|
Der [@astrodotbuild](https://twitter.com/astrodotbuild) Twitter-Account ist die offizielle Quelle für Ankündigungen vom Astro-Team.
|
||||||
|
|
||||||
Unser [@astrodotbuild](https://twitter.com/astrodotbuild) Twitter-Account ist die offizielle Quelle für Neuigkeiten vom Astro-Team.
|
Zusätzlich veröffentlichen wir alle Ankündigungen in unserer [Discord-Community](https://astro.build/chat) im `#announcements`-Channel.
|
||||||
|
|
||||||
Zusätzlich veröffentlichen wir alle Release-Ankündigungen in unserer [Discord Community](https://astro.build/chat) im `#announcements`-Kanal.
|
Nicht jedes Astro-Release verdient einen eigenen Blogpost, aber du kannst ein detailliertes Log aller Änderungen für jedes Release im [`CHANGELOG.md` des Astro Repository](https://github.com/snowpackjs/astro/blob/main/packages/astro/CHANGELOG.md) nachlesen.
|
||||||
|
|
||||||
Auch wenn nicht jedes Astro-Release einen eigenen Blogpost verdient, kannst Du alle Änderungen für jedes Release in unserem detaillierten [`CHANGELOG.md` im Astro Repository](https://github.com/withastro/astro/blob/main/packages/astro/CHANGELOG.md) nachlesen.
|
|
||||||
|
|
||||||
## Fehlt etwas?
|
## Fehlt etwas?
|
||||||
|
|
||||||
Falls Dir etwas in der Dokumentation fehlt, oder Du einen Teil verwirrend findest, [erstell bitte ein Issue](https://github.com/withastro/astro/issues/new/choose) mit deinen Verbesserungsvorschlägen für die Dokumentation oder tweete an den [@astrodotbuild](https://twitter.com/astrodotbuild) Twitter-Account.
|
Falls etwas in der Dokumentation fehlt, oder falls du einen bestimmten Teil verwirrend findest, [erstelle bitte ein Issue](https://github.com/snowpackjs/astro/issues/new/choose) mit deinen Verbesserungsvorschlägen oder tweete an den [@astrodotbuild](https://twitter.com/astrodotbuild) Twitter-Account. Wir freuen uns, von dir zu hören!
|
||||||
|
|
||||||
Wir freuen uns, von Dir zu hören.
|
|
||||||
|
|
||||||
## Credit
|
## Credit
|
||||||
|
|
||||||
Diese Einführung basierte ursprünglich auf der Einführung von [React](https://reactjs.org/).
|
Diese Einführung basierte ursprünglich auf der Einführung zu [React](https://reactjs.org/).
|
||||||
|
|
|
||||||
|
|
@ -4,19 +4,19 @@ title: Installation
|
||||||
description: So installierst du Astro mit NPM, PNPM oder Yarn.
|
description: So installierst du Astro mit NPM, PNPM oder Yarn.
|
||||||
---
|
---
|
||||||
|
|
||||||
Es gibt verschiedene Möglichkeiten, Astro in einem neuen Projekt zu installieren.
|
Es gibt verschiedene Möglichkeiten Astro in einem neuen Projekt zu installieren.
|
||||||
|
|
||||||
## Voraussetzungen
|
## Vorbereitungen
|
||||||
|
|
||||||
- **Node.js** - `v12.20.0`, `v14.13.1`, `v16.0.0`, or höher.
|
- **Node.js** - `v12.20.0`, `v14.13.1`, `v16.0.0` oder höher
|
||||||
- **Texteditor** - Wir empfehlen [VS Code](https://code.visualstudio.com/) mit unserer [Offiziellen Astro Erweiterung](https://marketplace.visualstudio.com/items?itemName=astro-build.astro-vscode).
|
- **Texteditor** - Wir empfehlen [VS Code](https://code.visualstudio.com/) mit unserer [offiziellen Astro-Erweiterung](https://marketplace.visualstudio.com/items?itemName=astro-build.astro-vscode)
|
||||||
- **Terminal** - Auf Astro wird hauptsächlich über die Befehlszeile des Terminals zugegriffen.
|
- **Terminal** - Astro wird im Wesentlichen über die Befehlszeile des Terminals gesteuert
|
||||||
|
|
||||||
Zu Demonstrationszwecken verwenden wir in den folgenden Beispielen [`npm`](https://www.npmjs.com/), aber du kannst auch [`yarn`](https://yarnpkg.com/) oder [`pnpm`](https://pnpm.io/) verwenden, wenn du eine npm-alternative bevorzugst.
|
Zu Demonstrationszwecken verwenden wir in den folgenden Beispielen [`npm`](https://www.npmjs.com/), aber du kannst ebenso [`yarn`](https://yarnpkg.com/) oder [`pnpm`](https://pnpm.io/) verwenden, falls du eine npm-Alternative bevorzugst.
|
||||||
|
|
||||||
## Projekt mit Astro erzeugen
|
## Astro-Projekt erzeugen
|
||||||
|
|
||||||
`npm init astro` ist der einfachste Weg, Astro in einem neuen Projekt zu installieren. Führe den Befehl in deinem Terminal aus, um unseren `create-astro`-Installationsassistenten zu starten, der dir bei der Einrichtung eines neuen Projekts hilft.
|
`npm init astro` ist der einfachste Weg in einem neuen Projekt Astro zu installieren. Führe diesen Befehl in deinem Terminal aus, um unseren `create-astro`-Installationsassistenten zu starten, der dich bei der Einrichtung eines neuen Projekts unterstützt.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
# Mit NPM
|
# Mit NPM
|
||||||
|
|
@ -29,65 +29,65 @@ yarn create astro
|
||||||
pnpm create astro
|
pnpm create astro
|
||||||
```
|
```
|
||||||
|
|
||||||
Mit dem [`create-astro`](https://github.com/withastro/astro/tree/main/packages/create-astro) Assistenten kannst du aus einer Reihe von [Starter-Vorlagen](https://github.com/withastro/astro/tree/main/examples) wählen. Alternativ kannst du auch dein eigenes Astro-Projekt direkt von GitHub importieren.
|
Der [`create-astro`](https://github.com/snowpackjs/astro/tree/main/packages/create-astro)-Assistent lässt dich aus einer Reihe von [Start-Vorlagen](https://github.com/snowpackjs/astro/tree/main/examples) auswählen. Alternativ könntest du auch dein eigenes Astro-Projekt direkt aus GitHub heraus importieren.
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
# Hinweis: Ersetze "my-astro-project" durch den Namen deines Projekts.
|
# Hinweis: Ersetze "mein-astro-projekt" durch den Namen deines Projekts.
|
||||||
|
|
||||||
# npm 6.x
|
# npm 6.x
|
||||||
npm init astro my-astro-project --template starter
|
npm init astro mein-astro-projekt --template starter
|
||||||
# npm 7+ (zusätzliche Bindestriche sind erforderlich)
|
# npm 7+ (zusätzliche Bindestriche sind erforderlich)
|
||||||
npm init astro my-astro-project -- --template starter
|
npm init astro mein-astro-projekt -- --template starter
|
||||||
# yarn
|
# yarn
|
||||||
yarn create astro my-astro-project --template starter
|
yarn create astro mein-astro-projekt --template starter
|
||||||
# pnpm
|
# pnpm
|
||||||
pnpm create astro my-astro-project -- --template starter
|
pnpm create astro mein-astro-projekt -- --template starter
|
||||||
# Verwenden einer Drittanbietervorlage
|
# Verwenden einer Drittanbietervorlage
|
||||||
npm init astro my-astro-project -- --template [GITHUB_USER]/[REPO_NAME]
|
npm init astro mein-astro-projekt -- --template [GITHUB_NAME]/[REPO_NAME]
|
||||||
# Verwenden einer Drittanbietervorlage innerhalb eines repos
|
# Verwenden einer Drittanbietervorlage innerhalb eines Repos
|
||||||
npm init astro my-astro-project -- --template [GITHUB_USER]/[REPO_NAME]/path/to/template
|
npm init astro mein-astro-projekt -- --template [GITHUB_NAME]/[REPO_NAME]/pfad/zur/vorlage
|
||||||
```
|
```
|
||||||
|
|
||||||
Nachdem `create-astro` dein Projekt vorbereitet hat, denke daran, die Projektabhängigkeiten mit npm oder dem Paketmanager deiner Wahl zu installieren. In diesem Beispiel verwenden wir npm:
|
Nachdem `create-astro` dein Projekt eingerichtet hat, denke daran die Abhängigkeiten deines Projekts mittels npm oder dem Paketmanager deiner Wahl zu installieren. In diesem Beispiel verwenden wir npm:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
npm install
|
npm install
|
||||||
```
|
```
|
||||||
|
|
||||||
Du kannst dein Astro-Projekt nun [Starten](#start-astro). Nachdem du dein Astro-Projekt fertiggestellt hast, kannst du dein Projekt [Bauen](#build-astro). Astro wird dann die statischen Seiten generieren und für dich bereitstellen, welche du anschließend bei deinem bevorzugten Hosting-Anbieter [Ausrollen](/guides/deploy) kannst.
|
Du kannst dein Astro-Projekt nun [starten](#start-astro). Sobald du dein Astro-Projekt fertiggestellt hast, kannst du dein Projekt [kompilieren](#build-astro). Astro wird dann deine Anwendung fertig packen und dafür die statischen Seiten generieren, die du bei deinem bevorzugten Hosting-Anbieter [veröffentlichen](/guides/deploy) kannst.
|
||||||
|
|
||||||
## Manuelle Installation
|
## Manuelle Installation
|
||||||
|
|
||||||
Du kannst Astro auch ohne die Hilfe des `create-astro` Assistenten einrichten. Nachfolgend sind die wenigen zusätzlichen Schritte aufgeführt, die erforderlich sind, um Astro zum Laufen zu bringen.
|
Du kannst Astro auch ohne die Hilfe des `create-astro`-Assistenten einrichten. Nachfolgend findest du die wenigen zusätzlichen Schritte, die erforderlich sind, um Astro zum Laufen zu bringen.
|
||||||
|
|
||||||
### Dein Projekt aufsetzen
|
### Setze dein Projekt auf
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
# Verzeichnis erzeugen und hinein wechseln
|
# Verzeichnis erzeugen und in das Verzeichnis wechseln
|
||||||
mkdir my-astro-project
|
mkdir mein-astro-projekt
|
||||||
cd my-astro-project
|
cd mein-astro-projekt
|
||||||
```
|
```
|
||||||
|
|
||||||
Erstelle ein leeres Verzeichnis mit dem Namen deines Projekts und navigiere dann in dieses:
|
Erstelle ein leeres Verzeichnis mit dem Namen deines Projekts und navigiere dann dorthin.
|
||||||
|
|
||||||
### `package.json` erzeugen
|
### Erzeuge `package.json`
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
# Dieser Befehl erstellt eine grundlegende package.json Datei für dich
|
# Dieser Befehl erstellt eine grundlegende package.json-Datei für dich
|
||||||
npm init --yes
|
npm init --yes
|
||||||
```
|
```
|
||||||
|
|
||||||
Astro wurde entwickelt, um mit dem gesamten npm-Paket-Ökosystem zu arbeiten. Dies wird durch ein Projektmanifest im Stammverzeichnis Ihres Projekts verwaltet, das als `package.json` bekannt ist. Wenn du mit der Datei `package.json` nicht vertraut bist, empfehlen wir dir dringend, dich ein wenig einzulesen [npm-Dokumentation] (https://docs.npmjs.com/creating-a-package-json-file).
|
Astro ist darauf ausgerichtet mit dem gesamten npm-Paket-Ökosystem zu arbeiten. Diese Arbeit wird durch ein Projektmanifest im Stammverzeichnis deines Projekts verwaltet, das als `package.json` bekannt ist. Für den Fall, dass du mit der `package.json`-Datei nicht vertraut bist, empfehlen wir dir dich kurz dazu in der [npm-Dokumentation] (https://docs.npmjs.com/creating-a-package-json-file) einzulesen.
|
||||||
|
|
||||||
### Astro installieren
|
### Installiere Astro
|
||||||
|
|
||||||
Wenn du die obigen Anweisungen ausgeführt hast, solltest du ein Verzeichnis mit einer einzelnen `package.json` Datei darin haben. Du kannst Astro jetzt in deinem Projekt einrichten.
|
Soweit du den obigen Anweisungen gefolgt bist, solltest du ein Verzeichnis mit einer einzelnen `package.json`-Datei darin haben. Du kannst Astro jetzt in deinem Projekt aufsetzen.
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
npm install astro
|
npm install astro
|
||||||
```
|
```
|
||||||
|
|
||||||
Du kannst jetzt den Platzhalter-Abschnitt "scripts" deiner `package.json` Datei, welche durch `npm init` für dich erstellt wurde, durch Folgendes ersetzen:
|
Jetzt kannst du den Platzhalter im Abschnitt "scripts" deiner `package.json`-Datei, die `npm init` für dich erstellt hat, durch Folgendes ersetzen:
|
||||||
|
|
||||||
```diff
|
```diff
|
||||||
"scripts": {
|
"scripts": {
|
||||||
|
|
@ -99,19 +99,20 @@ Du kannst jetzt den Platzhalter-Abschnitt "scripts" deiner `package.json` Datei,
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
Der Befehl [`dev`](#start-astro) startet den Astro Entwicklungs Server auf `http://localhost:3000`. Sobald dein Projekt fertig ist, generiert der Befehl [`build`](#build-astro) dein fertiges Projekt in das Verzeichnis `dist/`. [Lese mehr über das Veröffentlichen im Deployment Leitfaden.](/guides/deploy)
|
Der Befehl [`dev`](#start-astro) startet den Astro Entwicklungsserver auf `http://localhost:3000`. Sobald dein Projekt fertig ist, gibt der Befehl [`build`](#build-astro) dein Projekt in das Verzeichnis `dist/` aus. [Lese mehr über das Veröffentlichen von Astro-Builds](/guides/deploy).
|
||||||
|
|
||||||
### Erstelle deine erste Seite
|
### Erstelle deine erste Seite
|
||||||
|
|
||||||
Öffne deinen bevorzugten Texteditor und erstelle eine neue Datei in deinem Projekt:
|
Öffne deinen bevorzugten Texteditor und erstelle eine neue Datei in deinem Projekt:
|
||||||
|
|
||||||
1. Erstelle eine neue Datei unter `src/pages/index.astro`
|
1. Erstelle eine neue Datei unter `src/pages/index.astro`.
|
||||||
2. Kopiere den folgenden Code-Schnipsel (einschließlich der Bindestriche `---`) und füge ihn ein.
|
2. Kopiere den folgenden Code-Schnipsel (einschließlich der Bindestriche `---`) und füge ihn ein.
|
||||||
|
|
||||||
```astro
|
```astro
|
||||||
---
|
---
|
||||||
// JavaScript/TypeScript-Code, der zwischen den (---) Bindestrichen geschrieben wurde, wird ausschließlich auf dem Server ausgeführt!
|
// JS/TS-Code, der zwischen den (---) Bindestrichen geschrieben wurde,
|
||||||
console.log('Sieh mich mich im Terminal ')
|
// wird ausschließlich auf dem Server ausgeführt!
|
||||||
|
console.log('Du siehst mich im Terminal')
|
||||||
---
|
---
|
||||||
|
|
||||||
<html>
|
<html>
|
||||||
|
|
@ -129,24 +130,24 @@ console.log('Sieh mich mich im Terminal ')
|
||||||
</style>
|
</style>
|
||||||
|
|
||||||
<script>
|
<script>
|
||||||
// Hier eingegebener JS-Code wird vollständig im Browser ausgeführt
|
// Hier eingegebener JS-Code wird ausschließlich im Browser ausgeführt
|
||||||
console.log('Sieh mich in den devTools')
|
console.log('Du siehst mich in den devTools')
|
||||||
</script>
|
</script>
|
||||||
```
|
```
|
||||||
|
|
||||||
Oben ist ein Beispiel für die Syntax von Astro-Komponenten, die sowohl HTML als auch JSX umfasst.
|
Das Obige ist ein Beispiel für Astros Komponenten-Syntax, die sowohl HTML als auch JSX umfasst.
|
||||||
|
|
||||||
Du kannst weitere Seiten im Verzeichnis `src/pages` erstellen - Astro verwendet den Dateinamen, um neue Seiten auf deiner Seite zu erstellen. Durch das Erstellen einer neuen Datei unter `src/pages/about.astro` (der voherige Code-Schnipsel kann wiedervewendet werden) generiert Astro beispielsweise eine neue Seite unter der URL: `http://localhost/about`
|
Du kannst weitere Seiten im Verzeichnis `src/pages` erstellen - Astro verwendet den Dateinamen, um neue Seiten für deine Site zu erzeugen. Zum Beispiel wird Astro durch das Erzeugen einer neuen Datei unter `src/pages/about.astro` (auch unter Wiederverwendung des Code-Schnipsels) eine neue Seite unter der URL `http://localhost/about` generieren.
|
||||||
|
|
||||||
## [Astro starten](#start-astro)
|
## [Starte Astro](#start-astro)
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
npm run dev
|
npm run dev
|
||||||
```
|
```
|
||||||
|
|
||||||
Astro stellt nun deine Anwendung auf `http://localhost:3000` bereit. Wenn du diese URL in deinem Browser öffnest, solltest du das „Hello, World“ von Astro sehen.
|
Astro wird von nun an deine Anwendung unter `http://localhost:3000` bereitstellen. Wenn du diese URL in deinem Browser öffnest, solltest du Astros "Hello, World" sehen.
|
||||||
|
|
||||||
Wenn Du deinen Entwicklungsfortschritt im lokalen Netzwerk teilst oder die App von einem Telefon aus testen möchtest, füge einfach die folgende Option [snowpack](https://www.snowpack.dev/reference/configuration#devoptionshostname) zu `astro.config.mjs`:
|
Falls du deinen Entwicklungsfortschritt im lokalen Netzwerk teilen oder die Anwendung von einem Telefon aus testen möchtest, füge einfach die folgende [snowpack](https://www.snowpack.dev/reference/configuration#devoptionshostname)-Option in `astro.config.mjs` hinzu:
|
||||||
|
|
||||||
```js
|
```js
|
||||||
devOptions: {
|
devOptions: {
|
||||||
|
|
@ -154,22 +155,24 @@ devOptions: {
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
## [Astro bauen](#build-astro)
|
## [Kompiliere dein Projekt](#build-astro)
|
||||||
|
|
||||||
|
Führe in deinem Projektverzeichnis den folgenden Befehl im Terminal aus:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
npm run build
|
npm run build
|
||||||
```
|
```
|
||||||
|
|
||||||
Dadurch wird Astro angewiesen, deine Seite zu erstellen und direkt auf der Festplatte zu speichern. Deine Anwendung steht nun im Verzeichnis `dist/` bereit.
|
Dies weist Astro an deine Site zu erstellen und direkt zu speichern. Deine Anwendung steht nun im `dist/`-Verzeichnis bereit.
|
||||||
|
|
||||||
## Nächste Schritte
|
## Nächste Schritte
|
||||||
|
|
||||||
Erfolg! Du kannst jetzt mit der Entwicklung beginnen!
|
Geschafft! Du kannst jetzt mit dem Entwickeln beginnen!
|
||||||
|
|
||||||
Wir empfehlen dir dringend, dich mit der Funktionsweise von Astro vertraut zu machen. Du kannst dies tun, indem du unsere Dokumentation weiter erkundest. Wir empfehlen dir insbesondere folgende weiterführende Informationen:
|
Wir möchten dich ermutigen, dir etwas Zeit zu nehmen, um mit der Art und Weise vertraut zu werden, wie Astro funktioniert. Am besten befasst du dich weitergehend mit der Dokumentation. Hier ein paar Empfehlungen:
|
||||||
|
|
||||||
📚 Erfahre mehr über die Projektstruktur von Astro in unserem [Leitfaden zur Projektstruktur.](/core-concepts/project-structure)
|
📚 Lerne mehr über Astros Projektstruktur in unserer [Anleitung zur Projektstruktur](/core-concepts/project-structure)
|
||||||
|
|
||||||
📚 Erfahre mehr über die Komponentensyntax von Astro in unserem [Leitfaden zu Astro Components.](/core-concepts/astro-components)
|
📚 Lerne mehr über Astros Komponenten-Syntax in unserer [Astro-Komponenten-Anleitung](/core-concepts/astro-components)
|
||||||
|
|
||||||
📚 Erfahre mehr über das dateibasierte Routing von Astro in unserem [Routing-Leitfaden.](core-concepts/astro-pages)
|
📚 Lerne mehr über Astros dateibasiertes Routing in unserer [Routing-Anleitung](core-concepts/astro-pages)
|
||||||
|
|
|
||||||
229
docs/src/pages/de/migration/0.21.0.md
Normal file
229
docs/src/pages/de/migration/0.21.0.md
Normal file
|
|
@ -0,0 +1,229 @@
|
||||||
|
---
|
||||||
|
layout: ~/layouts/MainLayout.astro
|
||||||
|
title: Umstellung auf v0.21
|
||||||
|
description: Projekte von Astro v0.20 umziehen.
|
||||||
|
---
|
||||||
|
|
||||||
|
## Vite
|
||||||
|
|
||||||
|
Beginnend mit v0.21 werden Astro-Builds mittels [Vite](https://vitejs.dev) kompiliert.
|
||||||
|
Bedingt hierdurch sollten Konfigurationen, die in `snowpack.config.mjs` geschrieben wurden, nach `astro.config.mjs` transferiert werden.
|
||||||
|
|
||||||
|
```js
|
||||||
|
// @ts-check
|
||||||
|
|
||||||
|
/** @type {import('astro').AstroUserConfig} */
|
||||||
|
export default {
|
||||||
|
renderers: [],
|
||||||
|
vite: {
|
||||||
|
plugins: [],
|
||||||
|
},
|
||||||
|
};
|
||||||
|
```
|
||||||
|
|
||||||
|
Um mehr über die Konfiguration von Vite zu erfahren, lies bitte den [Vite Configuration Guide](https://vitejs.dev/config).
|
||||||
|
|
||||||
|
## Aliasierung
|
||||||
|
|
||||||
|
In Astro v0.21 können Aliase in `tsconfig.json` oder `jsconfig.json` hinzugefügt werden, um sie bei der Verwendung von _import_ einzusetzen.
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"compilerOptions": {
|
||||||
|
"baseUrl": ".",
|
||||||
|
"paths": {
|
||||||
|
"@/components/*": ["components/*"]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
_Diese Aliase werden automatisch in die Konfiguration von [VSCode](https://code.visualstudio.com/docs/languages/jsconfig) und anderen Editoren übernommen._
|
||||||
|
|
||||||
|
## Variablen in \<script> & \<style>
|
||||||
|
|
||||||
|
In Astro v0.21 können _serialisierbare_ Server-seitige Variablen innerhalb Client-seitiger `<style>`- oder `<script>`-Tags übergeben werden.
|
||||||
|
|
||||||
|
```astro
|
||||||
|
---
|
||||||
|
// tick.astro
|
||||||
|
const foregroundColor = "rgb(221 243 228)";
|
||||||
|
const backgroundColor = "rgb(24 121 78)";
|
||||||
|
---
|
||||||
|
<style define:vars={{foregroundColor, backgroundColor}}>
|
||||||
|
h-tick {
|
||||||
|
background-color: var(--backgroundColor);
|
||||||
|
border-radius: 50%;
|
||||||
|
color: var(--foregroundColor);
|
||||||
|
height: 15px;
|
||||||
|
width: 15px;
|
||||||
|
}
|
||||||
|
</style>
|
||||||
|
<h-tick>✓</h-tick>
|
||||||
|
```
|
||||||
|
|
||||||
|
## Komponenten in Markdown
|
||||||
|
|
||||||
|
In Astro v0.21 können Komponenten aus beliebigen Frameworks in Markdown-Dateien verwendet werden.
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
---
|
||||||
|
Layout: '...'
|
||||||
|
setup: |
|
||||||
|
import MeineReactKomponente from '../components/MeineReactKomponente.jsx'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Partial Hydration wenn sichtbar
|
||||||
|
|
||||||
|
<MeineReactKomponente client:visible>
|
||||||
|
|
||||||
|
# Hallo Welt!
|
||||||
|
|
||||||
|
</MeineReactKomponente>
|
||||||
|
```
|
||||||
|
|
||||||
|
## Komponenten in Titeln(Frontmatter)
|
||||||
|
|
||||||
|
Bisher ließen sich Astro-Komponenten innerhalb des Astro-Frontmatter erzeugen, indem dort JSX-Syntax anstelle der Astro-Syntax verwendet wurde. Mit dem neuen Compiler ist das nicht mehr möglich. Wir hoffen, dass wir diese Möglichkeit in einer zukünftigen Version von Astro wieder einführen können - in der wir hierfür jedoch eine andere API an Stelle der JSX-API verwenden werden.
|
||||||
|
|
||||||
|
Um auf v0.21 umzustellen, konvertiere bitte alle JSX-Astro-Komponenten (dies sind alle Astro-Komponenten, die innerhalb des Frontmatter einer anderen Komponente erzeugt werden) in eigenständige Komponenten.
|
||||||
|
|
||||||
|
## Umgebungsvariablen
|
||||||
|
|
||||||
|
In Astro v21.0 können Umgebungsvariablen aus .env-Dateien in deinem Projektverzeichnis geladen werden.
|
||||||
|
|
||||||
|
```ini
|
||||||
|
.env # wird in allen Fällen geladen
|
||||||
|
.env.local # wird in allen Fällen geladen, ignoriert von git
|
||||||
|
.env.[mode] # wird nur im spezifizierten Modus geladen
|
||||||
|
.env.[mode].local # wird nur im spezifizierten Modus geladen, ignoriert von git
|
||||||
|
```
|
||||||
|
|
||||||
|
Aus Sicherheitsgründen sind ausschließlich Variablen mit dem Prefix `PUBLIC_` für deinen Code verfügbar.
|
||||||
|
|
||||||
|
```ini
|
||||||
|
GEHEIMES_KENNWORT=kennwort123
|
||||||
|
PUBLIC_IRGENDWER=dieser
|
||||||
|
```
|
||||||
|
|
||||||
|
In diesem Beispiel ist `PUBLIC_IRGENDWER` verfügbar als ìmport.meta.env.PUBLIC_IRGENDWER für Server- oder Client-seitigen Code, `GEHEIMES_KENNWORT` hingegen nicht.
|
||||||
|
|
||||||
|
> In früheren Versionen wurde diesen Variablen das Prefix `SNOWPACK_PUBLIC` vorangestellt, und sie erforderten darüber hinaus das Plugin `@snowpack/plugin-env`.
|
||||||
|
|
||||||
|
## Dateiendungen
|
||||||
|
|
||||||
|
In Astro v21.0 muss auf Dateien mit Nennung ihrer tatsächlichen Erweiterung verwiesen werden, exakt so wie sie gespeichert sind.
|
||||||
|
|
||||||
|
```tsx
|
||||||
|
// Div.tsx
|
||||||
|
export default function Div(props) {
|
||||||
|
return <div />;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
In diesem Beispiel müsste auf `Div.tsx` mit `Div.tsx` verwiesen werden, nicht mit `Div.jsx`.
|
||||||
|
|
||||||
|
```diff
|
||||||
|
- import Div from './Div.jsx' // Astro v0.20
|
||||||
|
+ import Div from './Div.tsx' // Astro v0.21
|
||||||
|
```
|
||||||
|
|
||||||
|
Diese Änderung betrifft auch Style-Dateien.
|
||||||
|
|
||||||
|
```scss
|
||||||
|
// Div.scss
|
||||||
|
div {
|
||||||
|
all: unset;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
```diff
|
||||||
|
- <link rel="stylesheet" href={Astro.resolve('./Div.css')}>
|
||||||
|
+ <link rel="stylesheet" href={Astro.resolve('./Div.scss')}>
|
||||||
|
```
|
||||||
|
|
||||||
|
## Plugins
|
||||||
|
|
||||||
|
In Astro v0.21 können Vite-Plugins innerhalb von `astro.config.mjs` konfiguriert werden.
|
||||||
|
|
||||||
|
```js
|
||||||
|
import { imagetools } from 'vite-imagetools';
|
||||||
|
|
||||||
|
export default {
|
||||||
|
vite: {
|
||||||
|
plugins: [imagetools()],
|
||||||
|
},
|
||||||
|
};
|
||||||
|
```
|
||||||
|
|
||||||
|
Um mehr über Vite-Plugins zu lernen, lies bitte den [Vite Plugin Guide](https://vitejs.dev/guide/using-plugins.html).
|
||||||
|
|
||||||
|
## Benutzerdefinierte Renderer
|
||||||
|
|
||||||
|
In Astro v0.21 sollten Plugins ab jetzt `viteConfig()` verwenden.
|
||||||
|
|
||||||
|
```diff
|
||||||
|
// renderer-svelte/index.js
|
||||||
|
+ import { svelte } from '@sveltejs/vite-plugin-svelte';
|
||||||
|
|
||||||
|
export default {
|
||||||
|
name: '@astrojs/renderer-svelte',
|
||||||
|
client: './client.js',
|
||||||
|
server: './server.js',
|
||||||
|
- snowpackPlugin: '@snowpack/plugin-svelte',
|
||||||
|
- snowpackPluginOptions: { compilerOptions: { hydratable: true } },
|
||||||
|
+ viteConfig() {
|
||||||
|
+ return {
|
||||||
|
+ optimizeDeps: {
|
||||||
|
+ include: ['@astrojs/renderer-svelte/client.js', 'svelte', 'svelte/internal'],
|
||||||
|
+ exclude: ['@astrojs/renderer-svelte/server.js'],
|
||||||
|
+ },
|
||||||
|
+ plugins: [
|
||||||
|
+ svelte({
|
||||||
|
+ emitCss: true,
|
||||||
|
+ compilerOptions: { hydratable: true },
|
||||||
|
+ }),
|
||||||
|
+ ],
|
||||||
|
+ };
|
||||||
|
+ },
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Um mehr über Vite-Plugins zu lernen, lies bitte den [Vite Plugin Guide](https://vitejs.dev/guide/using-plugins.html).
|
||||||
|
|
||||||
|
> In früheren Versionen wurden diese Plugins mittels `snowpackPlugin` oder `snowpackPluginOptions` konfiguriert.
|
||||||
|
|
||||||
|
## Änderungen bei der Gestaltung
|
||||||
|
|
||||||
|
### Autoprefixer
|
||||||
|
|
||||||
|
Autoprefixer wird nicht mehr automatisch eingebunden. Aktiviere Autoprefixer in zwei Schritten:
|
||||||
|
|
||||||
|
1. Installiere zunächst die aktuelle Version (`npm i autoprefixer`)
|
||||||
|
2. Erzeuge die Datei `postcss.config.cjs` im Hauptverzeichnis deines Projekts mit:
|
||||||
|
```js
|
||||||
|
module.exports = {
|
||||||
|
plugins: {
|
||||||
|
autoprefixer: {},
|
||||||
|
},
|
||||||
|
};
|
||||||
|
```
|
||||||
|
Die in Vite enthaltene Post-CSS-Konfiguration wird hierdurch ersetzt.
|
||||||
|
|
||||||
|
### Tailwind-CSS
|
||||||
|
|
||||||
|
Stelle sicher, dass Post-CSS installiert ist. Dies war optional in vorherigen Versionen, ist aber nun Voraussetzung:
|
||||||
|
|
||||||
|
1. Intalliere die aktuelle Version von Post-CSS (`npm i -D postcss`)
|
||||||
|
2. Erzeuge die Datei `postcss.config.cjs` im Hauptverzeichnis deines Projekts mit:
|
||||||
|
```js
|
||||||
|
module.exports = {
|
||||||
|
plugins: {
|
||||||
|
tailwindcss: {},
|
||||||
|
},
|
||||||
|
};
|
||||||
|
```
|
||||||
|
Für weitere Informationen lies die [Tailwind CSS Documentation](https://tailwindcss.com/docs/installation#add-tailwind-as-a-post-css-plugin)
|
||||||
|
|
||||||
|
[vite]: https://vitejs.dev
|
||||||
|
[snowpack]: https://www.snowpack.dev
|
||||||
|
|
@ -1,78 +1,78 @@
|
||||||
---
|
---
|
||||||
layout: ~/layouts/MainLayout.astro
|
layout: ~/layouts/MainLayout.astro
|
||||||
title: Schnellstart
|
title: Schnellstart
|
||||||
description: Die einfachste Art, schnell mit Astro loszulegen.
|
description: Die einfachste Weg schnell mit Astro loszulegen.
|
||||||
---
|
---
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
# Voraussetzung: Node.js 12.20.0+, 14.13.1+, oder 16+
|
# Vorbereitung: Überprüfe, ob Node.js die Version 12.20.0+, 14.13.1+, oder 16+ ist
|
||||||
node --version
|
node --version
|
||||||
|
|
||||||
# Erstelle einen neuen Projektordner und navigiere in das Verzeichnis
|
# Erstelle einen neues Projektverzeichnis und navigiere direkt dorthin
|
||||||
mkdir my-astro-project && cd $_
|
mkdir mein-astro-projekt && cd $_
|
||||||
|
|
||||||
# Bereite dich vor abzuheben...
|
# Bereite dich auf den Start vor
|
||||||
npm init astro
|
npm init astro
|
||||||
|
|
||||||
# Dependencies installieren
|
# Installiere benötigte Pakete
|
||||||
npm install
|
npm install
|
||||||
|
|
||||||
# Fange an zu entwickeln!
|
# Beginne mit dem Entwickeln!
|
||||||
npm run dev
|
npm run dev
|
||||||
```
|
```
|
||||||
|
|
||||||
Für Produktionsstandorte,
|
Export - fertig zum Veröffentlichen:
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
# Wenn du bereit bist: Exportiere deine Seite nach `dist/`
|
# Wenn du soweit bist, exportiere deine Site nach `dist/`
|
||||||
npm run build
|
npm run build
|
||||||
```
|
```
|
||||||
|
|
||||||
Um mehr über den Installationsprozess und den ersten Gebrauch von Astro zu lernen, [lies unseren Installations-Leitfaden.](de/installation)
|
Um mehr über den Installationsprozess und den ersten Einsatz von Astro zu lernen [lies unsere Installationsanleitung](de/installation).
|
||||||
|
|
||||||
Wenn du es bevorzugst anhand eines Beispiels zu lernen, schau dir die [komplette Liste an Beispielen](https://github.com/withastro/astro/tree/main/examples) auf GitHub an.
|
Wenn du es bevorzugst anhand eines Beispiels zu lernen, werfe einen Blick auf die [komplette Liste der Beispiele](https://github.com/snowpackjs/astro/tree/main/examples) auf GitHub.
|
||||||
Du kannst jedes Beispiel ausprobieren, indem du `npm init astro -- --template "EXAMPLE_NAME"` ausführst.
|
Du kannst jedes dieser Beispiele ausprobieren, indem du `npm init astro -- --template "BEISPIEL_NAME"` ausführst.
|
||||||
|
|
||||||
## Starte dein Projekt
|
## Starte dein Projekt
|
||||||
|
|
||||||
Führe den folgenden Befehl in deinem Projektverzeichnis aus:
|
In deinem Projektverzeichnis führe den folgenden Befehl in deinem Terminal aus:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
npm run dev
|
npm run dev
|
||||||
```
|
```
|
||||||
|
|
||||||
Astro fängt nun an deine Anwendung unter [http://localhost:3000](http://localhost:3000) bereitzustellen. Wenn du diese URL in deinem Browser öffnest, solltest du Astro’s „Hello, World“ sehen.
|
Astro wird von nun an deine Anwendung unter [http://localhost:3000](http://localhost:3000) bereitstellen. Wenn du diese URL in deinem Browser öffnest, solltest du Astros "Hello, World" sehen.
|
||||||
|
|
||||||
Der Server beobachtet alle Dateiänderungen in deinem `src/`-Verzeichnis, sodass du deine Anwendung nicht bei jeder Änderung neu starten musst.
|
Der Server wird nun auf alle Änderungen in deinem `src/`-Verzeichnisch lauschen, sodass du deine Anwendung nicht nach jeder Änderung neu starten musst.
|
||||||
|
|
||||||
## Bereite dein Projekt für die Veröffentlichung vor
|
## Kompiliere dein Projekt
|
||||||
|
|
||||||
Um dein Projekt zu kompilieren, gebe in deinem Verzeichnis den folgenden Befehl in dein Terminal ein:
|
In deinem Projektverzeichnis führe den folgenden Befehl in deinem Terminal aus:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
npm run build
|
npm run build
|
||||||
```
|
```
|
||||||
|
|
||||||
Dadurch wird Astro beauftragt, deine Website zu erstellen und sie direkt auf der Festplatte zu speichern. Deine Anwendung steht nun im `dist/`-Verzeichnis für dich bereit.
|
Dies weist Astro an deine Site zu erstellen und direkt zu speichern. Deine Anwendung steht nun im `dist/`-Verzeichnis bereit.
|
||||||
|
|
||||||
## Veröffentliche dein Projekt
|
## Veröffentliche dein Projekt
|
||||||
|
|
||||||
Astro-Webseiten sind statisch, sodass sie bei deinem bevorzugten Hoster veröffentlicht werden können:
|
Astro-Sites sind statisch, sodass sie ganz einfach bei deinem bevorzugten Hoster veröffentlicht werden können:
|
||||||
|
|
||||||
- [AWS S3 bucket](https://aws.amazon.com/s3/)
|
- [AWS S3 bucket](https://aws.amazon.com/s3/)
|
||||||
- [Google Firebase](https://firebase.google.com/)
|
- [Google Firebase](https://firebase.google.com/)
|
||||||
- [Netlify](https://www.netlify.com/)
|
- [Netlify](https://www.netlify.com/)
|
||||||
- [Vercel](https://vercel.com/)
|
- [Vercel](https://vercel.com/)
|
||||||
- [Erfahre mehr über die Veröffentlichung deines Projektes in unserem Astro Deploy guide.](/guides/deploy)
|
- [Erfahre mehr über das Veröffentlichen von Astro-Builds](/guides/deploy).
|
||||||
|
|
||||||
## Nächste Schritte
|
## Nächste Schritte
|
||||||
|
|
||||||
Du hast es geschafft! Du kannst jetzt mit dem Entwickeln beginnen!
|
Geschafft! Du kannst jetzt mit dem Entwickeln beginnen!
|
||||||
|
|
||||||
Wir empfehlen dir, dass du dir etwas Zeit nimmst, um mit Astro vertraut zu werden. Am Besten indem du dir weitere Seiten unserer Dokumentation durchliest. Hier ein paar Empfehlungen:
|
Wir möchten dich ermutigen, dir etwas Zeit zu nehmen, um mit der Art und Weise vertraut zu werden, wie Astro funktioniert. Am besten befasst du dich weitergehend mit der Dokumentation. Hier ein paar Empfehlungen:
|
||||||
|
|
||||||
📚 Lerne mehr über Astro’s [Projektstruktur.](/core-concepts/project-structure)
|
📚 Lerne mehr über Astros Projektstruktur in unserer [Anleitung zur Projektstruktur](/core-concepts/project-structure)
|
||||||
|
|
||||||
📚 Lerne mehr über Astro’s Komponenten-Syntax in unserem [Astro-Komponenten-Handbuch.](/core-concepts/astro-components)
|
📚 Lerne mehr über Astros Komponenten-Syntax in unserer [Astro-Komponenten-Anleitung](/core-concepts/astro-components)
|
||||||
|
|
||||||
📚 Lerne mehr über Astro’s dateibasiertes Routing in unserem [Routing-Handbuch.](core-concepts/astro-pages)
|
📚 Lerne mehr über Astros dateibasiertes Routing in unserer [Routing-Anleitung](core-concepts/astro-pages)
|
||||||
|
|
|
||||||
52
docs/src/pages/de/themes.astro
Normal file
52
docs/src/pages/de/themes.astro
Normal file
|
|
@ -0,0 +1,52 @@
|
||||||
|
---
|
||||||
|
import Layout from '../../layouts/MainLayout.astro';
|
||||||
|
import Card from '../../components/Card.astro';
|
||||||
|
import { Markdown } from 'astro/components';
|
||||||
|
import themes from '../../data/themes.json';
|
||||||
|
import components from '../../data/components.json';
|
||||||
|
---
|
||||||
|
<Layout content={{title: 'Vorlagen'}} hideRightSidebar>
|
||||||
|
<style>
|
||||||
|
.card-grid {
|
||||||
|
display: grid;
|
||||||
|
grid-column-gap: 15px;
|
||||||
|
grid-row-gap: 15px;
|
||||||
|
grid-auto-flow: dense;
|
||||||
|
grid-template-columns: repeat(auto-fit,minmax(300px,1fr))
|
||||||
|
}
|
||||||
|
</style>
|
||||||
|
<Markdown>
|
||||||
|
## Vorgestellte Vorlagen
|
||||||
|
</Markdown>
|
||||||
|
<div class="card-grid">
|
||||||
|
{themes.featured.map((item)=>(<Card data={item} />))}
|
||||||
|
</div>
|
||||||
|
<Markdown>
|
||||||
|
## Offizielle Vorlagen
|
||||||
|
|
||||||
|
Astro pflegt verschiedene offizielle Vorlagen für Dokumentationssites, Portfolios und mehr.
|
||||||
|
</Markdown>
|
||||||
|
<div class="card-grid">
|
||||||
|
{themes.official.map((item)=>(<Card data={item} />))}
|
||||||
|
</div>
|
||||||
|
<Markdown>
|
||||||
|
## Vorlagen aus der Community
|
||||||
|
|
||||||
|
Sieh dir einige von unserer Community entwickelte Vorlagen an!
|
||||||
|
</Markdown>
|
||||||
|
<div class="card-grid">
|
||||||
|
{themes.community.map((item)=>(<Card data={item} />))}
|
||||||
|
</div>
|
||||||
|
<Markdown>
|
||||||
|
## Vorgestellte Packages
|
||||||
|
|
||||||
|
Unser Package-Ökosystem wächst stetig! Sieh dir die hier vorgestellten Packages unserer Community an. Durchsuche unsere vollständige Sammlung [auf npm.](https://www.npmjs.com/search?q=keywords%3Aastro-component)
|
||||||
|
</Markdown>
|
||||||
|
<div class="card-grid">
|
||||||
|
{components.community.map((item)=>(<Card data={item} />))}
|
||||||
|
</div>
|
||||||
|
<Markdown>
|
||||||
|
> Möchtest du deine eigene Arbeit hier sehen? [Teile sie in Discord!](https://astro.build/chat)
|
||||||
|
Wir teilen hier regelmäßig unsere Favoriten aus dem #showcase-Channel.
|
||||||
|
</Markdown>
|
||||||
|
</Layout>
|
||||||
Loading…
Reference in a new issue