In questo post, approfondiremo come utilizzare la potenza di Edge Delivery Services e Document Authoring per costruire una lista dinamica di elementi da un foglio di calcolo situato in DA.

C'è una grande differenza tra inserire una lista di link su una pagina e curare qualcosa di realmente utilizzabile. Questo progetto è iniziato con "ci serve solo una lista di URL e descrizioni", ma si è rapidamente trasformato nella soluzione di alcuni problemi reali: mantenere i contenuti mantenibili, evitare il gonfiore del DOM e rendere il filtraggio veloce senza sovraingegnerizzarlo.

Il risultato è il blocco Reference List ; una griglia di carte filtrabile guidata dai dati per Adobe Edge Delivery Services (EDS) che estrae contenuti da un feed JSON supportato da fogli di calcolo, supporta il filtraggio di categorie e tag e carica progressivamente i risultati con animazioni rifinite. L'abbiamo creata appositamente per guidare questa pagina di riferimento di Edge Delivery Services, che tutti voi avreste già segnato tra i preferiti!

Lasciare che il foglio di calcolo gestisca tutto

Il blocco è interamente guidato dai dati. Recupera un file JSON generato da un foglio EDS a /en/reference-links.json. Abbiamo deciso di usare un formato multi-sheet; Un foglio per gli elementi di riferimento, uno per le categorie:

{
  "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" }]
  }
}

I tag utilizzano tubi all'interno della cella (Tag1 | Tag2), che mantiene la scrittura semplice e prevedibile.

Quando crei questo blocco, sicuramente vorrai fare qualche test prima di pubblicarlo in live. Se hai solo la lista popolata all'interno di DA, probabilmente incontrerai problemi di condivisione delle risorse (CORS) tra i test locali. Per risolvere questo problema, basta creare un proprio file JSON con alcune voci di test che soddisfino gli stessi requisiti del foglio DA e abilitare l'uso locale di JSON.

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

Costruire carte che non si rompono

Ogni oggetto di riferimento diventa una carta con questa struttura 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)

Quando si costruisce un blocco, una delle cose più importanti da considerare è quanto facilmente un autore può usarlo. A tal fine, dovevamo assicurarci che la lista potesse gestire diverse quantità di informazioni e funzionare allo stesso modo. Alcuni hanno descrizioni, tag o nessuno dei due. La regola era di renderizzare solo ciò che esiste, ma non lasciare che la disposizione dipenda dal fatto che un singolo pezzo sia presente. Alcune decisioni specifiche:

Filtrare la lista senza ricostruire il mondo

Quando si pensa a come filtrare, a volte le cose possono diventare complicate, specialmente quando si ri-renderizza ogni interazione. Per evitare questo, ci siamo assicurati di impostare fin dall'inizio gli attributi di ogni carta, così si trasforma più in una funzione di alternanza di visibilità.

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

Abbiamo anche aggiunto una funzione, updateReferenceDisplay, per rivalutare la visibilità di ogni interazione:

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

L'abbinamento dei tag usa la logica OR, qualsiasi tag selezionato qualifica una carta. I tag attivi vivono in un set, quindi aggiungere/rimuovere e controllare l'iscrizione sono tutti O(1). Un caso sottile a margine: oggetti non taggati. Lasciarli sempre passare il filtro del tag significava che non sparivano mai all'improvviso.

CSS che fa più del previsto

Anche se questo non è necessariamente un blog sullo styling, sarebbe negligente se non menzionassi alcune delle decisioni che abbiamo preso in questo ambito. Soprattutto riguardo all'effetto "spotlight" quando una carta è sospesa.

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

L'animazione del fade-in segue lo stesso approccio, quindi non c'è coordinazione tra JS e stili:

.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); }
}

Considerazioni finali

Questo progetto è un forte esempio di come un'architettura attenta trasformi un modello comune in qualcosa di veramente scalabile. Spingendo la responsabilità nei dati strutturati e mantenendo il frontend focalizzato su rendering efficiente e gestione dello stato, il blocco Reference List evita i soliti rischi di DOM gonfiati e costosi rerender.

Il vero valore non sta solo nel filtraggio o nella presentazione, ma nel sistema stesso. Gli autori hanno un modo prevedibile e a basso attrito per gestire i contenuti, mentre l'implementazione rimane performante e facile da estendere. È un modello che si mantiene con la crescita dei contenuti, non uno che deve essere rivisitato ogni volta che accade.

Guarda la pagina di riferimento in azione!

Informazioni sull'autore

Noah Mattison

Responsabile Tecnico della Consegna presso Arbory Digital

Noah è laureato in Informatica presso UNC Wilmington e sviluppatore AEM certificato due volte. Inizialmente seguiva un percorso pre-medico con una passione per la diagnosi del cancro e l'intelligenza artificiale, porta una mentalità di problem solving nel suo lavoro ad Arbory. Aiuta a pianificare l'esecuzione dei progetti, delega il lavoro tra i team, mantiene una forte comunicazione e supporta le operazioni interne. Crede nella comunità e nella visione di Arbory e, al di fuori del lavoro, è orientato all'ambiente e ama mantenersi attivo all'aperto, tra campeggio, surf e arrampicata.

Contatta Noah su LinkedIn

Ti è piaciuto quello che hai sentito? Hai domande su cosa sia giusto per te? Ci piacerebbe parlare! Contattaci

Altri articoli che potrebbero piacerti

category
AEM Technical Help
tags
AEM
number of rows
1