Dans cet article, nous allons explorer comment utiliser la puissance des services de livraison en bord et de la création de documents pour construire une liste dynamique d’éléments à partir d’un tableau situé dans DA.

Il y a une grande différence entre déposer une liste de liens sur une page et sélectionner quelque chose de réellement utilisable. Ce projet a commencé par « il nous faut juste une liste d’URL et de descriptions », mais il s’est rapidement transformé en résolution de quelques vrais problèmes : garder le contenu maintenable, éviter le surchargement du DOM, et rendre le filtrage rapide sans trop le concevoir.

Le résultat est le bloc Liste de références ; une grille de cartes filtrable pilotée par les données pour Adobe Edge Delivery Services (EDS) qui extrait le contenu d’un flux JSON appuyé sur un tableur tableur, prend en charge le filtrage par catégories et tags, et charge progressivement les résultats avec des animations soignées. Nous l’avons conçue spécifiquement pour alimenter cette page de référence Edge Delivery Services que vous devriez tous avoir déjà mise en favori !

Laisser le tableau guider tout

Le bloc est entièrement piloté par les données. Il récupère un fichier JSON généré par une feuille EDS à /en/reference-links.json. Nous avons décidé d’utiliser un format multi-feuilles ; une fiche pour les éléments de référence, une autre pour les catégories :

{
  "data": {
    "data": [
      {
        "url": "https://developer.adobe.com/",
        "image-url": "https://example.com/thumb.png",
        "title": "Adobe Developer Documentation",
        "description": "Official docs for building on Adobe platforms.",
        "tag": "Documentation|Official",
        "category": "Development"
      }
    ]
  },
  "categories": {
    "data": [{ "Category": "Development", "Description": "Dev tools and references" }]
  }
}

Les balises utilisent des tuyaux à l’intérieur de la cellule (Tag1 | Tag2), qui maintient la création simple et prévisible.

Quand vous créez ce bloc, vous voudrez sans doute faire quelques tests avant de le mettre en ligne. Si vous n’avez que la liste remplie dans DA, vous rencontrerez probablement des problèmes de partage de ressources cross-origin (CORS) lors des tests locaux. Pour résoudre cela, il suffit de créer votre propre fichier JSON avec quelques entrées de test qui répondent aux mêmes exigences que la feuille DA et d’activer l’utilisation locale du JSON.

const USE_LOCAL_JSON = false;
const LOCAL_JSON_PATH = '/tools/json/reference-list.json';
const LIVE_JSON_URL = '/en/reference-links.json';

Construire des cartes qui ne cassent pas

Chaque élément de référence devient une carte avec cette structure DOM :

.reference-card
  └── a.reference-link
        ├── div.reference-image-wrapper   (optional)
        │     └── img.reference-image
        └── div.reference-content
              ├── h3.reference-title
              ├── p.reference-description  (optional)
              └── div.reference-tags
                    └── span.reference-tag (one per tag)

Lorsqu’on construit un bloc, l’un des éléments les plus importants à considérer est la facilité avec laquelle un auteur peut l’utiliser. À cette fin, nous devions nous assurer que la liste pouvait gérer différentes quantités d’informations tout en fonctionnant de la même manière. Certains ont des descriptions, des tags, ou aucun des deux. La règle était de ne rendre que ce qui existe, mais ne laisse pas la disposition dépendre de la présence d’une seule pièce. Quelques décisions spécifiques :

Filtrer la liste sans reconstruire le monde

Quand on réfléchit à la façon de filtrer, les choses peuvent parfois devenir compliquées, surtout lors du re-rendu à chaque interaction. Pour éviter cela, nous avons veillé à définir les attributs de chaque carte dès le départ, ce qui fait que cela devient plutôt un basculement de visibilité.

card.setAttribute('data-category', ref.category);
card.setAttribute('data-tags', JSON.stringify(cardTags));

Nous avons également ajouté une fonction, updateReferenceDisplay, pour réévaluer la visibilité de chaque interaction :

const categoryMatch = selectedCategory === 'all' || cardCategory === selectedCategory;
const tagMatch = cardTags.length === 0 || cardTags.some((tag) => activeTags.has(tag));

L’appariement des tags utilise la logique OU, toute étiquette sélectionnée qualifie une carte. Les balises actives sont présentes dans un Set, donc les vérifications d’ajout/suppression et d’adhésion sont toutes O(1). Un cas subtil : les objets non étiquetés. Les laisser toujours passer le filtre de l’étiquette signifiait qu’ils ne disparaissaient jamais de façon inattendue.

CSS fait plus que prévu

Bien que ce ne soit pas forcément un blog sur le stylisme, je serais négligent de ne pas mentionner certaines décisions que nous avons prises dans ce domaine. Surtout concernant l’effet « projecteur » quand une carte est en lévitation.

.reference-grid:has(.reference-card:hover) .reference-card:not(:hover) {
  transform: scale(0.9);
  opacity: 0.6;
}

L’animation de fondu suit la même approche, donc il n’y a pas de coordination entre JS et styles :

.reference-card { opacity: 0; }

.reference-card.fade-in {
  opacity: 1;
  animation: fade-in-up 0.5s ease-out forwards;
}

@keyframes fade-in-up {
  from { transform: translateY(20px); }
  to   { transform: translateY(0); }
}

Dernières réflexions

Ce projet est un exemple fort de la façon dont une architecture réfléchie transforme un schéma commun en quelque chose de véritablement évolutif. En transférant la responsabilité dans les données structurées et en maintenant le frontend focalisé sur un rendu efficace et une gestion de l’état, le bloc Liste de Références évite les pièges habituels des DOMs gonflés et des re-rendus coûteux.

La vraie valeur ne réside pas seulement dans le filtrage ou la présentation, mais dans le système lui-même. Les auteurs bénéficient d’une manière prévisible et peu stressante de gérer le contenu, tout en restant performante et facile à étendre. C’est un schéma qui se maintient à mesure que le contenu grandit, pas un schéma à revenir à chaque fois.

Voyez la page de référence en action!

À propos de l’auteur

Noah Mattison

Responsable technique de la livraison chez Arbory Digital

Noah est diplômé en informatique de l’UNC Wilmington et développeur AEM certifié deux fois. Initialement sur une filière pré-médecine, passionné de détection du cancer et d’IA, il apporte un état d’esprit axé sur la résolution de problèmes dans son travail à Arbory. Il aide à planifier l’exécution des projets, délègue les tâches entre les équipes, maintient une communication solide et soutient les opérations internes. Il croit en la communauté et la vision d’Arbory, et en dehors du travail, il est très attaché à l’environnement et aime rester actif en plein air, notamment en camping, en surf et en escalade.

Contactez Noah sur LinkedIn

Tu as aimé ce que tu as entendu ? Vous avez des questions sur ce qui vous convient ? Nous serions ravis de discuter ! Contactez-nous

Plus d’articles que vous pourriez aimer

category
AEM Technical Help
tags
AEM
number of rows
1