Astro getStaticPaths einfach erklärt

Astro getStaticPaths ist die Funktion, die Sie verwenden, um Astro mitzuteilen, welche dynamischen Seiten während eines statischen Builds generiert werden sollen. Wenn eine Routen-Datei Klammern verwendet, wie [slug].astro oder [category]/[product].astro, benötigt Astro eine vollständige Liste von Parameterwerten, bevor es die finalen Seiten schreiben kann.

Das ist wichtig, weil es ein Routenmuster in echte URLs umwandelt, ohne zur Laufzeit raten zu müssen. Ein Blog, ein Produktkatalog oder eine Dokumentationsseite kann als statisches HTML ausgeliefert werden und gleichzeitig Hunderte oder Tausende von einzigartigen Seiten unterstützen.

Wichtigste Erkenntnisse

• Dynamische Dateinamen definieren die Routenstruktur; getStaticPaths liefert die tatsächlichen Werte.
• Jedes Params-Objekt muss genau mit den Routen-Dateinamen übereinstimmen, einschließlich mehrerer Parameter.
• Statische Builds benötigen die vollständige Routeliste im Voraus; SSR verwendet nicht getStaticPaths.
• Props können seiten-spezifische Daten in die Vorlage tragen, was den Seiten-Code sauberer hält.
• Restparameter ermöglichen es, dass eine Routen-Datei geschachtelte Pfade abdeckt, aber sie benötigen eine sorgfältige Datenstrukturierung.

Was ist das?

Astro getStaticPaths ist eine Funktion, die von einer dynamischen Seiten-Datei exportiert wird und die Menge der Routenparameter zurückgibt, die Astro erstellen soll. Im statischen Ausgabemodus kann Astro nicht raten, welche Seiten allein aus einem Dateinamen existieren sollen, daher fungiert getStaticPaths als die Quelle der Wahrheit für diese Seiten.

Ein einfaches Beispiel ist eine Datei wie src/pages/dogs/[dog].astro. Der Dateiname sagt, dass die Route ein dynamisches Segment hat, aber er sagt nicht, welche Hundeseiten existieren. getStaticPaths könnte Parameter für clifford, rover und spot zurückgeben, und Astro generiert /dogs/clifford, /dogs/rover und /dogs/spot.

Der wichtige Teil ist, dass die Routen-Datei und das Params-Objekt übereinstimmen müssen. Wenn der Dateiname [dog] verwendet, müssen die zurückgegebenen Parameter dog enthalten. Wenn der Dateiname [lang]/[version]/info.astro verwendet, müssen die zurückgegebenen Parameter sowohl lang als auch version für jede generierte Route enthalten.

In der Praxis ist dies die Brücke zwischen Inhaltsdaten und URLs. Ein Händler könnte eine Sammlung von Landingpages für Produktkategorien haben, während ein Entwickler eine Dokumentationsseite mit einer Seite pro API-Referenzeintrag haben könnte. getStaticPaths ermöglicht es beiden Teams, die Inhalte strukturiert zu halten und gleichzeitig statische Seiten auszuliefern.

Es ist auch wichtig, die Routen-Definition von den Seiteninhalten zu trennen. Der Dateiname definiert die URL-Struktur, aber getStaticPaths definiert die tatsächlichen Instanzen dieser Struktur. Diese Unterscheidung sorgt dafür, dass Astros statisches Routing vorhersehbar ist: Die Route wird nicht zur Anfragezeit entdeckt, sondern wird aus bekannten Daten während des Builds zusammengestellt.

Warum es wichtig ist – geschäftliche und technische Auswirkungen

Für Händler und Entwickler ist der geschäftliche Wert von astro getStaticPaths Vorhersehbarkeit. Wenn Seiten zur Build-Zeit generiert werden, kann die Seite schnell, cachebar und leichter nachvollziehbar sein. Sie wissen, welche URLs vor der Bereitstellung existieren, was bei der Inhaltsplanung, QA und SEO-Überprüfungen hilft.

Diese Vorhersehbarkeit reduziert auch die Laufzeit-Arbeit. Anstatt den Server zu bitten, jede Route bei jeder Anfrage zu entdecken, kann Astro die Seiten im Voraus schreiben. Für inhaltsreiche Seiten bedeutet dies oft einfacheres Hosting und weniger bewegliche Teile bei Traffic-Spitzen.

Es gibt auch eine Such- und Betriebsseite. Statische Seiten sind leichter auf gebrochene Links, doppelte Routen und fehlende Inhalte zu überprüfen. Wenn Ihre Seitenstruktur von einem CMS, Produktkatalog oder Inhaltskollektionen abhängt, gibt Ihnen getStaticPaths einen kontrollierten Weg, um Datensätze in Seiten zu übersetzen.

Die technischen Auswirkungen sind ebenso wichtig. Dynamische Routen sind leistungsfähig, können jedoch zerbrechlich werden, wenn die Routen-Daten inkonsistent sind. Ein fehlender Parameter, ein unerwartetes Slug-Format oder eine Diskrepanz zwischen Dateinamen und zurückgegebenen Objekten können Builds brechen. Sobald das Muster verstanden ist, wird getStaticPaths jedoch zu einem zuverlässigen Fundament für große statische Seiten.

Für Teams, die Inhalte in großem Maßstab bereitstellen, verbessert dies auch die Zusammenarbeit. Redakteure können in Bezug auf Datensätze und Slugs denken, während Entwickler in Bezug auf Routen-Dateien und Vorlagen denken können. getStaticPaths ist der Vertrag zwischen diesen beiden Ansichten. Wenn dieser Vertrag klar ist, wird es einfacher, neue Inhaltstypen hinzuzufügen, Abschnitte neu zu organisieren oder Seiten zu lokalisieren, ohne das gesamte Rendering-Modell zu ändern.

Ein praktischer geschäftlicher Vorteil ist das Vertrauen in Veröffentlichungen. Wenn die Routeliste aus einer bekannten Quelle generiert wird, können Sie die Ausgabe vor dem Start überprüfen und fehlende Seiten finden, bevor es die Benutzer tun. Das ist besonders nützlich für saisonale Kampagnen, Dokumentationsupdates und Katalogaktualisierungen, bei denen ein gebrochenes URL sowohl den Traffic als auch das Vertrauen beeinträchtigen kann.

Ein weiterer Grund, warum es wichtig ist, ist, dass es Leistungsentscheidungen sichtbar hält. Wenn eine Seite vorab gebaut werden muss, muss das Team diese Entscheidung absichtlich treffen, anstatt das Routing-Verhalten im Laufe der Zeit driften zu lassen. Das schafft eine sauberere Architekturüberprüfung: statische Seiten für stabile Inhalte, SSR für anfragegesteuerte Inhalte und eine klare Grenze zwischen den beiden. In größeren Teams verhindert diese Grenze versehentliche Komplexität, wie das Hinzufügen von Live-Datenabhängigkeiten zu einer Seite, die statisch bleiben sollte.

Wie es funktioniert – den Mechanismus Schritt für Schritt erklären

Astro-Routing beginnt mit dem Dateisystem. Eine Seiten-Datei innerhalb von src/pages/ wird zu einer Route, und geklammerte Segmente kennzeichnen dynamische Teile des Pfades. Eine Datei namens [slug].astro kann viele URLs zuordnen, aber nur, wenn Astro weiß, welche Slugs zu bauen sind.

Der Build-Prozess ruft dann getStaticPaths auf. Diese Funktion gibt ein Array von Objekten zurück, wobei jedes Objekt eine Params-Eigenschaft enthält. Diese Params-Werte werden in das Routenmuster eingefügt, wobei eine generierte Seite pro Objekt entsteht.

Wenn die Routen-Datei mehrere dynamische Segmente enthält, muss jedes Params-Objekt jeden erforderlichen Schlüssel enthalten. Zum Beispiel benötigt eine Route wie [lang]/[version]/info.astro sowohl lang als auch version. Wenn Sie nur einen von beiden zurückgeben, hat Astro nicht genügend Informationen, um die Seite zu erstellen.

Astro unterstützt auch Restparameter wie […slug].astro. Dieses Muster ist nützlich, wenn eine Datei geschachtelte Pfade unterschiedlicher Tiefe abgleichen muss. In diesem Fall kann der Slug-Wert ein einzelnes Segment, mehrere Segmente oder sogar undefiniert für die oberste Seite darstellen, je nachdem, wie Sie die zurückgegebenen Daten strukturieren.

Ein nützlicher Aspekt des Routing-Modells ist, dass getStaticPaths auch Props zurückgeben kann. Diese Props werden in die Seitenkomponente eingefügt und können seiten-spezifische Daten wie Titel, Beschreibungen oder vorab geladenen Inhalt halten. Das hält die Vorlage auf das Rendern fokussiert, anstatt wiederholt nach Informationen zu suchen.

Der Mechanismus ist am einfachsten als dreistufige Übergabe zu verstehen: Der Dateiname erklärt das Routenmuster, getStaticPaths liefert die Liste gültiger Parameterwerte und die Seitenvorlage rendert jede generierte Route mit Astro.params und Astro.props. Wenn eines dieser drei Teile nicht übereinstimmt, schlägt der Build fehl oder die Ausgabe ist unvollständig.

In echten Projekten beginnt diese Übergabe oft mit einer Datenquelle wie einem CMS-Export, einer JSON-Datei oder einer Inhaltskollektion. Die Routenfunktion liest die Datensätze, filtert sie und mappt jeden in ein Params-Objekt. Wenn die Seite mehr als die URL benötigt, kann dieselbe Schleife Props anhängen, sodass die Vorlage nicht die Suchlogik wiederholen muss. Diese Trennung hält die Routen-Generierung deterministisch und macht die Seite später einfacher zu warten.

Ein zweiter Mechanismus, den man verstehen sollte, ist, dass die Build-Ausgabe festgelegt ist, sobald die Funktion läuft. Das bedeutet, dass die Routeliste keine Live-Abfrage gegen Ihre Inhaltsquelle ist; sie ist ein Snapshot der Daten zur Build-Zeit. Wenn die Quelle später geändert wird, ändern sich die generierten Seiten nicht, bis der nächste Build erfolgt. Für viele Teams ist das ein Merkmal, kein Nachteil, da es die Bereitstellungen wiederholbar und einfacher überprüfbar macht.

Anwendungsfälle – wo Teams dies tatsächlich anwenden

Der häufigste Anwendungsfall ist eine Inhaltsseite mit einer Seite pro Datensatz. Denken Sie an einen Blog, ein Dokumentationsportal oder eine Ressourcenbibliothek, in der jeder Artikel einen Slug hat. getStaticPaths verwandelt die Liste der Datensätze in eine Liste von Seiten, was genau das ist, wofür die statische Generierung gut ist.

Ein zweiter Anwendungsfall sind Produkt- oder Kategorieseiten. Ein Händler möchte möglicherweise eine Seite für jede Kategorie, Sammlung oder Kampagnenvariante. Wenn diese Routen im Voraus bekannt sind, macht getStaticPaths es einfach, die URLs sauber und die Seiten schnell zu halten.

Ein dritter Anwendungsfall ist mehrsprachiger oder mehrversionierter Inhalt. Wenn Ihre Seite Routen wie /en/v1/info und /fr/v2/info hat, kann getStaticPaths die benötigten Kombinationen aus einer strukturierten Datenquelle generieren. Das ist besonders hilfreich, wenn dieselbe Vorlage mehrere Lokalisierungen oder Dokumentationsversionen bedienen muss.

Inhaltsgetriebene Seiten

Wenn der Inhalt aus einem CMS oder einer lokalen Inhaltsschicht kommt, ist getStaticPaths das Stück, das Datensätze mit URLs abgleicht. Die Routen-Datei definiert das Muster, und die Datenquelle definiert die tatsächlichen Seiten. Dies ist eine natürliche Passform für redaktionelle Seiten, in denen regelmäßig neue Einträge hinzugefügt, aber trotzdem in Chargen veröffentlicht werden.

Katalog- oder Landingpages

Für Handels- oder Portfolio-Webseiten kann die Routen-Generierung die Katalogstruktur widerspiegeln. Eine Kategorieseite, eine Dienstleistungsseite oder eine Präsentationsseite kann jeweils ihren eigenen Slug haben. Wenn Sie bereits in Bezug auf Datensätze und Slugs denken, hält getStaticPaths die Implementierung im Einklang mit diesem mentalen Modell.

Geschachtelte und hierarchische Routen

Restparameter sind nützlich, wenn die Pfadtiefe nicht festgelegt ist. Eine Wissensdatenbank, ein Dateibrowser oder eine geschachtelte Produkt-Taxonomie benötigt möglicherweise URLs, die in einigen Fällen eine Ebene tief und in anderen drei Ebenen tief sind. getStaticPaths kann das handhaben, aber nur, wenn die zurückgegebenen Parameter sorgfältig geformt sind.

Eine nützliche Entscheidungsregel ist, getStaticPaths auszuwählen, wenn die Seitenliste endlich und die URL-Struktur stabil ist. Vermeiden Sie es, wenn der Routenbereich effektiv offen ist, wie bei benutzergenerierten Pfaden, Live-Suchergebnissen oder berechtigungsbasierten Seiten, die nur existieren sollten, nachdem eine Anfrage authentifiziert wurde. In diesen Fällen ist SSR oder ein anderes On-Demand-Muster normalerweise besser geeignet.

Wie man es implementiert oder anwendet – praktische Anleitung

Beginnen Sie damit, zu entscheiden, ob die Routeliste zur Build-Zeit bekannt ist. Wenn ja, ist die statische Generierung eine gute Wahl. Wenn die Routeliste von anfragebasierten Personalisierungen, Live-Inventar oder ständig wechselnden Daten abhängt, benötigen Sie möglicherweise statische Generierung nicht.

Als Nächstes sollten Sie die Routen-Datei an das Inhaltsmodell anpassen. Wenn Ihre Daten ein einzelnes Slug-Feld haben, verwenden Sie [slug].astro. Wenn Ihre Daten hierarchische Felder haben, verwenden Sie mehrere Routen-Segmente. Der Dateiname sollte die Form der Daten widerspiegeln, anstatt die Daten zu zwingen, zu einer unhandlichen Route zu passen.

Schreiben Sie dann getStaticPaths so, dass es ein sauberes Array von Params-Objekten zurückgibt. Halten Sie die Werte einfach und konsistent. Wenn Ihre Quelldaten kodierte Werte oder Sonderzeichen enthalten, normalisieren Sie diese, bevor Sie die Params zurückgeben, damit die generierten URLs stabil und lesbar sind.

Ein praktisches Muster ist, die Datenvorbereitung von der Darstellung zu trennen. Erstellen Sie zuerst die Routeliste und übergeben Sie dann alle zusätzlichen Seiteninformationen über Props. Das erleichtert den Test der Vorlage, da die Seitenkomponente nur Astro.params und Astro.props konsumiert.

Wenn Sie Restparameter verwenden, entscheiden Sie, wie Sie das Verhalten der obersten Route gestalten möchten. Astro unterstützt undefiniert für den Restparameter, wenn Sie möchten, dass die Datei den Basis-Pfad abgleicht. Das ist nützlich für Seiten wie /sequences sowie /sequences/one/two/three.

Ein guter Implementierungsworkflow besteht darin, zuerst mit einem kleinen Datensatz zu prototypisieren und dann auf die vollständige Sammlung zu erweitern, sobald die Routenform bewiesen ist. Das hilft Ihnen, Namensfehler frühzeitig zu erkennen, insbesondere wenn Sie mehrere dynamische Segmente oder geschachtelte Pfade haben. Es macht es auch einfacher zu sehen, ob Props zusätzliche Inhalte tragen sollten oder ob die Seite alles aus der URL und einer einzigen Abfrage ableiten kann.

Wenn die Quelldaten in einem CMS oder einer API gespeichert sind, betrachten Sie die Routeliste als Build-Eingabe und validieren Sie sie vor der Generierung. Überprüfen Sie, ob jeder Datensatz einen Slug hat, dass die Slugs eindeutig sind und dass alle geschachtelten Pfadsegmente in der richtigen Reihenfolge sind. Wenn die Datenquelle Entwürfe oder unveröffentlichte Elemente erzeugen kann, filtern Sie diese heraus, bevor getStaticPaths das endgültige Array zurückgibt. Das verhindert, dass Vorschauinhalte in Produktions-URLs gelangen.

Eine einfache Implementierungscheckliste:

• Bestätigen Sie, dass die Route für die statische Generierung geeignet ist.
• Stimmen Sie jedes dynamische Dateinamen-Segment mit einem Params-Schlüssel überein.
• Geben Sie ein Objekt pro Seite zurück, die Astro erstellen soll.
• Verwenden Sie Props, wenn die Seite zusätzliche Daten benötigt, die über die URL hinausgehen.
• Testen Sie geschachtelte und oberste Restparameter-Routen separat.
• Erstellen Sie neu, wenn sich die Quelldaten ändern, da die Routeliste Teil der Build-Ausgabe ist.
• Validieren Sie Slugs auf Einzigartigkeit, Lesbarkeit und URL-Sicherheit, bevor der Build ausgeführt wird.

Wenn Sie zwischen Params und Props entscheiden, verwenden Sie Params für alles, was die Route identifiziert, und Props für alles, was nur das Rendern der Seite unterstützt. Zum Beispiel gehört ein Slug in Params, während ein Titel, eine Zusammenfassung oder ein Hero-Bild in Props leben kann. Das hält den Routenvertrag klein und erleichtert es, die Vorlage später ohne Änderung der URL-Struktur umzustrukturieren.

Ein weiterer praktischer Implementierungstipp ist, den Code für die Routen-Generierung nahe an der Datenquelle zu halten, aber nicht mit der Präsentationslogik zu vermischen. Wenn dieselbe Inhaltskollektion mehrere Seiten speist, erstellen Sie einen kleinen Helfer, der normalisierte Routen-Datensätze zurückgibt. Dann kann jede Seite diese Datensätze in ihre eigene Params- und Props-Form abbilden. Das reduziert Duplikationen und erleichtert es, dieselben Quelldaten für Indizes, Detailseiten und lokalisierte Varianten wiederzuverwenden.

Häufige Fehler und Fallstricke

Der erste häufige Fehler ist ein Params-Mismatch. Wenn der Dateiname [dog].astro ist, funktioniert die Rückgabe von { params: { slug: "spot" } } nicht, da Astro dog erwartet, nicht slug. Die Schlüsselnamen müssen genau mit den Dateinamen-Segmenten übereinstimmen.

Der zweite Fehler ist die Annahme, dass getStaticPaths ein Laufzeit-Hook ist. Das ist es nicht. Im statischen Modus wird es zur Build-Zeit ausgeführt, sodass es nicht von anfrage-spezifischen Daten abhängen kann. Wenn Sie eine Route für jeden eingehenden Wert existieren lassen möchten, handelt es sich um ein anderes Rendering-Modell.

Ein weiterer Fallstrick ist die Übernutzung von Restparametern, wenn eine einfachere Route klarer wäre. Eine Catch-All-Route kann viele Probleme lösen, kann aber auch die Struktur verbergen. Wenn Ihr Inhalt eine stabile Hierarchie hat, sind explizite Segmente in der Regel einfacher zu warten und zu debuggen.

Teams stoßen auch auf Probleme, wenn sie vergessen, dass die Routeliste vollständig sein muss. Wenn ein neues Inhaltselement nach dem Build hinzugefügt wird, erscheint es erst, wenn die Seite neu erstellt wird. Das ist für viele redaktionelle und Katalog-Workflows in Ordnung, aber es ist eine Einschränkung, die Sie einplanen müssen.

Schließlich können kodierte oder ungewöhnliche Pfadwerte Verwirrung stiften. Astro stellt fest, dass die von getStaticPaths zurückgegebenen Params nicht dekodiert werden, sodass Sie, wenn Ihre Quelldaten kodierte Zeichen enthalten, dies absichtlich behandeln müssen. Andernfalls stimmt die generierte URL möglicherweise nicht mit dem menschenlesbaren Pfad überein, den Sie erwartet haben.

Ein verwandter Fehler besteht darin, die Anliegen innerhalb von getStaticPaths zu vermischen. Wenn die Funktion zu einem Ort für Formatierungen, Filterungen, Abrufen und Rendering-Entscheidungen wird, wird es schwieriger zu debuggen. Halten Sie die Funktion auf die Routen-Generierung fokussiert und verschieben Sie wiederverwendbare Datenformate in Hilfsfunktionen, wenn die Logik zu wachsen beginnt.

Ein weiteres praktisches Problem ist das Vergessen, den leeren oder Root-Fall für Rest-Routen zu testen. Wenn […slug].astro sowohl /sequences als auch tiefere Pfade bedienen soll, überprüfen Sie, ob undefiniert absichtlich behandelt wird und ob die Vorlage immer noch eine sinnvolle Basisseite rendert. Dieser kleine Test verhindert oft verwirrende 404-Fehler oder doppelte Inhalte später.

Ein einfaches Fixmuster hilft hier: Wenn ein Build fehlschlägt, überprüfen Sie zuerst den Dateinamen, dann die Params-Schlüssel und schließlich die Datenquelle. In vielen Fällen liegt der Fehler nicht in Astro selbst, sondern in einer Diskrepanz zwischen dem Inhaltsmodell und dem Routenmodell. Wenn Sie das Modell korrigieren, wird der Code normalerweise als Nebeneffekt einfacher.

Best Practices und schnelle Checkliste

Der beste Ansatz ist, getStaticPaths als Teil Ihrer Inhaltsarchitektur zu betrachten, nicht nur als Routing-Utility. Je sauberer Ihr Datenmodell ist, desto einfacher wird Ihre Routen-Generierung. Das bedeutet in der Regel ein kanonisches Slug-Feld, vorhersehbare Benennungen und eine klare Regel für geschachtelte Pfade.

Halten Sie die Routen-Datei und die Datenquelle synchron. Wenn Inhaltsredakteure Slugs umbenennen können, stellen Sie sicher, dass der Build-Prozess und interne Links zusammen aktualisiert werden. Wenn Sie auf ein CMS, Inhaltskollektionen oder einen Produktfeed angewiesen sind, verifizieren Sie, dass die Quelldaten immer die Felder zurückgeben, die Ihre Route erwartet.

Verwenden Sie Props für alles, was nicht Teil der URL selbst ist. Die URL sollte die Seite identifizieren; Props sollten der Vorlage unterstützende Daten bereitstellen. Diese Trennung macht die Route leichter verständlich und reduziert wiederholte Suchen innerhalb des Seitenkörpers.

Wenn Sie zwischen statischer Generierung und SSR entscheiden, stellen Sie zwei Fragen: Kann ich die Routeliste vor der Build-Zeit kennen und möchte ich, dass die Seite als statische Datei zwischengespeichert wird? Wenn die Antwort auf beide Fragen ja lautet, ist getStaticPaths normalerweise das richtige Werkzeug.

Eine praktische Faustregel: Verwenden Sie getStaticPaths, wenn die Routeliste endlich, stabil genug für Builds und wertvoll für das Vorab-Rendert ist. Vermeiden Sie es, wenn der Routenbereich effektiv unbegrenzt, benutzerspezifisch oder durch anfragebasierte Berechtigungen gesteuert wird. Diese Entscheidung allein verhindert viele unnötige Komplexität.

Schnelle Checkliste:

• Stimmen Sie jeden Parameternamen dem Routen-Dateinamen zu.
• Geben Sie eine vollständige Routeliste für statische Builds zurück.
• Verwenden Sie Props für zusätzliche Seiteninformationen.
• Bevorzugen Sie einfache Slugs gegenüber cleverer Pfadlogik.
• Testen Sie geschachtelte Routen, oberste Routen und Randfälle separat.
• Erstellen Sie neu, wann immer sich die Quelldaten ändern.
• Halten Sie die Routen-Generierung von der Präsentationslogik getrennt.

Eine letzte Best-Practice-Gewohnheit ist es, den Routenvertrag in der Nähe der Datenquelle zu dokumentieren. Wenn ein Sammlungsfeld eine dynamische Route speist, notieren Sie, welches Feld erforderlich ist, wie es normalisiert wird und ob es sich nach der Veröffentlichung ändern kann. Diese Dokumentation hilft Redakteuren, Entwicklern und QA-Teams, versehentliches URL-Driften zu vermeiden.

Eine weitere nützliche Gewohnheit ist es, die generierte Routeliste vor der Veröffentlichung mit Ihrer Sitemap oder Navigation zu vergleichen. Das fängt fehlende Seiten, doppelte Slugs und versehentliche Ausschlüsse frühzeitig auf. Wenn Ihre Seite mehrere Lokalisierungen oder Versionen hat, überprüfen Sie jede Gruppe separat, damit sich eine Sprache nicht stillschweigend von den anderen entfernt.

Aus der Praxis – illustratives Szenario (hypothetisch, kein Kundenprojekt)

Illustratives Beispiel – kein echtes Kundenprojekt: Stellen Sie sich einen Händler vor, der einen kleinen Astro-basierten Katalog für herunterladbare Vorlagen und Anleitungen erstellt. Die Seite hat eine Landingpage, eine Kategorieseite für jeden Vorlagentyp und eine Detailseite für jeden Artikel. Der Inhalt lebt in einer strukturierten Datenquelle mit Feldern wie Slug, Kategorie, Titel und Zusammenfassung.

Zuerst könnte das Team versucht sein, Links und Seiten-Dateien manuell zu codieren. Das funktioniert für fünf Seiten, wird jedoch brüchig, wenn der Katalog wächst. Ein neuer Artikel bedeutet eine weitere Datei, eine weitere Route und eine weitere Chance, eine URL falsch einzugeben. Das Team möchte auch, dass die Seiten schnell bleiben und einfach auf statischem Hosting bereitgestellt werden können.

Ein praktischerer Ansatz besteht darin, eine dynamische Routen-Datei für die Detailseiten zu erstellen, wie z. B. [slug].astro, und getStaticPaths zu verwenden, um ein Params-Objekt pro Artikel zurückzugeben. Die Funktion kann die Katalogdaten lesen, jeden Datensatz auf einen Slug abbilden und den Titel und die Zusammenfassung über Props übergeben. Die Seitenvorlage rendert dann das gemeinsame Layout, während jede generierte Seite ihre eigene URL und ihren eigenen Inhalt erhält.

Wenn der Katalog auch Kategorieseiten benötigt, kann das Team eine zweite dynamische Route wie [category].astro oder eine geschachtelte Struktur verwenden, wenn die Hierarchie tiefer ist. Die entscheidende Entscheidung besteht darin, die Routenform an das Inhaltsmodell anzupassen. Auf diese Weise bleibt die Build-Ausgabe vorhersehbar, selbst wenn der Katalog wächst.

Eine sinnvolle Arbeitsweise wäre es, zuerst das Datenschema zu definieren, dann einen kleinen Helfer zur Routen-Generierung zu schreiben und dann die Ausgabedaten-URLs mit einer kurzen Liste von erwarteten Seiten zu testen. Wenn das Team später Filter wie hervorgehoben, Entwurf oder saisonal hinzufügen möchte, können diese behandelt werden, bevor das Params-Array zurückgegeben wird. Das hält die Routing-Ebene sauber und macht deutlich, welche Datensätze versendet werden sollen.

Die Erkenntnis ist nicht, dass getStaticPaths kompliziert ist. Die Erkenntnis ist, dass es Struktur belohnt. Wenn die Inhalte zuerst organisiert sind, kann Astro diese Struktur mit sehr wenig Laufzeit-Overhead in Seiten umwandeln. Wenn die Inhalte unordentlich sind, wird die Routenfunktion zu einer Bereinigungsstufe, was normalerweise ein Zeichen dafür ist, dass das Datenmodell überarbeitet werden muss.

Ein zweiter hypothetischer Workflow macht den Kompromiss klarer. Angenommen, dasselbe Team möchte eine lokalisierte Version des Katalogs mit englischen und französischen Routen. Anstatt separate Seiten-Dateien für jede Sprache zu erstellen, können sie Kombinationen in getStaticPaths aus einer einzigen Quelle der Wahrheit generieren. Der Routenhelfer kann jede Position und jede Lokalisierung durchlaufen, die passenden Params zurückgeben und lokalisierungsspezifische Inhalte über Props anhängen. Das reduziert Duplikationen und hält die Übersetzungsarbeit von der Routenplanung getrennt.

Zusammenfassend würde das Team drei Dinge überprüfen, bevor es live geht: ob jede generierte URL mit der beabsichtigten Struktur übereinstimmt, ob die Basisroute und die geschachtelten Routen beide korrekt gerendert werden und ob unveröffentlichte Elemente aus dem Build ausgeschlossen sind. Diese Überprüfungen sind einfach, aber genau das sind die Details, die später gebrochene Navigation verhindern.

Ein nützlicher Entscheidungspunkt in diesem Szenario ist, was passiert, wenn sich ein Datensatz ändert. Wenn sich ein Titel ändert, aber der Slug gleich bleibt, kann die Seite neu erstellt werden, ohne die Links zu beeinflussen. Wenn sich der Slug ändert, benötigt das Team einen Umleitungsplan, damit alte URLs nicht brechen. Deshalb sollte das Routen-Design zusammen mit der Inhaltsverwaltung besprochen werden, nicht nach dem Start. Je stabiler die Slug-Richtlinie, desto weniger Wartung benötigt die statische Seite im Laufe der Zeit.

Verwandte Konzepte und weiterführende Literatur

Wenn Sie an dynamischen Routen in Astro arbeiten, helfen diese Leitfäden, das Routing-Modell mit der tatsächlichen Seitenarchitektur zu verbinden.

• Astro Inhaltskollektionen — nützlich, wenn Ihre Routen-Daten aus organisierten Inhaltsquellen stammen.
• Astro Islands Architektur — hilfreicher Kontext, wie Astro die Seiten nach dem Build schnell hält.
• Astro-Themen — stöbern Sie in Starter-Themen, die von strukturiertem dynamischen Routing profitieren können.
• Astro-Dokumentations-Routing-Leitfaden — das offizielle Referenzdokument für Routen-Dateien, Params und statische Generierung.