Sauver la continuité de l'espace-temps, suite et fin.

Mes principaux problèmes de date sont réglés mais il me reste encore quelques soucis dans mes listes d'articles et mon journal : tous mes articles ne sont pas correctement ordonnés :

• Ceux qui ont une date définie dans le front matter sont bien ordonnés entre eux
• Ceux dont la date est déduite du nom de fichier semblent encore ordonnés selon leur date de création

Ce comportement est assez cohérent avec la doc des Collections(S'ouvre dans un nouvelle fenêtre)⎋, même si j'ai un regret, il semble que la surcharge par la propriété date ne prend pas en compte la version calculée que j'ai modifié dans mon entrée précédente… Il va falloir que je fasse mon propre système de tri de collections avec l'API proposée par eleventy : Collections API(Opens in a new window)⎋

À la découverte des collections personnalisées

En me renseignant sur le sujet, outre la doc officielle, je suis tombé sur cet article : Working with 11ty Collections, Matthew McAdams(Opens in a new window)⎋.
L'originalité ici est qu'il base ses collections sur des dossiers plutôt que des tags. J'apprécie l'approche mais j'ai déjà exploité les données de dossier(S'ouvre dans un nouvelle fenêtre)⎋ pour appliquer toutes sortes de métadonnées à mes articles et entrées, notamment les tags nécessaire aux collections "classiques". Il est probablement préférable que je garde ce genre de réglages à un emplacement unique.

Matthew propose aussi une méthode pour générer des "super collection" listant les tags existants (et pour chaque tag listé, la collection liée^[1]). L'idée est intéressante mais je vais déjà commencer par une collection simple, afin de le fixer mon problème de dates.

Échec du retour vers le futur

Malheureusement il m'est impossible de résoudre ce problème de tri : en effet les collections ignorent les propriétés calculées car elles sont générées avant le calcul de celles-ci.

La conclusion est terrible : Tous mes bricolages de la veille sont inutiles.

Je suis bon pour les retirer et opter pour la seule option fiable et officielle pour obtenir une date immuable : date: git Created

Cette approche n'est pas parfaite, mais au moins me garantie une certaines immutabilité de la date par défaut, que je pourrais toujours surcharger manuellement directement dans le front matter de mes pages.

// In eleventy.config.js

export default async function(eleventyConfig) {
  // Setup Git as the default creation date for all pages (fallback to Date.NOW() for non committed files)
  eleventyConfig.addGlobalData("date", "git Created");
}

Ce que j'ai appris

L'intégrité de l'espace-temps est maintenant rétablie et, bien que ce fut douloureux, j'en retire quelques apprentissages :

1. Eleventy attend des objets Date mais le seul moyen de les obtenir sans souci est encore de passer par Luxon
2. Les propriétés calculées c'est génial mais inutilisable dans les collections ou les paginations.
3. Le fonctionnement de data.date et data.page.date. Je pensais que data.page.date représentait toujours la date de création du fichier, mais c'est faux. Cette propriété prend toujours (et converti) la valeur de data.date, quand celle-ci est fournie.