Aplicativos de página única (SPA) podem oferta experiências interessantes para usuários de sites. Os desenvolvedores querem ser capazes de criar sites usando estruturas SPA e os autores querem editar o conteúdo no AEM para um site criado usando essas estruturas.
Este artigo apresenta questões importantes a serem consideradas ao envolver um desenvolvedor de front-end para desenvolver uma SPA para AEM e fornece uma visão geral da arquitetura do AEM em relação à implantação do SPA no AEM.
O Editor de SPA é a solução recomendada para projetos que exigem renderização do cliente baseada em SPA estrutura (por exemplo, Reagir ou Angular).
O desenvolvimento de aplicativos de página única em AEM pressupõe que o desenvolvedor front-end observe as práticas recomendadas padrão ao criar um SPA. Se você seguir essas práticas recomendadas gerais e alguns princípios específicos para AEM como desenvolvedor front-end, seu SPA funcionará com AEM e seus recursos de criação de conteúdo.
Se você tiver esses princípios em mente ao desenvolver seu SPA, ele será o mais flexível e a prova futura possível, além de permitir a funcionalidade de criação AEM suportada.
Se você não precisar suportar os recursos de criação AEM, talvez precise considerar um SPA modelo de design diferente.
Como ao desenvolver qualquer componente, seus componentes devem ser projetados de modo a maximizar sua portabilidade. Quaisquer padrões que funcionem contra a portabilidade ou a reusabilidade dos componentes devem ser evitados para garantir a compatibilidade, flexibilidade e manutenção futura.
O SPA resultante deve ser construído com componentes altamente portáteis e reutilizáveis.
O desenvolvedor front-end deve se considerar responsável pela criação de uma biblioteca de componentes SPA usados para criar o aplicativo. O desenvolvedor front-end tem controle total da estrutura interna dos componentes. No entanto, AEM sempre possui a estrutura do site.
Isso significa que o desenvolvedor front-end pode adicionar conteúdo ao cliente antes ou depois do ponto de entrada dos componentes e também pode fazer chamadas de terceiros dentro do componente. No entanto, o desenvolvedor de front-end não está no controle total de como os componentes são aninhados, por exemplo.
O SPA deve depender apenas da renderização dinâmica do conteúdo. Essa é a expectativa padrão na qual AEM busca e renderiza todos os filhos da estrutura de conteúdo.
Qualquer renderização explícita que aponte para um conteúdo específico é considerada uma renderização estática e, embora seja suportada, não será compatível com AEM recursos de criação de conteúdo. Isso também vai contra o princípio de portability.
Assim como na renderização, todos os roteamentos também devem ser dinâmicos. No AEM, o SPA deve ser o proprietário do roteamento e AEM o escuta e busca conteúdo com base nele.
Qualquer roteamento estático funciona de acordo com o princípio de portabilidade e limita o autor ao não ser compatível com os recursos de criação de conteúdo da AEM. Por exemplo, com roteamento estático, se o autor do conteúdo quiser alterar uma rota ou uma página, ele ou ela precisará solicitar que o desenvolvedor de front-end faça isso.
Qualquer projeto AEM deve aproveitar o AEM Project Archetype, que suporta projetos SPA usando React ou Angular e aproveita o SPA SDK.
Se os princípios de desenvolvimento de SPA em AEM forem seguidos, seu SPA funcionará com todos os recursos de criação AEM conteúdo suportados.
No entanto, podem existir casos em que tal não seja inteiramente necessário. A tabela a seguir apresenta uma visão geral dos vários modelos de design, suas vantagens e suas desvantagens.
Modelo de design |
Vantagens | Desvantagens |
---|---|---|
AEM é usado como um CMS sem cabeçalho sem usar SPA estrutura SDK do Editor. | O desenvolvedor front-end tem controle total sobre o aplicativo. | Os autores de conteúdo não podem aproveitar AEM experiência de criação de conteúdo. O código não é portátil nem reutilizável se contiver referências estáticas ou roteamento. Não permite o uso do editor de modelo, portanto, o desenvolvedor front-end deve manter modelos editáveis por meio do JCR. |
O desenvolvedor front-end usa a estrutura do SDK do Editor de SPA, mas abre apenas algumas áreas para o autor do conteúdo. | O desenvolvedor mantém controle sobre o aplicativo, permitindo apenas a criação em áreas restritas do aplicativo. | Os autores de conteúdo são restritos a um conjunto limitado de experiências de criação de conteúdo AEM. O código pode não ser portátil nem reutilizável se contiver referências estáticas ou roteamento. Não permite o uso do editor de modelo, portanto, o desenvolvedor front-end deve manter modelos editáveis por meio do JCR. |
O projeto aproveita totalmente o SDK do Editor de SPA e os componentes de front-end são desenvolvidos como uma biblioteca e a estrutura de conteúdo do aplicativo é delegada à AEM. | O aplicativo é reutilizável e portátil. O autor do conteúdo pode editar o aplicativo usando AEM experiência de criação de conteúdo. O SPA é compatível com o editor de modelo. |
O desenvolvedor não controla a estrutura do aplicativo e a parte do conteúdo delegada ao AEM. O desenvolvedor ainda pode reservar áreas do aplicativo para o conteúdo que não deve ser criado usando AEM. |
Embora todos os modelos sejam suportados em AEM, somente ao implementar o terceiro (e, portanto, seguir os SPA princípios de desenvolvimento recomendados em AEM) os autores de conteúdo poderão interagir e editar o conteúdo do SPA na AEM, conforme estiverem acostumados.
Geralmente, se seu SPA seguir os SPA Princípios de desenvolvimento para AEM, então seu SPA funcionará em AEM e poderá ser editado usando o Editor de SPA de AEM.
Siga estas etapas para preparar seu SPA existente para trabalhar com AEM.
Torne seus componentes JS modulares.
Torne-os capazes de serem renderizados em qualquer ordem, posição e tamanho.
Use os container fornecidos pelo SDK para colocar seus componentes na tela.
AEM fornece um componente de sistema de página e parágrafo para você usar.
Crie um componente AEM para cada componente JS.
Os componentes AEM definem a caixa de diálogo e a saída JSON.
A principal tarefa para que um desenvolvedor de front-end crie um SPA para AEM é concordar com os componentes e seus modelos JSON.
A seguir está um resumo das etapas que um desenvolvedor front-end precisa seguir ao desenvolver um SPA para AEM.
Concordar em componentes e em seus modelos JSON
Desenvolvedores front-end e desenvolvedores de AEM back-end precisam concordar sobre quais componentes são necessários e um modelo para que haja uma correspondência individual entre SPA componentes e os componentes back-end.
AEM componentes ainda são necessários principalmente para fornecer caixas de diálogo de edição e exportar o modelo do componente.
Em Reagir componentes, acesse o modelo viathis.props.cqModel
Depois que os componentes forem aceitos e o modelo JSON estiver implementado, o desenvolvedor front-end poderá desenvolver o SPA e simplesmente acessar o modelo JSON via this.props.cqModel
.
Implementar o render()
método do componente
O desenvolvedor de front-end implementa o método render()
conforme ele/ela julgar adequado e pode usar os campos da propriedade cqModel
. Isso gera os fragmentos DOM e HTML que serão inseridos na página. Essa é a maneira padrão de criar um aplicativo no React.
Mapeie o componente para o tipo de recurso AEM viaMapTo()
O mapeamento armazena classes de componentes e é usado internamente pelo componente Container
fornecido para recuperar e instanciar dinamicamente componentes com base no tipo de recurso fornecido.
Isso serve como a "colagem" entre front-end e back-end para que o editor saiba a quais componentes os componentes reagem correspondem.
Os Page
e ResponsiveGrid
são bons exemplos de classes que estendem a base Container
.
Defina o parâmetro do componente EditConfig
comoMapTo()
Esse parâmetro é necessário para informar ao editor como o componente deve ser nomeado desde que ainda não seja renderizado ou não tenha conteúdo para renderizar.
Estender a Container
classe fornecida para páginas e container
Os sistemas de páginas e parágrafos devem estender essa classe para que a delegação aos componentes internos funcione como esperado.
Implemente uma solução de roteamento que use a History
API HTML5.
Quando ModelRouter
estiver ativado, chamar as funções pushState
e replaceState
acionará uma solicitação para PageModelManager
buscar um fragmento ausente do modelo.
A versão atual do ModelRouter
suporta apenas o uso de URLs que apontam para o caminho de recurso real dos pontos de entrada do Modelo Sling. Ele não suporta o uso de URLs personalizados ou aliases.
O ModelRouter
pode ser desativado ou configurado para ignorar uma lista de expressões regulares.
Esses blocos de código ilustram como seus componentes React e Angular não precisam de nada que seja Adobe ou AEM específico.
O auxiliar MapTo
é a "cola" que permite que os componentes de back-end e de front-end sejam combinados:
Para obter mais informações sobre como usar MapTo
e criar SPA para AEM em geral, consulte o guia Introdução para sua estrutura selecionada.
A arquitetura geral de AEM incluindo ambientes de desenvolvimento, criação e publicação não é alterada ao usar SPA. No entanto, é útil entender como o desenvolvimento SPA se encaixa nessa arquitetura.
Criar Ambiente
É aqui que a origem do aplicativo SPA e a fonte do componente são desconectadas.
AEM Author
O conteúdo é criado no autor AEM, incluindo a criação de SPA.
Quando um SPA é editado usando o Editor SPA no ambiente de criação:
cq-data
.cq-data
permitem que o editor carregue informações adicionais da página para que ele saiba quais configurações de edição estão disponíveis para os componentes.AEM Publish
É aqui que o conteúdo criado e as bibliotecas compiladas, incluindo artefatos SPA aplicativos, clientlibs e componentes, são publicados para consumo público.
Dispatcher / CDN
O dispatcher serve como a camada de cache de AEM para visitantes no site.
Dentro AEM não há necessidade de executar os mecanismos de criação do Javascript ou executar o próprio Javascript. AEM hospeda somente os artefatos compilados do aplicativo SPA.
Para obter uma visão geral de como um SPA simples no AEM está estruturado e como ele funciona, consulte o guia de introdução para React e Angular.
Para obter um guia passo a passo para a criação de seu próprio SPA, consulte Introdução ao Editor de SPA AEM - Tutorial de Eventos WKND.
Para obter mais detalhes sobre o modelo dinâmico para mapeamento de componentes e como ele funciona dentro do SPA em AEM, consulte o artigo Dynamic Model to Component Mapping for SPA.
Se você quiser implementar SPA no AEM para uma estrutura diferente de React ou Angular ou simplesmente quiser aprofundar-se em como o SDK SPA para AEM funciona, consulte o artigo SPA Blueprint.