Zum Inhalt springen
duxt

Collections

Was Content aus den Quellen baut, und die vier Dinge, die das Schema hinzufügt.

Eine Collection ist Contents Einheit des Bezugs: ein Glob, ein Ort zum Lesen und ein Schema. duxt deklariert eine je Repository × Ref — eine Seite mit einem Ordner hat also eine Collection, eine Seite mit zwei Repositories an drei Refs hat sechs.

Ihre Namen sind Daten, keine Konstante. Eine Seite mit zwei Repositories hat docs_duxt und docs_workflows und überhaupt keine Collection namens docs — deshalb liest das Theme den Collection-Namen aus dem Manifest, statt einen fest zu verdrahten, und deshalb sollte eine eigene Abfrage dasselbe tun:

<script setup lang="ts">
const { collection } = useDuxtCollection();
const { data } = await useAsyncData(() =>
  queryCollection(collection.value).all()
);
</script>

Was das Schema hinzufügt

Content speichert nur, was ein Schema deklariert, deshalb sind vier Dinge, die das Theme braucht, ausdrücklich deklariert. Die vollständige Liste steht in der Frontmatter-Referenz; die Gründe stehen hier:

  • icon, layout, navigation — Theme-Felder. Ohne das Schema wird ein icon: im Frontmatter stillschweigend verworfen, bevor die Seitenleiste es je sieht.
  • rawbody — das Markdown, wie es geschrieben wurde. Zwei Dinge brauchen es: die Schaltfläche, die eine Seite an ein Modell übergibt, und llms-full.txt.
  • redirectFrom — vom Build in Routenregeln übersetzt; siehe Eine Seite verschieben.
  • sitemap — das, was diese Seiten überhaupt in die Sitemap bringt. Eine Collection muss das Feld deklarieren, sonst listet die Sitemap die Routen der Seite und keine einzige Dokumentationsseite.

Partials

_partials/ im Doku-Ordner jeder Quelle speist eine gemeinsame Collection, und :partial{name="install"} in einer beliebigen Seite einer beliebigen Quelle rendert es. Content liefert keine Include-Direktive, und über mehrere Repositories hinweg hat diese Lücke überhaupt keinen Behelf — ein Installationshinweis, der in drei Projekten gleich lauten muss, wird in drei Projekte kopiert und driftet auseinander.

Partials tragen dieselbe Sprachdimension wie die Seiten: docs/_partials/ ist duxt_partials, docs/de/_partials/ ist duxt_partials_de, und :partial durchläuft dieselbe Fallback-Kette wie die Seite, in der es steht. Es muss dieselbe Kette sein — dass eine Seite und die Blöcke, die sie einbindet, auf unterschiedliche Sprachen zurückfallen, ist genau der Weg zu einer halb übersetzten Seite, auf der nichts davon erzählt.

Partials sind aus den Seiten-Collections selbst ausgeschlossen. Sonst wäre jedes Partial auch eine Seite: in der Seitenleiste, in der Suche, in llms.txt.

Entwürfe sind Dateien, keine Schalter

Ein Entwurf ist deploying.draft.md, nicht draft: true im Frontmatter. Der Schalter ist die naheliegende Schreibweise und die, die nicht funktionieren kann: Der Inhalt einer Collection wird deklariert, bevor Content eine einzige Datei gelesen hat — bei einer entfernten Quelle, bevor sie heruntergeladen wurde — nichts weiß zu diesem Zeitpunkt also, was in irgendeinem Frontmatter steht. Ein Dateiname ist bekannt. Content entfernt .draft aus der URL, die Seite wird also im Entwicklungsserver unter /deploying ausgeliefert und fehlt im Build schlicht.

War diese Seite hilfreich?