Aller au contenu
duxt

Collections

Ce que Content construit à partir des sources, et les quatre choses qu’ajoute le schéma.

Une collection est l’unité de sourcing de Content : un glob, un endroit d’où le lire et un schéma. duxt en déclare une par dépôt × ref : un site avec un dossier a donc une collection, et un site avec deux dépôts sur trois refs en a six.

Leurs noms sont des données, pas une constante. Un site avec deux dépôts a docs_duxt et docs_workflows et aucune collection nommée docs — c’est pourquoi le thème lit le nom de la collection dans le manifeste plutôt que de le coder en dur, et pourquoi une requête à vous devrait faire de même :

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

Ce qu’ajoute le schéma

Content ne stocke que ce qu’un schéma déclare : quatre éléments dont le thème a besoin sont donc déclarés explicitement. La liste complète est dans la référence du frontmatter ; les raisons sont ici :

  • icon, layout, navigation — des champs du thème. Sans le schéma, un icon: dans le frontmatter est silencieusement supprimé avant même que la barre latérale le voie.
  • rawbody — le Markdown tel qu’écrit. Deux choses en ont besoin : le bouton qui remet une page à un modèle, et llms-full.txt.
  • redirectFrom — transformé en règles de route par la compilation ; voir Déplacer une page.
  • sitemap — ce qui met ces pages dans le sitemap. Une collection doit déclarer le champ, sinon le sitemap liste les routes du site et pas une seule page de documentation.

Fragments

_partials/ dans le dossier de documentation de n’importe quelle source alimente une collection partagée, et :partial{name="install"} dans n’importe quelle page de n’importe quelle source l’affiche. Content ne fournit aucune directive d’inclusion, et à travers plusieurs dépôts ce manque n’a aucun contournement — une note d’installation qui doit être identique dans trois projets est copiée dans trois projets et diverge.

Les fragments portent la même dimension linguistique que les pages : docs/_partials/ est duxt_partials, docs/de/_partials/ est duxt_partials_de, et :partial parcourt la même chaîne de repli que la page qui le contient. Ce doit être la même chaîne — qu’une page et les blocs qu’elle inclut se replient sur des langues différentes, c’est exactement ainsi qu’on obtient une page à moitié traduite sans que rien ne le signale.

Les fragments sont exclus des collections de pages elles-mêmes. Sinon chaque fragment serait aussi une page : dans la barre latérale, dans la recherche, dans llms.txt.

Les brouillons sont des fichiers, pas des drapeaux

Un brouillon est deploying.draft.md, pas draft: true dans le frontmatter. Le drapeau est l’écriture évidente et celle qui ne peut pas fonctionner : le contenu d’une collection est déclaré avant que Content ait lu le moindre fichier — pour une source distante, avant même qu’elle soit téléchargée — donc rien à ce moment ne sait ce que dit un frontmatter. Un nom de fichier, lui, est connu. Content retire .draft de l’URL : la page est donc servie sur /deploying dans le serveur de développement et simplement absente de la compilation.

Cette page vous a-t-elle été utile ?