

Tworzenie bloku dynamicznej listy referencyjnej dla usług Adobe Edge Delivery Services
- AEM
- da
- performance
- adobe
W tym poście przyjrzymy się, jak wykorzystać możliwości Edge Delivery Services i Document Authoring do tworzenia dynamicznej listy elementów z arkusza kalkulacyjnego znajdującego się w DA.
Istnieje duża różnica między wrzuceniem listy linków na stronę, a stworzeniem czegoś, co jest rzeczywiście użyteczne. Ten projekt rozpoczął się jako "potrzebujemy tylko listy adresów URL i opisów,", ale szybko przekształcił się w rozwiązanie kilku rzeczywistych problemów: utrzymanie treści w dobrym stanie, unikanie rozrostu DOM i sprawienie, by filtrowanie było szybkie bez nadmiernej inżynierii.
Rezultatem jest blok listy referencyjnej; oparta na danych, filtrowana siatka kart dla Adobe Edge Delivery Services (EDS), która pobiera zawartość z kanału JSON opartego na arkuszu kalkulacyjnym, obsługuje filtrowanie kategorii i tagów oraz stopniowo ładuje wyniki z dopracowanymi animacjami. Stworzyliśmy go specjalnie po to, aby prowadzić tę stronę referencyjną Edge Delivery Services, którą wszyscy powinniście już mieć w zakładkach!
Pozwalając arkuszowi kalkulacyjnemu kierować wszystkim
Blok jest całkowicie oparty na danych. Pobiera plik JSON wygenerowany przez arkusz EDS na stronie /en/reference-links.json. Zdecydowaliśmy się użyć formatu wieloarkuszowego; jeden arkusz dla pozycji referencyjnych, jeden dla kategorii:
{
"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" }]
}
}
Znaczniki używają potoków w komórce (Tag1 | Tag2), dzięki czemu tworzenie jest proste i przewidywalne.
Podczas tworzenia tego bloku bez wątpienia będziesz chciał przeprowadzić testy przed jego uruchomieniem. Jeśli wszystko, co masz, to wypełniona lista wewnątrz DA, prawdopodobnie napotkasz pewne problemy z udostępnianiem zasobów między źródłami (CORS) podczas testowania lokalnego. Aby to naprawić, wystarczy utworzyć własny plik JSON z kilkoma wpisami testowymi, które spełniają te same wymagania, co arkusz DA i włączyć lokalne użycie JSON.
const USE_LOCAL_JSON = false;
const LOCAL_JSON_PATH = '/tools/json/reference-list.json';
const LIVE_JSON_URL = '/en/reference-links.json';
Budowanie kart, które się nie psują
Każdy element referencyjny staje się kartą z tą strukturą 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)
Podczas tworzenia bloku jedną z najważniejszych rzeczy do rozważenia jest to, jak łatwo autor może z niego korzystać. W tym celu musieliśmy upewnić się, że lista może obsługiwać różne ilości informacji i nadal działać tak samo. Niektóre mają opisy, tagi lub żadne z nich. Zasadą było, aby renderować tylko to, co istnieje, ale nie pozwolić, aby układ zależał od obecności jednego elementu. Kilka konkretnych decyzji:
-
Obraz jest opcjonalny, pole image-url (z opcją powrotu do obrazu) jest renderowane tylko wtedy, gdy nie jest puste.
-
Obrazy używają loading="lazy", więc miniatury poza ekranem nie blokują początkowego renderowania.
-
Wszystkie linki używają rel="noopener noreferrer", aby zapobiec tab-nappingowi na zewnętrznych adresach URL.
- Zwykle jest to wykonywane automatycznie przez nowoczesne przeglądarki, ale lepiej być bezpiecznym niż żałować!
Filtrowanie listy bez przebudowywania świata
Zastanawiając się nad sposobem filtrowania, czasami może dojść do bałaganu, zwłaszcza przy ponownym renderowaniu przy każdej interakcji. Aby tego uniknąć, upewniliśmy się, że ustawiliśmy atrybuty każdej karty od samego początku, w ten sposób zamienia się ona bardziej w przełącznik widoczności.
card.setAttribute('data-category', ref.category);
card.setAttribute('data-tags', JSON.stringify(cardTags));
Dodaliśmy również funkcję updateReferenceDisplay, aby ponownie ocenić widoczność przy każdej interakcji:
const categoryMatch = selectedCategory === 'all' || cardCategory === selectedCategory;
const tagMatch = cardTags.length === 0 || cardTags.some((tag) => activeTags.has(tag));
Dopasowywanie tagów wykorzystuje logikę OR, każdy wybrany tag kwalifikuje kartę. Aktywne tagi żyją w zestawie, więc dodawanie/usuwanie i sprawdzanie członkostwa są O(1). Jeden subtelny przypadek brzegowy: nieoznaczone przedmioty. Dzięki temu, że zawsze przechodzą przez filtr tagów, nigdy nie znikają niespodziewanie.
CSS robi więcej niż oczekiwano
Chociaż niekoniecznie jest to blog o stylizacji, byłbym niedbały, gdybym nie wspomniał o niektórych decyzjach, które podjęliśmy w tym dziale. Zwłaszcza jeśli chodzi o efekt "spotlight" po najechaniu na kartę.
.reference-grid:has(.reference-card:hover) .reference-card:not(:hover) {
transform: scale(0.9);
opacity: 0.6;
}
Animacja zanikania ma to samo podejście, więc nie ma narzutu koordynacji między JS i stylami:
.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); }
}
Przemyślenia końcowe
Projekt ten jest dobrym przykładem tego, jak przemyślana architektura przekształca powszechny wzorzec w coś naprawdę skalowalnego. Przenosząc odpowiedzialność na ustrukturyzowane dane i utrzymując frontend skoncentrowany na wydajnym renderowaniu i zarządzaniu stanem, blok listy referencyjnej unika typowych pułapek związanych z rozdętym DOM i kosztownym ponownym renderowaniem.
Prawdziwa wartość tkwi nie tylko w filtrowaniu czy prezentacji, ale w samym systemie. Autorzy otrzymują przewidywalny sposób zarządzania treścią o niskim tarciu, podczas gdy implementacja pozostaje wydajna i łatwa do rozszerzenia. Jest to wzorzec, który utrzymuje się wraz z rozwojem treści, a nie taki, do którego trzeba wracać za każdym razem.
Zobacz stronę referencyjną w akcji!
O autorze
Noah Mattison
Technical Delivery Manager w Arbory Digital
Noah jest absolwentem informatyki na UNC Wilmington i 2x certyfikowanym programistą AEM. Początkowo studiował medycynę z pasją do wykrywania raka i sztucznej inteligencji, a do swojej pracy w Arbory wnosi nastawienie na rozwiązywanie problemów. Pomaga planować realizację projektów, deleguje pracę między zespołami, utrzymuje silną komunikację i wspiera wewnętrzne operacje. Wierzy w społeczność i wizję Arbory, a poza pracą koncentruje się na ochronie środowiska i lubi przebywać na świeżym powietrzu, w tym biwakować, surfować i wspinać się po skałach.
Podoba ci się to, co usłyszałeś? Masz pytania dotyczące tego, co jest dla Ciebie odpowiednie? Chętnie porozmawiamy! Skontaktuj się z nami

