Single page applications (SPA) can offer compelling experiences for website users. Utvecklare vill kunna skapa webbplatser med SPA ramverk och författare vill smidigt redigera innehåll i Adobe Experience Manager (AEM) för en webbplats som skapats med sådana ramverk.
I den här artikeln finns viktiga frågor att tänka på när en frontutvecklare ska utveckla en SPA för AEM och en översikt över arkitekturen i AEM för att distribuera SPA på AEM.
SPA Editor är den rekommenderade lösningen för projekt som kräver SPA ramverksbaserad klientåtergivning (till exempel React eller Angular).
Utveckla single page-applikationer AEM förutsätter att frontutvecklaren följer vedertagna standarder när han skapar en SPA. Om du som gränssnittsutvecklare följer dessa allmänna bästa metoder och några AEM specifika principer fungerar SPA med AEM och funktioner för att skapa innehåll.
Om du håller dessa principer i åtanke när du utvecklar SPA blir det så flexibelt och säkert som möjligt i framtiden, samtidigt som du aktiverar alla funktioner för AEM som stöds.
Om du inte behöver stöd för AEM redigeringsfunktioner kan du behöva överväga ett annat SPA designmodell.
Precis som när du utvecklar en komponent bör dina komponenter utformas på ett sådant sätt att de blir så bärbara som möjligt. Mönster som motverkar komponenternas bärbarhet eller återanvändbarhet bör undvikas för att säkerställa kompatibilitet, flexibilitet och underhållbarhet.
Den resulterande SPA ska byggas med mycket portabla och återanvändbara komponenter.
Utvecklaren måste tänka på sig själv som ansvarig för att skapa ett bibliotek med SPA komponenter som används för att bygga appen. Utvecklaren har fullständig kontroll över komponenternas interna struktur. AEM äger dock alltid platsens struktur.
Det innebär att frontendutvecklaren kan lägga till kundinnehåll före eller efter startpunkten för komponenterna och även göra tredjepartsanrop inuti komponenten. Utvecklaren har dock inte fullständig kontroll över hur komponenterna kapslas, till exempel.
SPA ska endast förlita sig på dynamisk återgivning av innehåll. Detta är standardförväntningen där AEM hämtar och återger alla underordnade element i innehållsstrukturen.
All explicit återgivning som pekar på visst innehåll betraktas som statisk återgivning och även om den stöds kommer den inte att vara kompatibel med AEM innehållsredigeringsfunktioner. Detta strider också mot principen om bärbarhet.
Precis som vid återgivning ska all routning också vara dynamisk. AEM SPA ska alltid äga routningen och AEM lyssnar på den och hämtar innehåll baserat på den.
Alla statiska routningar fungerar mot bärbarhetsprincip och begränsar författaren genom att inte vara kompatibel med redigeringsfunktionerna i AEM. Om innehållsförfattaren till exempel vill ändra en väg eller ändra en sida med statisk routning måste han eller hon be frontutvecklaren att göra det.
Alla AEM ska använda AEM Project Archettype, som stöder SPA projekt med React eller Angular och använder SPA SDK.
Om principer för utveckling av SPA inom AEM följer du SPA med alla funktioner som stöds AEM innehållsredigeringsfunktionen.
Det kan dock finnas fall där detta inte är helt nödvändigt. Tabellen nedan ger en översikt över de olika designmodellerna, deras fördelar och nackdelar.
Designmodell |
Fördelar | Nackdelar |
---|---|---|
AEM används som headless CMS utan att använda SPA SDK-ramverket. | Utvecklaren har fullständig kontroll över appen. | Innehållsförfattare kan inte använda AEM. Koden är inte portabel eller återanvändbar om den innehåller statiska referenser eller routning. Det går inte att använda mallredigeraren, så frontendutvecklaren måste underhålla redigerbara mallar via JCR. |
Utvecklaren använder SDK-ramverket för SPA Editor, men bara vissa områden öppnas för innehållsförfattaren. | Utvecklaren behåller kontrollen över appen genom att endast aktivera redigering i begränsade delar av appen. | Innehållsförfattare är begränsade till en begränsad uppsättning AEM upplevelser. Koden kan varken vara flyttbar eller återanvändbar om den innehåller statiska referenser eller routning. Det går inte att använda mallredigeraren, så frontendutvecklaren måste underhålla redigerbara mallar via JCR. |
I projektet används SPA Editor SDK fullt ut och klientkomponenterna utvecklas som ett bibliotek och innehållsstrukturen i programmet delegeras till AEM. | Appen är återanvändbar och portabel. Innehållsförfattaren kan redigera appen med hjälp av AEM. SPA är kompatibelt med mallredigeraren. |
Utvecklaren har inte kontroll över programmets struktur och den del av innehållet som har delegerats till AEM. Utvecklaren kan fortfarande reservera områden i programmet för innehåll som inte ska redigeras med AEM. |
Även om alla modeller stöds i AEM, är det bara genom att implementera den tredje (och därför följa den rekommenderade SPA utvecklingsprinciper inom AEM) kan skribenter interagera med och redigera innehållet i SPA i AEM som de är vana vid.
Om SPA följer SPA för AEM, fungerar SPA i AEM och kan redigeras med AEM SPA Editor.
Följ de här stegen för att göra dina befintliga SPA redo att arbeta med AEM.
Gör dina JS-komponenter modulära.
Gör dem kapabla att återges i valfri ordning, position och storlek.
Använd behållarna från Adobe SDK för att placera dina komponenter på skärmen.
AEM innehåller en sid- och styckesystemkomponent som du kan använda.
Skapa en AEM för varje JS-komponent.
De AEM komponenterna definierar dialogrutan och JSON-utdata.
Den främsta uppgiften att engagera en gränssnittsutvecklare för att skapa en SPA för AEM är att komma överens om komponenterna och deras JSON-modeller.
Här följer en översikt över de steg som en frontendutvecklare måste följa när han eller hon utvecklar en SPA för AEM.
Godkänn komponenterna och deras JSON-modell
Utvecklare och AEM måste komma överens om vilka komponenter som är nödvändiga och en modell så att det går att hitta en exakt motsvarighet mellan komponenterna SPA bakomliggande komponenter.
AEM är fortfarande nödvändiga för att kunna tillhandahålla redigeringsdialogrutor och exportera komponentmodellen.
I React-komponenter får du åtkomst till modellen viathis.props.cqModel
När komponenterna är överenskomna och JSON-modellen är på plats kan den som utvecklar SPA utveckla den och enkelt komma åt JSON-modellen via this.props.cqModel
.
Implementera komponentens render()
method
Utvecklaren implementerar render()
metoden så som den passar och kan använda fälten i cqModel
-egenskap. Då skrivs DOM- och HTML-fragmenten som infogas på sidan ut. Det här är standardsättet att bygga en app i React.
Mappa komponenten till AEM-resurstypen viaMapTo()
Mappningen lagrar komponentklasser och används internt av den angivna Container
för att hämta och dynamiskt instansiera komponenter baserat på den angivna resurstypen.
Det här fungerar som en"limma" mellan fram- och bakände så att redigeraren vet vilka komponenter som de olika reaktionskomponenterna motsvarar.
The Page
och ResponsiveGrid
är bra exempel på klasser som utökar basen Container
.
Definiera komponentens EditConfig
som parameter tillMapTo()
Den här parametern är nödvändig för att tala om för redigeraren hur komponenten ska namnges så länge som den inte har återgetts eller inte har något innehåll att återge.
Utöka den angivna Container
klass för sidor och behållare
Sidor och styckesystem bör utöka den här klassen så att delegering till inre komponenter fungerar som förväntat.
Implementera en routningslösning som använder HTML5 History
API.
När ModelRouter
är aktiverat, anropar pushState
och replaceState
funktioner som utlöser en begäran till PageModelManager
för att hämta ett saknat fragment av modellen.
Den aktuella versionen av ModelRouter
stöder endast användning av URL:er som pekar på den faktiska resurssökvägen för Sling Model-startpunkter. Det stöder inte användning av vanity-URL:er eller alias.
The ModelRouter
kan inaktiveras eller konfigureras för att ignorera en lista med reguljära uttryck.
Dessa kodblock illustrerar hur komponenterna React och Angular inte behöver något som är specifikt för Adobe eller AEM.
The MapTo
helper är den limning som gör att bakände och framände kan matchas ihop:
Mer information om hur du använder MapTo
och skapa SPA för AEM i allmänhet, se Komma igång-guiden för ditt valda ramverk.
Den allmänna arkitekturen för AEM, inklusive utvecklings-, skribent- och publiceringsmiljöer, förändras inte när SPA används. Men det är bra att förstå hur SPA kan integreras i arkitekturen.
Bygg miljö
Det är här som källan för SPA programkälla och komponentkälla checkas ut.
AEM
Innehåll skapas på AEM författare, inklusive SPA.
När en SPA redigeras med SPA Editor i redigeringsmiljön:
cq-data
attribut.cq-data
kan redigeraren läsa in ytterligare sidinformation så att den vet vilka redigeringskonfigurationer som är tillgängliga för komponenterna.AEM Publish
Det är här som det innehåll och de kompilerade biblioteken, inklusive SPA, programartefakter, klientlibs och komponenter publiceras för allmänheten.
Dispatcher/CDN
Dispatcher fungerar som AEM för webbplatsens besökare.
I AEM finns ingen anledning att köra JavaScript-byggmekanismer eller själva JavaScript. AEM är bara värd för de kompilerade artefakterna från det SPA programmet.
En översikt över hur en enkel SPA i AEM är strukturerad och hur den fungerar finns i guiden Komma igång för båda Reagera och Angular.
En steg-för-steg-guide till hur du skapar egna SPA finns i Getting Started with the AEM SPA Editor - WKND Events Tutorial.
Mer information om den dynamiska modellen till komponentmappning och hur den fungerar i SPA i AEM finns i artikeln Dynamisk mappning av modell till komponent för SPA.
Om du vill implementera SPA i AEM för ett annat ramverk än React eller Angular eller bara vill ta en grundlig titt på hur SPA SDK för AEM fungerar, se SPA artikel.