diff options
Diffstat (limited to 'docs/src/pages/de')
| -rw-r--r-- | docs/src/pages/de/404.astro | 9 | ||||
| -rw-r--r-- | docs/src/pages/de/comparing-astro-vs-other-tools.md | 233 | ||||
| -rw-r--r-- | docs/src/pages/de/core-concepts/astro-components.md | 386 | ||||
| -rw-r--r-- | docs/src/pages/de/core-concepts/astro-pages.md | 67 | ||||
| -rw-r--r-- | docs/src/pages/de/core-concepts/component-hydration.md | 113 | ||||
| -rw-r--r-- | docs/src/pages/de/core-concepts/layouts.md | 155 | ||||
| -rw-r--r-- | docs/src/pages/de/core-concepts/project-structure.md | 58 | ||||
| -rw-r--r-- | docs/src/pages/de/core-concepts/routing.md | 102 | ||||
| -rw-r--r-- | docs/src/pages/de/getting-started.md | 75 | ||||
| -rw-r--r-- | docs/src/pages/de/guides/styling.md | 644 | ||||
| -rw-r--r-- | docs/src/pages/de/installation.md | 178 | ||||
| -rw-r--r-- | docs/src/pages/de/migration/0.21.0.md | 229 | ||||
| -rw-r--r-- | docs/src/pages/de/quick-start.md | 78 | ||||
| -rw-r--r-- | docs/src/pages/de/themes.astro | 53 |
14 files changed, 0 insertions, 2380 deletions
diff --git a/docs/src/pages/de/404.astro b/docs/src/pages/de/404.astro deleted file mode 100644 index 7107cc49a..000000000 --- a/docs/src/pages/de/404.astro +++ /dev/null @@ -1,9 +0,0 @@ ---- -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> diff --git a/docs/src/pages/de/comparing-astro-vs-other-tools.md b/docs/src/pages/de/comparing-astro-vs-other-tools.md deleted file mode 100644 index 7462ced85..000000000 --- a/docs/src/pages/de/comparing-astro-vs-other-tools.md +++ /dev/null @@ -1,233 +0,0 @@ ---- -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/withastro/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](/de/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](/de/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](/de/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](/de/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](/de/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](/de/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](/de/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](/de/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](/de/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](/de/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/withastro/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/withastro/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](/de/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](/de/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. diff --git a/docs/src/pages/de/core-concepts/astro-components.md b/docs/src/pages/de/core-concepts/astro-components.md deleted file mode 100644 index 18ce76789..000000000 --- a/docs/src/pages/de/core-concepts/astro-components.md +++ /dev/null @@ -1,386 +0,0 @@ ---- -layout: ~/layouts/MainLayout.astro -title: Astro-Komponenten -description: 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](/de/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](/de/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](/de/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 **Fallback-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 diff --git a/docs/src/pages/de/core-concepts/astro-pages.md b/docs/src/pages/de/core-concepts/astro-pages.md deleted file mode 100644 index 15beec1f4..000000000 --- a/docs/src/pages/de/core-concepts/astro-pages.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -layout: ~/layouts/MainLayout.astro -title: Astro-Seiten -description: Eine Einführung in Astro-Seiten - Komponenten die wie vollständige Seiten funktionieren. ---- - -**Seiten** sind eine spezielle Art der [Astro-Komponente](/de/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`. diff --git a/docs/src/pages/de/core-concepts/component-hydration.md b/docs/src/pages/de/core-concepts/component-hydration.md deleted file mode 100644 index a804805b5..000000000 --- a/docs/src/pages/de/core-concepts/component-hydration.md +++ /dev/null @@ -1,113 +0,0 @@ ---- -layout: ~/layouts/MainLayout.astro -title: Partial Hydration in Astro -description: Lerne wie Partial Hydration unter Verwendung der "Islands-Architecture" 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. - -> 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. -> <br/> -- [Jason Miller](https://jasonformat.com/islands-architecture/) - -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 diff --git a/docs/src/pages/de/core-concepts/layouts.md b/docs/src/pages/de/core-concepts/layouts.md deleted file mode 100644 index ce630dde2..000000000 --- a/docs/src/pages/de/core-concepts/layouts.md +++ /dev/null @@ -1,155 +0,0 @@ ---- -layout: ~/layouts/MainLayout.astro -title: Layouts -description: Einführung in Layouts, eine Art der Astro-Komponente, die für gemeinsame Layouts auf verschiedenen Seiten verwendet wird. ---- - -**Layouts** sind eine besondere Art [Komponente](/de/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](/de/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: Blogpost -layout: ../layouts/PostLayout.astro ---- - -Dieser Blogpost 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). diff --git a/docs/src/pages/de/core-concepts/project-structure.md b/docs/src/pages/de/core-concepts/project-structure.md deleted file mode 100644 index a1d8f1e82..000000000 --- a/docs/src/pages/de/core-concepts/project-structure.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -layout: ~/layouts/MainLayout.astro -title: Projektstruktur -description: Lerne wie die Projektstruktur in Astro aufgebaut ist. ---- - -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](/de/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) -- [Astro-Seiten](/de/core-concepts/astro-pages) -- [Layouts](/de/core-concepts/layouts) -- [JavaScript-Komponenten](/de/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](/de/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 [Partial Hydration](/de/core-concepts/component-hydration) eine bestimmte Frontend-Komponente aktiviert hast. - -### `src/layouts` - -[Layouts](/de/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`](/de/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. diff --git a/docs/src/pages/de/core-concepts/routing.md b/docs/src/pages/de/core-concepts/routing.md deleted file mode 100644 index d42d2b094..000000000 --- a/docs/src/pages/de/core-concepts/routing.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -layout: ~/layouts/MainLayout.astro -title: Routing -description: Einführung in das Routing in 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 `/withastro/astro/tree/main/docs/public/favicon.svg` folgende Parameter für die Seite verfügbar machen: - -```js -{ - org: 'withastro', - 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` diff --git a/docs/src/pages/de/getting-started.md b/docs/src/pages/de/getting-started.md deleted file mode 100644 index 24eb52476..000000000 --- a/docs/src/pages/de/getting-started.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -layout: ~/layouts/MainLayout.astro -title: Erste Schritte -description: Eine einfache Einführung in Astro -lang: de ---- - -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 für die Astro-Dokumentation und alle damit verbundenen Ressourcen. - -## Astro ausprobieren - -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 in fünf einfachen Schritten mit Astro loszulegen, lies [unsere Schnellstart-Anleitung](/de/quick-start). - -Alternativ kannst du unsere [Installationsanleitung](/de/installation) lesen, um eine ausführlichere Schritt-für-Schritt-Anleitung zu erhalten. - -### Beispielprojekte - -Falls du Astro lieber anhand von Beispielen kennenlernen möchtest, sieh dir unsere [vollständige Beispiel-Bibliothek](https://github.com/withastro/astro/tree/main/examples) auf GitHub an. - -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/withastro/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 - -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 **praktisches Lernen** bevorzugst, starte direkt mit ein Beispiel aus unserer [Beispiel-Liste](https://github.com/withastro/astro/tree/main/examples). -- Falls du bevorzugst **Schritt für Schritt zu lernen**, starte mit unseren [grundlegenden Konzepten und Anleitungen](/de/core-concepts/project-structure). - -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. - -### Lerne die `.astro`-Syntax - -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 unterstützende Anleitung zu [Astro-Komponenten](/de/core-concepts/astro-components) ist eine gute Einführung in die Astro-Syntax - und der beste Weg sie zu lernen. - -### API-Referenz - -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. - -### Versionsdokumentation - -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. - -## Auf dem Laufenden bleiben - -Der [@astrodotbuild](https://twitter.com/astrodotbuild) Twitter-Account ist die offizielle Quelle für Ankündigungen vom Astro-Team. - -Zusätzlich veröffentlichen wir alle Ankündigungen in unserer [Discord-Community](https://astro.build/chat) im `#announcements`-Channel. - -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/withastro/astro/blob/main/packages/astro/CHANGELOG.md) nachlesen. - -## Fehlt etwas? - -Falls etwas in der Dokumentation fehlt, oder falls du einen bestimmten Teil verwirrend findest, [erstelle bitte ein Issue](https://github.com/withastro/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! - -## Credit - -Diese Einführung basierte ursprünglich auf der Einführung zu [React](https://reactjs.org/). diff --git a/docs/src/pages/de/guides/styling.md b/docs/src/pages/de/guides/styling.md deleted file mode 100644 index 3d8fb0c82..000000000 --- a/docs/src/pages/de/guides/styling.md +++ /dev/null @@ -1,644 +0,0 @@ ---- -layout: ~/layouts/MainLayout.astro -title: Styling & CSS -description: Lerne Komponenten mit Astro zu gestalten. ---- - -Astro verfügt über eine besondere Möglichkeit, um das Schreiben von CSS so einfach wie möglich zu halten: Astro-Komponenten können über das Einfügen eines `<style>`-Tags an beliebiger Stelle gestaltet werden. - -## Styles in Astro-Komponenten - -Standardmäßig werden in Astro-Komponenten alle Styles nur auf Elemente im Rahmen der Komponente (genannt **Scope**) angewandt, der sie hinzugefügt wurden. Dies kann die Arbeit mit Styles erheblich erleichtern, da du dich zu jeder Zeit nur um die Gestaltung der Komponente kümmern musst, an der du arbeitest. - -```html -<!-- src/components/MeineKomponente.astro --> -<style> - /* Klassen-Selektor im Scope der Komponente */ - .text { - font-family: cursive; - } - /* Element-Selektor im Scope der Komponente */ - h1 { - color: red; - } -</style> - -<h1>Ich bin ein Style im Scope der Komponente, und ich bin rot!</h1> -<p class="text"> - Ich bin ein Style im Scope der Komponente, und ich bin kursiv!! -</p> -``` - -Beachte dass der `h1`-Selektor hier nicht über die Komponente hinaus wirksam wird! Die Styles werden nicht auf andere `h1`-Tags außerhalb dieses Dokuments angewandt - auch nicht in untergeordneten Komponenten. - -_Tipp: Auch wenn es möglich ist hier Element-Selektoren zu verwenden, sollten doch bevorzugt Klassen-Namen verwendet werden. Das ist nicht nur ein klein wenig performanter, es ist auch leichter zu lesen, insbesondere in einem umfangreichen Dokument._ - -### Globale Styles - -Natürlich besteht die tatsächliche Macht von CSS darin, Styles so häufig wie möglich wiederzuverwenden! Die bevorzugte Methode um globale Styles einzubinden, ist die Verwendung eines `<link>`-Tags im `<head>`-Block, ganz so wie du es gewohnt bist. Diese Methode kann in Astro auch im Zusammenhang mit dem `<style>`-Tag im Scope der Komponente angewandt werden: - -```html -<!-- src/pages/index.astro --> -<head> - <!-- Styles - geladen über src/styles/utils.css unter Verwendung von Astro.resolve() --> - <link rel="stylesheet" type="text/css" - href={Astro.resolve('../styles/utils.css')} /> -</head> -<body> - <!-- Styles die nur im Scope der aktuellen Seite gelten - (nicht für untergeordnete Seiten oder andere Komponenten) --> - <style> - .title { - font-size: 32px; - font-weight: bold; - } - </style> - - <!-- Die Klasse ".title" ist im Scope, aber wir können auch unsere - globalen Hilfsklasssen "align-center" und "margin top: 4" aus utils.css verwenden --> - <h1 class="title align-center mt4">Seitentitel im Scope</h1> -</body> -``` - -_Beachte: `Astro.resolve()` ist ein nützliches Hilfsmittel, um Verweise auf Dateien von überall her aufzulösen ([docs][astro-resolve])_ - -#### Styling untergeordneter Elemente - -Falls du Styles, die im Scope der Komponente gesetzt werden, auch auf untergeordnete Komponenten anwenden willst, kannst du auf die `:global()`-Funktion aus den [CSS-Modules][css-modules] zurückgreifen: - -```astro -<!-- src/components/MeineKomponente.astro --> ---- -import PostContent from './Post.astro'; ---- -<style> - /* Nur im Scope der aktuellen Komponente gültig */ - h1 { - color: red; - } - - /* Im Scope aller Komponenten unterhalb des Elements mit der .blogpost-Klasse gültig */ - .blogpost :global(h1) { - color: blue; - } -</style> - -<h1>Titel</h1> -<article class="blogpost"> - <PostContent /> -</article> -``` - -Dies ist eine sehr gute Methode, um Dinge zu stylen wie Blogposts oder Dokumente, die mit Inhalten aus einem CMS außerhalb von Astro gefüttert werden. Aber Vorsicht, wenn untergeordnete Elemente frei von Abhängigkeiten gestaltet werden, bricht dies auch die Verkapselung der Komponente auf. Das Arbeiten mit Komponenten die unterschiedlich aussehen, abhängig davon ob sie ein bestimmtes übergeordnetes Element haben oder nicht, kann sehr schnell unübersichtlich werden. - -#### Globale Styles innerhalb eines `<style>`-Tags - -Falls du globale Styles verwenden willst, ohne einen normalen `<link>`-Tag im `<head>`-Block zu verwenden (die empfohlene Variante), gibt es dafür mit `<style global>` eine Notlösung: - -```html -<style global> - /* Wird auf alle h1-Tags der gesamten Site angewandt */ - h1 { - font-size: 32px; - } -</style> - -<h1>Globaler Style</h1> -``` - -Dasselbe kannst du erreichen, indem du einem Selektor die `:global()`-Funktion voranstellst: - -```html -<style> - /* Wird auf alle h1-Tags deiner gesamten Site angewandt */ - :global(h1) { - font-size: 32px; - } - - /* h1-Style nur im Scope dieser Datei angewandt */ - h1 { - color: blue; - } -</style> -``` - -Es wird empfohlen diese Methoden nur dort einzusetzen, wo ein `<link>`-Tag nicht funktionieren würde. Es ist sehr schwer irrige globale Styles aufzuspüren, wenn sie verteilt auftreten und nicht in einer zentralen CSS-Datei stehen. - -📚 Lies unseren vollständigen Artikel über die Syntax in [Astro-Komponenten][astro-component], um mehr über die Verwendung des `<style>`-Tags zu erfahren. - -## Autoprefixer - -[Autoprefixer][autoprefixer] kümmert sich für dich um Browser-übergreifende CSS-Kompatibilität. Installiere autoprefixer (`npm install --save-dev autoprefixer`) und füge eine Datei mit dem Namen `postcss.config.cjs` deinem Hauptverzeichnis hinzu: - -```js -// postcss.config.cjs -module.exports = { - plugins: [require('autoprefixer')], -}; -``` - -_Beachte: Astro v0.21 und spätere Versionen erfordern diesen Schritt zur Einrichtung von autoprefixer. Vorherige Versionen haben dies automatisch ausgeführt._ - -## PostCSS - -Du kannst jedes beliebige PostCSS-Plugin verwenden, indem du eine `postcss.config.cjs`-Datei deinem Hauptverzeichnis hinzufügst. Für das Setup und die Konfiguration des Plugins, das du installieren willst, folge der Dokumentation zu dem Plugin. - ---- - -## Unterstützte Styling-Optionen - -Styling in Astro sollte so flexibel sein, wie du es haben willst! Die folgenden Optionen werden unterstützt: - -| Framework | Globales CSS | Scoped CSS | CSS-Modules | -| :--------------- | :----------: | :--------: | :---------: | -| `.astro` | ✅ | ✅ | N/A¹ | -| `.jsx` \| `.tsx` | ✅ | ❌ | ✅ | -| `.vue` | ✅ | ✅ | ✅ | -| `.svelte` | ✅ | ✅ | ❌ | - -¹ _`.astro`-Dateien haben keine Laufzeit, daher nimmt Scoped-CSS hier den Platz von CSS-Modules ein (Styles sind im Scope der Komponenten, benötigen aber keine dynamischen Werte)_ - -Alle Styles in Astro werden automatisch minifiziert und gepackt, du kannst so einfach nur dein CSS schreiben - und wir machen den Rest ✨. - ---- - -## Frameworks und Bibliotheken - -### 📘 React/Preact - -`.jsx`-Dateien unterstützen sowohl globales CSS als auch CSS-Modules. Um letztere zu verwenden, benutze die Erweitereung `.module.css` (oder `.module.scss`/`.module.sass` wenn du Sass einsetzt). - -```js -import './global.css'; // Verwende globales CSS -import Styles from './styles.module.css'; // Verwende CSS-Modules (muss auf `.module.css`, `.module.scss`, or `.module.sass` enden!) -``` - -### 📗 Vue - -Vue unterstützt in Astro die selben Methoden wie `vue-loader`: - -- [vue-loader - Scoped-CSS][vue-scoped] -- [vue-loader - CSS-Modules][vue-css-modules] - -### 📕 Svelte - -Svelte funktioniert in Astro ebenfalls genauso wie gewohnt: [Svelte-Styling-Docs][svelte-style]. - -### 🎨 CSS-Präprozessoren (Sass, Stylus, etc.) - -Astro unterstützt als CSS-Präprozessoren [Sass][sass], [Stylus][stylus] und [Less][less] mittels [Vite][vite-preprocessors]. Der jeweils gewünschte Präprozessor kann wie folgt aufgesetzt werden: - -- **Sass**: Führe `npm install -D sass` aus und verwende `<style lang="scss">` oder `<style lang="sass">` (eingerückt) in `.astro`-Dateien -- **Stylus**: Führe `npm install -D stylus` aus und verwende `<style lang="styl">` oder `<style lang="stylus">` in `.astro`-Dateien -- **Less**: Führe `npm install -D less` aus und verwende `<style lang="less">` in `.astro`-Dateien - -Alle oben genannten können auch innerhalb eines JS-Frameworks ausgeführt werden! Folge einfach den Modellen, die das jeweilige Framework hierfür empfielt: - -- **React**/**Preact**: `import Styles from './styles.module.scss'`; -- **Vue**: `<style lang="scss">` -- **Svelte**: `<style lang="scss">` - -Darüber hinaus unterstützt Astro auch [PostCSS](#-postcss), aber die Einrichtung erfolgt [etwas abweichend hiervon](#-postcss). - -_Beachte: CSS unterhalb des `public/`-Verzeichnisses wird **nicht** verarbeitet! Platziere es stattdessen unterhalb des `src/`-Verzeichnisses._ - -### 🍃 Tailwind - -Astro kann sehr einfach für die Verwendung von [Tailwind][tailwind] konfiguriert werden! Installiere die Abhängigkeiten: - -``` -npm install --save-dev tailwindcss -``` - -Und erzeuge zwei Dateien in deinem Hauptverzeichnis: `tailwind.config.cjs` und `postcss.config.cjs`: - -```js -// tailwind.config.cjs -module.exports = { - mode: 'jit', - purge: ['./public/**/*.html', './src/**/*.{astro,js,jsx,svelte,ts,tsx,vue}'], - // Weitere Optionen hier ... -}; -``` - -```js -// postcss.config.cjs -module.exports = { - plugins: [require('tailwindcss')], -}; -``` - -Damit bist du ausgerüstet, um Tailwind einzusetzen! Der von uns empfohlene Ansatz ist, eine Datei `src/styles/global.css` (oder wie du dein globales Stylesheet bevorzugterweise nennst) mit den [Tailwind-Utilities][tailwind-utilities] darin zu erzeugen - ungefähr in dieser Form: - -```css -/* src/styles/global.css */ -@tailwind base; -@tailwind components; -@tailwind utilities; -``` - -Füge die Datei deiner Astro-Seite (oder deiner Layout-Komponente) hinzu: - -```astro -<head> - <style global> - @import "../styles/global.css"; - </style> -</head> -``` - -Alternativ zu einer Datei `src/styles/global.css` kannst du Tailwind-Utilities auch in einzelnen `pages/*.astro`-Komponenten in einem `<style>`-Block hinzufügen. Aber vermeide sorgfältig etwaige Dopplungen! Falls du mehrere von Tailwind verwaltete Stylesheets verwendest, stelle sicher, dass du nicht die selben CSS-Styles mehrfach in verschiedenen CSS-Dateien an die Benutzerinnen und Benutzer schickst. - -#### Umziehen von v0.19 - -Mit der [Version 0.20.0](https://github.com/withastro/astro/releases/tag/astro%400.20.0) packt, kompiliert und prozessiert Astro keine Dateien mehr, die im Verezichnis `public/` liegen. Wir haben ursprünglich empfohlen sämtliche Tailwind-Dateien im `public`-Verzeichnis zu speichern. Falls du dein Projekt diesem Modell folgend begonnen hast, solltest du alle Tailwind-Dateien in das `src`-Verzeichnis verschieben und sie in deinem Template über [Astro.resolve()][astro-resolve] importieren: - -```astro - <link - rel="stylesheet" - href={Astro.resolve("../styles/global.css")} - > -``` - -### 🎭 PostCSS - -PostCSS zu verwenden ist so einfach wie eine [`postcss.config.cjs`](https://github.com/postcss/postcss#usage)-Datei in deinem Hauptverzeichnis zu erzeugen. - -Beachte, dass dieses Plugin sämtliches CSS in deinem Projekt verarbeitet, einschließlich jeglicher Dateien die nach CSS kompiliert wurden (wie zum Beispiel `.scss`-Sass-Dateien). - -_Beachte: CSS unterhalb des `public/`-Verzeichnisses **wird nicht verarbeitet!** Platziere es stattdessen unterhalb des `src/`-Verzeichnisses, wenn PostCSS es vearbeiten soll._ - -## Bündeln - -Sämtliches CSS wird minifiziert und automatisch gebündelt, wenn du `astro build` ausführst. Ohne zu sehr in die Tiefe zu gehen, die grundlgenden Regeln lauten wie folgt: - -- Wenn ein Style nur innerhalb einer Route auftaucht, wird er nur für diese Route geladen (`/_astro/[page]-[hash].css`) -- Wenn ein Style innerhalb mehrerer Routen auftaucht, wird er in einem `/_astro/common-[hash].css`-Bündel zusammengefasst -- Sämtliche Styles erhalten ihre Hashes in Bezug auf die Inhalte, für die sie gelten (das bedeutet, die Hashes ändern sich nur, wenn die Inhalte sich ändern) - -Wir werden unsere Styling-Optimierungen im Laufe der Zeit stetig weiterentwickeln und würden gerne euer Feedback dazu hören! Falls `astro build` unerwartete Styles generiert, oder wenn du Vorschläge zur Verbesserung hast, [eröffne bitte ein Issue][issues]. - -_Beachte: Wenn einige Seiten-Styles gemeinsam gebündelt werden und andere Seiten-Styles auf die Seite bezogen bleiben, entwickeln sich hieraus meistens keine Probleme. Aber wenn Teile deiner Styles gebündelt werden, könnten sie \_technisch_ auch in einer anderen Reihenfolge laden, als von dir in deiner Kaskade intendiert. Auch wenn dieses Problem nicht nur Astro zu eigen ist - es besteht potentiell bei so ziemlich jedem Bündelungsprozess - so kann es dich doch unerwartet treffen, wenn du diese Möglichkeit nicht von vorne herein in Betracht ziehst. Stelle sicher, dass du deinen abschließenden Build eingehend diesbezüglich inspizierst - und [melde bitte auftretende Probleme][issues], auf die du stößt.\_ - -## Fortgeschrittene Styling-Architektur - -Zu viele Entwicklungsumgebungen legen die Hände in den Schoß, wen es um CSS geht - oder sie warten im besten Fall mit erfundenen Beispielen auf, die dich nicht wirklich weiter bringen. Entwicklern zu sagen "Verwende einfach die Styling-Lösung, die dir gefällt!", ist ein netter Ansatz, der sich in der Praxis nicht bewährt. Nur sehr wenige Styling-Lösungen taugen für wirklich jedes Setup. Mit Astro verhält es sich in dieser Hinsicht nicht anders - manche Ansätze _werden_ besser funktionieren als andere. - -Ein Beispiel, um dies zu bebildern: Astro entfernt JS welches zur Laufzeit ausgeführt wird (sogar das eigentliche Framework wenn möglich). Somit wäre es eine schlechte Idee für sämtliche Styles auf gestylte JS-Elemente zu setzen, da dann React auch auf Seiten geladen werden müsste, wo es eigentlich nicht gebraucht wird. Oder du erzeugst mit dem Laden einen "[FOUC][fouc]", wenn dein statisches HTML geladen wird, aber der Browser noch darauf wartet, dass JavaScript vollständig heruntergeladen und ausgeführt wird. Oder stelle dir ein weiteres Beispiel am anderen Ende des Spektrums vor: _BEM_. Du kannst in Astro einen vollständig entkoppelten [BEM][bem]- oder [SMACSS][smacss]-Ansatz verfolgen. Doch das bedeutet eine große Menge manueller Wartung, die du vermeiden könntest - und es lässt dich vieles von dem Komfort verpassen, den dir [Astro-Komponenten](/de/core-concepts/astro-components) bieten können. - -Wir denken, es gibt einen Mittelweg zwischen intuitivem, aber langsamem CSS-in-JS und schnellem, aber mühseligem globalem CSS: **Hybrides Scoped-CSS + Utility-CSS**. Dieser Ansatz funktioniert gut in Astro, ist performant für die Nutzerinnen und Nutzer und ist entsprechend die wohl beste Styling-Lösung in Astro für _die meisten Leute_ (vorausgesetzt du bist bereit dich damit auseinanderzusetzen). Eine kurze Übersicht: - -**Dieser Ansatz ist gut für…** - -- Entwickler und Entwicklerinnen die etwas Neues bezüglich Styling ausprobieren wollen -- Entwickler und Entwicklerinnen die ein paar dogmatische Annahmen bezüglich der CSS-Architektur zu schätzen wissen - -**Dieser Ansatz ist _NICHT_ gut für…** - -- Entwickler und Entwicklerinnen die bereits selbst starke dogmatische Annahmen bezüglich des Styling haben - und alles selbst kontrollieren wollen - -Lies weiter, wenn du nach ein paar dogmatischen Annahmen suchst 🙂. Wir werden den Ansatz beschreiben, indem wir ein paar Grundregeln festlegen, die dich anleiten sollen deine Styles zu definieren: - -### Hybrides Scoped-CSS + Utility-CSS - -#### Scoped Styles - -Du benötigst keine Erläuterung zu Komponenten-basiertem Design. Dir ist bereits klar, dass die Wiederverwendung von Komponenten eine gute Idee ist. Und es war diese Idee, die die Leute dazu brachte sich an Konzepte wie [gestylte Komponenten][styled-components] und [gestyltes JSX][styled-jsx] zu gewöhnen. Aber anstatt deine Nutzerinnen und Nutzer mit den langen Ladezeiten von CSS-in-JS zu belasten, kannst du mit Astro etwas Besseres einsetzen: **eingebaute Styles im Scope der Komponente**. - -```astro ---- -// src/components/Button.astro --> ---- -<style lang="scss"> - /* ✅ Lokal im Scope! */ - .btn { - padding: 0.5em 1em; - border-radius: 3px; - font-weight: 700; - } -</style> -<button type="button" class="btn"> - <slot></slot> -</button> -``` - -_Beachte: Wir verwenden hier in sämtlichen Beispielen `lang="scss"`, welches das Verschachteln und Teilen von [Farben und Variablen][sass-use] stark vereinfacht. Dies ist jedoch gänzlich optional, und du kannst ebenso gut normales CSS verwenden._ - -Die `.btn`-Klasse ist auf die Komponente begrenzt und wird nicht über das Dokument hinaus wirksam. Dies bedeutet, du kannst dich **auf das Styling und musst dich nicht auf die Benennung konzentrieren**. Dieser Ansatz, der das Lokale an den Anfang stellt, fügt sich sehr gut in das ESM-getriebene Design von Astro, das Einkapselung und Wiederverwendbarkeit über eine globale Wirksamkeit stellt. Auch wenn es sich um ein einfaches Beispiel handelt, sollte festgehalten werden, dass dies **extrem gut skaliert**. Und für den Fall, dass du gemeinsame Werte zwischen Komponenten teilen willst, empfehlen wir das [Sass-Modulsystem][sass-use], das sehr einfach zu verwenden ist und sich perfekt in ein Design einfügt, in dem die Komponente an den Anfang gestellt wird. - -Im Kontrast zu diesem Ansatz erlaubt Astro auch globale Styles mittels der `:global()` und `<style global>`-Notlösungen. Es sollte jedoch soweit möglich vermieden werden sie einzusetzen. Ein einfaches Beispiel: Nehmen wir an, du hast deinen Button in einer `<Nav />`-Komponente verwendet und willst ihn dort anders gestalten. Du könntest versucht sein, das folgendermaßen zu probieren: - -```astro ---- -// src/components/Nav.astro -import Button from './Button.astro'; ---- - -<style lang="scss"> - .nav :global(.btn) { - /* ❌ Dies wird einen Konflikt mit <Button>-Styles erzeugen */ - } -</style> - -<nav class="nav"> - <Button>Menü</Button> -</nav> -``` - -Dies ist allerdings nicht erstrebenswert, da nun `<Nav>` und `<Button>` bei der endgültigen Gestaltung des Buttons konkurrieren. Sobald du jetzt den einen veränderst, musst du auch den anderen anpassen, und sie sind nicht mehr wirklich isoliert, so wie zuvor (sie sind nun verbunden in bidirektionaler Abhängigkeit). Es ist sehr leicht sich vorzustellen, dass dieses Modell nur ein paar mal wiederholt werden muss, bis die Befürchtung aufkommt, dass jede Veränderung von Styles _irgendwo_ das Styling in einem ganz anderem Teil der Anwendung kaputt macht. - -Stattdessen kannst du `<Button>` seine eigenen Styles kontrollieren lassen und es mit einer Prop versuchen: - -```astro ---- -// src/components/Button.astro -const { theme } = Astro.props; ---- -<style lang="scss"> - .btn { - /* ✅ <Button> hat nun wieder die Kontrolle über das Styling! */ - [data-theme='nav'] { - // nav-friendly styles here… - } - } -</style> - -<button type="button" data-theme={theme}> - <slot></slot> -</button> -``` - -An anderer Stelle kannst du nun `<Button theme="nav">` verwenden, um zu bestimmen, welche Art von Button es ist. Dies bewahrt den Vertrag, in dem steht, dass _Button sich um seine Styles kümmert und Nav sich um seine_. Und du kannst den einen bearbeiten ohne den anderen zu beeinflussen. Der schlimmstmögliche Fall bei der Verwendung globaler Styles ist, dass eine Komponente kaputt und nicht mehr nutzbar ist (ihr fehlen wesentliche Teile ihrer Styles). Aber der schlimmstmögliche Fall bei der Verwendung von Props (z. B. bei einem Tippfehler) ist, dass die Komponente zurückgesetzt wird auf ihren ursprünglichen, aber immer noch nutzbaren, Zustand. - -💁 **Warum dies mit Astro gut funktioniert**. Astro ist im Wesentlichen von JavaScript-Modulen inspiriert: Du musst zu jeder Zeit nur wissen, was sich in deiner Datei befindet, und du musst dir niemals Gedanken darüber machen, welches Element aus einer anderen Datei Einfluss darauf hat, wie der Code ausgeführt wird. Aber wir sind damit nicht allein; Vue und Svelte haben beide die Idee vorangetrieben und popularisiert, dass Markup und Styles in ein und derselben Komponenten-Datei gut zusammenpassen. [Du kannst verschiedene Belange immer noch gut voneinander trennen][peace-on-css], sogar wenn Markup, Styles und Logik in einer Datei enthalten sind. Und tatsächlich ist es genau das, was Komponeten-Design so mächtig macht! Du kannst also einfach CSS schreiben ohne fürchten zu müssen, dass du einen Namen verwendest, der bereits von einer anderen Komponente in der App verwendet wird. - -#### Utility-CSS - -Vor Kurzem gab es eine Debatte über die ausschließliche Verwendung von Komponenten-Styles im Scope vs. die ausschließliche Verwendung von Utility-CSS. Aber wir stimmen Leuten wie Sarah Dayan zu, die fragen, [warum können wir nicht beides haben][utility-css]? Tatsache ist doch, dass während es großartig ist, Styles im Scope der Komponente zu haben, es immer noch hunderte von Male vorkommt, dass wenn die Website vollständig zusammengesetzt ist, zwei Elemente nicht _gut_ zusammenspielen und eines von beiden einen kleinen Stupser braucht. Oder es wird vielleicht eine abweichende Behandlung eines Textes in einer Komponenten-Instanz benötigt. - -Zwar ist die Vorstellung von perfekten, makellosen Komponenten schön, aber sie ist auch unrealistisch. Kein Design-System ist absolut perfekt, und jedes Design-System zeigt auch Ungereimtheiten. Und es passiert bei dem Versuch diese Ungereimtheiten aufzulösen, dass Komponenten ohne Utility-CSS durcheinander geraten. Utility-CSS ist großartig darin kleinere Optimierungen hinzuzufügen, um die Website fertigzustellen und ausliefern zu können. Aber es ist an sich auch unvollständig auf ganz eigene Art - wenn du z. B. jemals versuchst responsive Styles oder Fokussierungen mit Utility-CSS zu verwalten, kann das schnell zu einem großen Durcheinander werden! -**Utility-CSS funktioniert am besten in Partnerschaft mit Styles im Scope der Komponente**. Und um so leicht wie möglich anwendbar zu sein, sollte Utility-CSS global sein (und sollte möglicherweise auch das einzige globale CSS sein - vielleicht neben reset.css), so dass du nicht mit Importen arbeiten musst, die allesamt willkürlich sind. - -Einige größere Probleme, die am besten mit Utility-CSS gelöst werden, sind: - -- [margin](https://github.com/drwpow/sass-utils#-margin--padding) -- [padding](https://github.com/drwpow/sass-utils#-margin--padding) -- [text- und background-color](https://github.com/drwpow/sass-utils#-color) -- [font-size und font-family](https://github.com/drwpow/sass-utils#%F0%9F%85%B0%EF%B8%8F-font--text) -- [Standardelement-Styling](https://github.com/kognise/water.css) - -In Astro empfehlen wir folgendes Setup hierfür: - -```html -<head> - <link rel="stylesheet" href={Astro.resolve("../styles/global.css")} > -</head> -``` - -Und in deinem lokalen Dateisystem kannst du natürlich auch Sass' [@use][sass-use] verwenden, um Dateien umstandslos miteinander zu kombinieren: - -``` -├── src/ -│ └── styles/ -│ ├── _base.scss -│ ├── _tokens.scss -│ ├── _typography.scss -│ ├── _utils.scss -│ └── global.scss -``` - -Was in jeder dieser Dateien stehen sollte, musst du selbst bestimmen, aber es lohnt sich, klein anzufangen. Füge Utilities immer erst hinzu, sobald du sie benötigst, und du wirst dein CSS-Gewicht unglaublich gering halten können. Und Utilities die du selbst geschrieben hast, um deinen realen Bedarf zu erfüllen, werden immer besser sein als etwas aus dem Regal. - -Zusammengefasst kannst du dir Styles im Scope der Komponente als das Rückgrat deiner gesamten Styles vorstellen, was etwa 80% ausmacht - und die fehlenden 20% füllen CSS-Utilities. Beide funktionieren gut im Tandem und gleichen gegenseitig ihre Schwächen aus. - -💁 **Warum dies in Astro gut funktioniert**: Astro wurde um die Idee von **"Scoped-CSS und globales Utility-CSS leben harmonisch zusammen** ♥️!" herum entwickelt. Nutze das so gut du kannst. - -### Weitere Vorschläge - -"Aber halt!", wirst du vielleicht sagen, nachdem du den vorherigen Abschnitt gelesen hast. "Das berücksichtigt nicht [meinen Anwendungsfall]!" Wenn du nach weiteren Ratschlägen zu einigen gängigen Styling-Problemen suchst, könnten dich die folgenden Vorschläge ineteressieren. Sie stehen alle miteinander in Verbindung und passen zu der Philosophie von **Hybrides Scoped-CSS + Utility-CSS**. - -1. Unterteile deine App in Layout-Komponenten und Basis-Komponenten -2. Vermeide Flexbox- und Grid-Bibliotheken (schreibe deine eigenen!) -3. Vermeide die Verwendung von `margin` in Wrappern für Komponenten -4. Vermeide globale Media-Queries - -#### Vorschlag #1: Unterteile deine App in Layout-Komponenten und Basis-Komponenten - -Sicher wird diese Anleitung niemals lang genug sein, um die Frage zu beantworten _"Wie sollte eine Seite aufgebaut sein?"_ (das ist ein [Design-Problem!][cassie-evans-css]). -Und doch liegt darin versteckt auch eine etwas spezifischere Frage, die wir beantworten _können_: _"Ein bestimmtes Layout angenommen - wie sollten Komponenten und Styles darin organisiert sein?"_ Die Antwort ist, **brenne niemals das Layout in Komponenten ein**. Erzeuge Layout-Komponenten, die das Layout bestimmen, und Basis-Komponenten (Buttons, Karten etc.) die nicht das Layout bestimmen. _Was bedeutet das?_ Gehen wir das an einem Beispiel durch, damit es klarer wird. Angenommen wir haben eine Seite, die folgendermaßen aussieht (die Zahlen stehen für unterschiedliche Komponenten): - -``` -|---------------| -| 1 | -|-------+-------| -| 2 | 2 | -|---+---|---+---| -| 3 | 3 | 3 | 3 | -|---+---+---+---| -| 3 | 3 | 3 | 3 | -|---+---+---+---| -``` - -Das Layout besteht aus einem riesig großen Post über die gesamte Breite, gefolgt von Posts mit halber Breite darunter. Und darunter wollen wir einen Haufen kleinerer Posts, die den Rest der Seite auffüllen. Der Einfachheit halber nennen wir sie `<RiesenPost>` (1), `<HalbePosts>` (2), und `<KleinePosts>` (3). Wir fügen sie wie folgt unserer Seite hinzu: - -```astro ---- -// src/pages/index.astro - -import Nav from '../components/Nav.astro'; -import RiesenPost from '../components/RiesenPost.astro'; -import Grid from '../components/Grid.astro'; -import HalbePosts from '../components/HalberPost.astro'; -import KleinePosts from '../components/KleinerPost.astro'; -import Footer from '../components/Footer.astro'; ---- -<html> - <body> - <Nav /> - - <Grid> - <RiesenPost /> - <HalbePosts /> - <KleinePosts /> - </Grid> - - <Footer /> - </body> -</html> -``` - -Das ist _anscheinend_ sauber voneinander getrennt, aber der Schein kann trügen. Auf den ersten Blick nehmen wir vielleicht an, dass `<Grid>` das Layout kontrolliert, aber dieser Eindruck täuscht. Tatsächlich bestimmt `<RiesenPost>` seine Breite selbst, `<HalbePosts>` lädt zwei Komponenten und bestimmt die eigene Breite, und `<KleinePosts>` lädt vier oder mehr Komponenten und bestimmt seine eigene Breite. Insgesamt - `<Grid>` eingeschlossen - streiten sich **vier Komponenten** um dasselbe Layout. Entferne einen Post von `<HalbePosts>` und das Layout zerbricht. Bearbeite `<RiesenPost>`, das Layout zerbricht. Bearbeite `<Grid>`, das Layout zerbricht. Wenn du es dir genau überlegst, ist keine dieser Komponenten wirklich wiederverwendbar - sie könnten auch einfach in einer einzigen großen Datei stehen. - -Das ist tatsächlich das **Problem mit globalem CSS** in hübscher Verkleidung - mehrere Komponenten kämpfen darum, wie sie angeordnet werden, ohne dass es ein Layout in zentraler Verantwortung gibt (in der Art wie globales CSS)! Nun, da wir das Problem identifiziert haben, bestünde eine Möglichkeit es zu lösen darin, das gesamte Layout auf die oberste Ebene zu heben und dort ebenfalls alle Komponenten zu laden: - -```astro ---- -// src/pages/index.astro - -import Nav from '../components/Nav.astro'; -import RiesenPost from '../components/RiesenPost.astro'; -import HalbePosts from '../components/HalberPost.astro'; -import KleinePosts from '../components/KleinerPost.astro'; -import Footer from '../components/Footer.astro'; ---- - -<html> - <head> - <style lang="scss"> - .wrapper { - max-width: 60rem; - margin-right: auto; - margin-left: auto; - padding-right: 2rem; - padding-left: 2rem; - } - - .grid { - display: grid; - grid-gap: 1.5rem; - grid-template columns: 1fr 1fr 1fr 1fr; - } - - .riesen-post { - grid-column: span 4; - } - - .halber-post { - grid-column: span 2; - } - - .kleiner-post { - grid-column: span 1; - } - </style> - </head> - <body> - <Nav /> - - <div class="wrapper"> - <div class="grid"> - <div class="riesen-post"><RiesenPost postId={12345} /></div> - - <div class="halber-post"><HalberPost postId={12345} /></div> - <div class="halber-post"><HalberPost postId={12345} /></div> - - <div class="kleiner-post"><KleinerPost postId={12345} /></div> - <div class="kleiner-post"><KleinerPost postId={12345} /></div> - <div class="kleiner-post"><KleinerPost postId={12345} /></div> - <div class="kleiner-post"><KleinerPost postId={12345} /></div> - <div class="kleiner-post"><KleinerPost postId={12345} /></div> - <div class="kleiner-post"><KleinerPost postId={12345} /></div> - <div class="kleiner-post"><KleinerPost postId={12345} /></div> - <div class="kleiner-post"><KleinerPost postId={12345} /></div> - </div> - </div> - - <Footer /> - </body> -</html> -``` - -Einmal davon abgesehen, dass das mehr Code ist, bedeutet es tatsächlich eine viel klarere Trennung. Was zuvor ein 4-Komponenten-Layout war, wird nun zu 100% innerhalb der `index.astro`-Datei auf der obersten Ebene verwaltet (welche wir nun als **Layout-Komponente** betrachten - und wenn wir es weiterverwenden wollten, könnten wir es auch in eine eigene Datei extrahieren). Dein Layout ist jetzt zentralisiert, und die Komponenten sind nun wirklich wiederverwendbar, da es ihnen komplett egal ist, ob sie sich mit den anderen im selben Grid befinden oder nicht. Du kannst in jeder dieser Dateien die Styles bearbeiten ohne Gefahr zu laufen, dadurch Styles in anderen zu stören. - -Die Grundregel beim Arrangieren mehrerer Komponenten lautet, **es handelt sich um eine besondere Verantwortung**, die an einem zentralen Ort wahrgenommen werden sollte, anstatt über vier Komponenten hinweg, wie wir es angelegt hatten. Und tatsächlich sind Seiten auf der obersten Ebene sehr gut darin und sie sollten dir stets als Ausgangspunkt für deine Layout-Komponenten dienen. Probiere aus, wie weit du damit kommst, und extrahiere nur dann Layout-Komponenten hieraus, wenn es absolut notwendig ist. - -Zusammengefasst: **Wenn du mehrere Dateien anfassen musst, um dein Layout zu ändern, solltest du vielleicht alles gmeinsam in einer einzelnen Layout-Komponente neu organisieren.** - -💁 **Warum das in Astro gut funktioniert**: In Astro kann alles eine `.astro`-Komponente sein, und du bekommst niemals Performance-Probleme, gleichgültig wieviele Komponenten du hinzufügst. Aber der größte Vorteil beim Einsatz von [Layout-Isolierung][layout-isolated] besteht in den Einsparungen bei der Menge an CSS, die du benötigst. - -#### Vorschlag #2: Vermeide Flexbox- und Grid-Bibliotheken (schreibe deine eigenen!) - -Es mag sich sehr übergriffig anfühlen, wenn dir gesagt wird, du solltest deine geliebte Layout-Bibliothek, mit der du gut vertraut bist, nicht verwenden. Immerhin hat sie dich bis hierher gebracht! Aber die Zeiten von [Float-Madness](https://zellwk.com/blog/responsive-grid-system/) sind vorbei, ersetzt durch Flexbox und Grid - und um die zu verwalten brauchen wir keine Bibliotheken (Bibliotheken können die Aufgabe sogar erschweren). - -Viele Front-End-Entwicklerinnen und -Entwickler kennen den folgenden Gedankengang: - -1. Ich sollte soviel CSS wie möglich mehrfach verwenden (_gut!_) -2. Viele Seiten verwenden dasselbe Layout (_hmm?_) -3. Ich könnte eine bereits bestehende Lösung einsetzen, um meine gesamten Layout-Duplikate zu verwalten (_Moment mal!_) - -Während die Logik in sich stimmig ist, ist es in Wirklichkeit doch so, dass #2 nur selten auf ein Projekt zutrifft. Möglicherweise wurden viele Teile der Website nicht entwickelt, um in diese netten, gepflegten 12-Säulen-Raster einer Bibliothek zu passen. Sogar relativ bescheidene Websites können _hunderte_ Layouts enthalten, wenn du sämtliche Breakpoints mit einrechnest. Frage dich einmal selbst: _Wenn die Website, die ich baue, wirklich soviele unterschiedliche Layouts beinhaltet, warum verwende ich dann eine schwergewichtige Grid-Bibliothek, die mir nur generische Layouts ermöglicht?_ - -Ein paar gut geschriebene Zeilen CSS-Grid hier und da werden sich perfekt an jede Situation anpassen; das Ganze ist höchstwahrscheinlich leichtgewichtiger und einfacher zu verwalten, als die schwergewichtige Bibliothek, mit der du doch so lange gekämpft hast. Anders herum betrachtet: Wenn du schon einige Stunden benötigst, um eine proprietäre Styling-Bibliothek zu lernen, dich mit ihr auseinanderzusetzen, Probleme zu melden etc., wäre es nicht besser diese Zeit darauf zu verwenden den Umgang mit Flexbox und Grid zu erlernen? Viele Leute brauchen nur eine Stunde, um die Grundlagen ausreichend zu verstehen - und damit kommt man schon ziemlich weit! Es gibt großartige kostenlose Lernmöglichkeiten, in die du deine Zeit investieren kannnst: - -- [Flexbox Froggy](https://flexboxfroggy.com/) -- [CSS Grid Garden](https://cssgridgarden.com/) - -Kurz gesagt: Hör auf Layouts zu vereinfachen, wenn da nichts zu vereinfachen ist! Du wirst sehen, dass nicht nur deine Styles leichter zu organisieren, sondern dein CSS auch leichter und die Ladezeiten kürzer sind. - -💁 **Warum das in Astro gut funktioniert**: Grid-Bibliotheken sind ein einfacher und schneller Weg, um Stylesheets aufzublähen - und damit auch ein wesentlicher Beitrag zum Gebrauch von [Treeshaking][css-treeshaking], um überflüssige Styles wieder loszuwerden. Astro verwendet **kein** Treeshaking, um ungenutztes CSS für dich zu entfernen, da dies zu [Problemen][css-treeshaking] führen kann. Wir sagen nicht, dass du vollständig ohne Bibliotheken arbeiten sollst; wir sind große Fans von einigen Bibliotheken, wie zum Beispiel [Material UI][material-ui]. Aber wenn du zumindest die abertausende Layouts, die du nicht verwendest, aus deiner Bibliothek entfernen kannst, musst du später möglicherweise auch kein automatisches Treeshaking einsetzen. - -#### Vorschlag #3: Vermeide die Verwendung von `margin` in Wrappern für Komponenten - -Anders ausgedrückt, tu Folgendes nicht: - -```astro -<!-- src/components/MeineKomponente.astro --> -<style lang="scss"> - .wrapper { - /* ❌ Tu das nicht! */ - margin-top: 3rem; - } -</style> - -<div class="wrapper"></div> -``` - -Wenn du dir das [CSS-Box-Model][box-model] vor Augen führst, dehnt sich darin `margin` stets über die Grenzen einer Box hinweg aus. Das bedeutet, wenn du `margin` auf das äußerste Element deiner Komponente anwendest, wird dies die Position angrenzender Komponenten beeinflussen. Selbst wenn die Styles im Scope der Komponete sind, betreffen sie _technisch_ auch Elemente um die Komponente herum - somit bricht dies mit dem [Konzept der Einschließung von Styles][layout-isolated]. - -Wenn du Komponenten verwendest, die sich neu arrangieren oder anders dargestellt werden, sobald sie sich in der Nähe anderer Komponenten befinden, bedeutet dies einen Kampf, den du nur schwer gewinnen kannst. **Komponenten sollten sich identisch verhalten und aussehen, unabhängig davon wo sie platziert werden.** Das ist es, was sie zu Komponenten macht! - -💁 **Warum das in Astro gut funktioniert**: `margins` die andere Komponenten herumschubsen, unterwandern deine Styling-Architektur auf heimtückische Weise, und das kann zu wackeligen oder brüchigen Layout-Komponenten führen. Solche Dinge grundsätzlich zu vermeiden, erlaubt dir deine Layout-Komponenten einfach zu halten - und du wirst weniger Zeit mit Styling zubringen. - -#### Vorschlag #4: Vermeide globale Media-Queries - -Dieser letzte Punkt behandelt eine natürliche Beschränkung von **Styles im Scope**. Und diese bezieht sich auch auf Breakpoints! Du kennst diesen einen, seltsamen Breakpoint, bei dem deine `<Card />`-Komponente bei einer bestimmten Größe ungünstig umbricht? Du solltest dieses Problem innerhalb von `<Card />` lösen, und nicht _irgendwo_ anders. - -Selbst wenn du am Ende einen willkürlichen Wert wie `@media (min-width: 732px)` verwendest, wird das wahrscheinlich besser funktionieren, als es irgendwo mit einer _globalen_ [magischen Zahl][magic-number] zu probieren, die aber doch nur _in einem einzigen Kontext_ angewandt wird (eine willkürliche Zahl mag für den Rest der Anwendung "rätselhaft" sein, aber sie hat immer noch eine "konkrete" Bedeutung im Kontext einer Komponente, die diesen Wert benötigt). - -Zugegeben, diese Art von Konflikt vollständig zu lösen war bisher nahezu unmöglich; glücklicherweise gibt es inzwischen wachsende [Unterstützung für Container-Queries!][container-queries]. - -Ein weiterer Anlass zur Beschwerde bei diesem Ansatz liegt in der Frage, "_Was ist aber, wenn ich zwei Komponenten habe, die dasselbe am selben Breakpoint tun?_", worauf ich antworten würde: Ein oder zwei solcher Punkte wird es immer geben; behandle sie einfach wie _Sonderfälle_. Wenn aber deine gesamte Anwendung aus Dutzenden solcher Fälle besteht, solltest du versuchen die Unterteilung deiner Komponenten so zu verändern, dass sie grundsätzlich deine [Layout-Isolierung][layout-isolated] besser unterstützen. - -💁 **Warum das in Astro gut funktioniert**: Dies ist wahrscheinlich der am wenigsten wichtige Punkt, weshalb er auch am Ende steht. Tatsächlich kannst du ihn auch überspringen, wenn er so für dich keine Rolle spielt. Aber es handelt sich um etwas, dem Leute versuchen in größerem Umfang Rechnung zu tragen - und dafür ein _globales_ System zu verwenden kann auch vollkommen unnötig sein. Versuche einmal _nicht_ auf globale Media-Queries ausgerichtet zu entwickeln - und schau wie weit du damit kommst! - -### 👓 Weitere Lektüre - -Diese Anleitung wäre nicht möglich ohne die folgenden Blogposts, die auf diese Themen eingehen und sie vertiefend erklären. Bitte lies sie - es lohnt sich! - -- [**Layout-isolated Components**][layout-isolated] von Emil Sjölander -- [**In defense of utility-first CSS**][utility-css] von Sarah Dayan - -Wirf bitte auch einen Blick auf das [Stylelint][stylelint]-Projekt, mit dem du deine Styles in Form bringen kannst. Du bringst dein JS in Form, warum nicht auch dein CSS? - -[autoprefixer]: https://github.com/postcss/autoprefixer -[astro-component]: /de/core-concepts/astro-components#css-styles -[astro-resolve]: /reference/api-reference#astroresolve -[bem]: http://getbem.com/introduction/ -[box-model]: https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/The_box_model -[browserslist]: https://github.com/browserslist/browserslist -[browserslist-defaults]: https://github.com/browserslist/browserslist#queries -[cassie-evans-css]: https://twitter.com/cassiecodes/status/1392756828786790400?s=20 -[container-queries]: https://ishadeed.com/article/say-hello-to-css-container-queries/ -[css-modules]: https://github.com/css-modules/css-modules -[css-treeshaking]: https://css-tricks.com/how-do-you-remove-unused-css-from-a-site/ -[fouc]: https://en.wikipedia.org/wiki/Flash_of_unstyled_content -[layout-isolated]: https://web.archive.org/web/20210227162315/https://visly.app/blogposts/layout-isolated-components -[less]: https://lesscss.org/ -[issues]: https://github.com/withastro/astro/issues -[magic-number]: https://css-tricks.com/magic-numbers-in-css/ -[material-ui]: https://material.io/components -[peace-on-css]: https://didoo.medium.com/let-there-be-peace-on-css-8b26829f1be0 -[sass]: https://sass-lang.com/ -[sass-use]: https://sass-lang.com/documentation/at-rules/use -[smacss]: http://smacss.com/ -[styled-components]: https://styled-components.com/ -[stylus]: https://stylus-lang.com/ -[styled-jsx]: https://github.com/vercel/styled-jsx -[stylelint]: https://stylelint.io/ -[svelte-style]: https://svelte.dev/docs#style -[tailwind]: https://tailwindcss.com -[tailwind-utilities]: https://tailwindcss.com/docs/adding-new-utilities#using-css -[utility-css]: https://frontstuff.io/in-defense-of-utility-first-css -[vite-preprocessors]: https://vitejs.dev/guide/features.html#css-pre-processors -[vue-css-modules]: https://vue-loader.vuejs.org/guide/css-modules.html -[vue-scoped]: https://vue-loader.vuejs.org/guide/scoped-css.html diff --git a/docs/src/pages/de/installation.md b/docs/src/pages/de/installation.md deleted file mode 100644 index e1611495f..000000000 --- a/docs/src/pages/de/installation.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -layout: ~/layouts/MainLayout.astro -title: Installation -description: So installierst du Astro mit NPM, PNPM oder Yarn. ---- - -Es gibt verschiedene Möglichkeiten Astro mit einem neuen Projekt zu installieren. - -## Vorbereitungen - -- **Node.js** - `v14.15.0`, `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) -- **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 ebenso [`yarn`](https://yarnpkg.com/) oder [`pnpm`](https://pnpm.io/) verwenden, falls du eine npm-Alternative bevorzugst. - -## Astro-Projekt erzeugen - -`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 -# Mit NPM -npm init astro - -# Yarn -yarn create astro - -# Pnpm -pnpm create astro -``` - -Der [`create-astro`](https://github.com/withastro/astro/tree/main/packages/create-astro)-Assistent lässt dich aus einer Reihe von [Start-Vorlagen](https://github.com/withastro/astro/tree/main/examples) auswählen. Alternativ könntest du auch dein eigenes Astro-Projekt direkt aus GitHub heraus importieren. - -```bash -# Hinweis: Ersetze "mein-astro-projekt" durch den Namen deines Projekts. - -# npm 6.x -npm init astro mein-astro-projekt --template starter -# npm 7+ (zusätzliche Bindestriche sind erforderlich) -npm init astro mein-astro-projekt -- --template starter -# yarn -yarn create astro mein-astro-projekt --template starter -# pnpm -pnpm create astro mein-astro-projekt -- --template starter -# Verwenden einer Drittanbietervorlage -npm init astro mein-astro-projekt -- --template [GITHUB_NAME]/[REPO_NAME] -# Verwenden einer Drittanbietervorlage innerhalb eines Repos -npm init astro mein-astro-projekt -- --template [GITHUB_NAME]/[REPO_NAME]/pfad/zur/vorlage -``` - -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 -npm install -``` - -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 - -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. - -### Setze dein Projekt auf - -```bash -# Verzeichnis erzeugen und in das Verzeichnis wechseln -mkdir mein-astro-projekt -cd mein-astro-projekt -``` - -Erstelle ein leeres Verzeichnis mit dem Namen deines Projekts und navigiere dann dorthin. - -### Erzeuge `package.json` - -```bash -# Dieser Befehl erstellt eine grundlegende package.json-Datei für dich -npm init --yes -``` - -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. - -### Installiere Astro - -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 -npm install astro -``` - -Jetzt kannst du den Platzhalter im Abschnitt "scripts" deiner `package.json`-Datei, die `npm init` für dich erstellt hat, durch Folgendes ersetzen: - -```diff - "scripts": { -- "test": "echo \"Error: no test specified\" && exit 1" -+ "dev": "astro dev", -+ "build": "astro build", -+ "preview": "astro preview" - }, -} -``` - -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 - -Öffne deinen bevorzugten Texteditor und erstelle eine neue Datei in deinem Projekt: - -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. - -```astro ---- -// JS/TS-Code, der zwischen den (---) Bindestrichen geschrieben wurde, -// wird ausschließlich auf dem Server ausgeführt! -console.log('Du siehst mich im Terminal') ---- - -<html> - <body> - <h1>Hello, World!</h1> - </body> -</html> - -<style lang='css||scss'> - body{ - h1{ - color:orange; - } - } -</style> - -<script> - // Hier eingegebener JS-Code wird ausschließlich im Browser ausgeführt - console.log('Du siehst mich in den devTools') -</script> -``` - -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 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. - -## [Starte Astro](#start-astro) - -```bash -npm run dev -``` - -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. - -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 -devOptions: { - hostname: '0.0.0.0'; -} -``` - -## [Kompiliere dein Projekt](#build-astro) - -Führe in deinem Projektverzeichnis den folgenden Befehl im Terminal aus: - -```bash -npm run build -``` - -Dies weist Astro an deine Site zu erstellen und direkt zu speichern. Deine Anwendung steht nun im `dist/`-Verzeichnis bereit. - -## Nächste Schritte - -Geschafft! Du kannst jetzt mit dem Entwickeln beginnen! - -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 die Projektstruktur in Astro in unserem [Artikel zur Projektstruktur](/de/core-concepts/project-structure) - -📚 Lerne mehr über die Komponenten-Syntax in Astro in unserem [Artikel zu Astro-Komponenten](/de/core-concepts/astro-components) - -📚 Lerne mehr über das dateibasierte Routing in Astro in unserem [Artikel zu Astro-Seiten](/de/core-concepts/astro-pages) und unserem [Artikel über Routing](/de/core-concepts/routing). diff --git a/docs/src/pages/de/migration/0.21.0.md b/docs/src/pages/de/migration/0.21.0.md deleted file mode 100644 index 3d8409ded..000000000 --- a/docs/src/pages/de/migration/0.21.0.md +++ /dev/null @@ -1,229 +0,0 @@ ---- -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 unter 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 diff --git a/docs/src/pages/de/quick-start.md b/docs/src/pages/de/quick-start.md deleted file mode 100644 index aa0b0a43d..000000000 --- a/docs/src/pages/de/quick-start.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -layout: ~/layouts/MainLayout.astro -title: Schnellstart -description: Die einfachste Weg schnell mit Astro loszulegen. ---- - -```shell -# Vorbereitung: Überprüfe, ob Node.js die Version 14.15.0+, oder 16+ ist -node --version - -# Erstelle einen neues Projektverzeichnis und navigiere direkt dorthin -mkdir mein-astro-projekt && cd $_ - -# Bereite dich auf den Start vor -npm init astro - -# Installiere benötigte Pakete -npm install - -# Beginne mit dem Entwickeln! -npm run dev -``` - -Export - fertig zum Veröffentlichen: - -```shell -# Wenn du soweit bist, exportiere deine Site nach `dist/` -npm run build -``` - -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, werfe einen Blick auf die [komplette Liste der Beispiele](https://github.com/withastro/astro/tree/main/examples) auf GitHub. -Du kannst jedes dieser Beispiele ausprobieren, indem du `npm init astro -- --template "BEISPIEL_NAME"` ausführst. - -## Starte dein Projekt - -In deinem Projektverzeichnis führe den folgenden Befehl in deinem Terminal aus: - -```bash -npm run dev -``` - -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 wird nun auf alle Änderungen in deinem `src/`-Verzeichnisch lauschen, sodass du deine Anwendung nicht nach jeder Änderung neu starten musst. - -## Kompiliere dein Projekt - -In deinem Projektverzeichnis führe den folgenden Befehl in deinem Terminal aus: - -```bash -npm run build -``` - -Dies weist Astro an deine Site zu erstellen und direkt zu speichern. Deine Anwendung steht nun im `dist/`-Verzeichnis bereit. - -## Veröffentliche dein Projekt - -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/) -- [Google Firebase](https://firebase.google.com/) -- [Netlify](https://www.netlify.com/) -- [Vercel](https://vercel.com/) -- [Erfahre mehr über das Veröffentlichen von Astro-Builds](/guides/deploy). - -## Nächste Schritte - -Geschafft! Du kannst jetzt mit dem Entwickeln beginnen! - -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 die Projektstruktur in Astro in unserem [Artikel zur Projektstruktur](/de/core-concepts/project-structure) - -📚 Lerne mehr über die Komponenten-Syntax in Astro in unserem [Artikel zu Astro-Komponenten](/de/core-concepts/astro-components) - -📚 Lerne mehr über das dateibasierte Routing in Astro in unserem [Artikel zu Astro-Seiten](/de/core-concepts/astro-pages) und unserem [Artikel über Routing](/de/core-concepts/routing). diff --git a/docs/src/pages/de/themes.astro b/docs/src/pages/de/themes.astro deleted file mode 100644 index b33fe3c03..000000000 --- a/docs/src/pages/de/themes.astro +++ /dev/null @@ -1,53 +0,0 @@ ---- -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> |