Desenvolvimento de SPAs para o AEM developing-spas-for-aem
Aplicativos de página única (SPAs) podem oferecer experiências interessantes para usuários de sites. Os desenvolvedores desejam criar sites usando estruturas SPA, e os autores desejam editar o conteúdo no Adobe Experience Manager (AEM) para um site criado com essas estruturas.
Este artigo apresenta perguntas importantes a serem consideradas ao envolver um desenvolvedor de front-end para desenvolver um SPA para AEM e fornece uma visão geral da arquitetura do AEM em relação à implantação do no SPA AEM.
Princípios de desenvolvimento do SPA para AEM spa-development-principles-for-aem
O desenvolvimento de aplicativos de página única no AEM parte do princípio de que o desenvolvedor de front-end segue as práticas recomendadas padronizadas ao criar um SPA. Se, como desenvolvedor de front-end, você seguir essas práticas recomendadas gerais e alguns princípios específicos do AEM, seu SPA estará funcional com AEM e seus recursos de criação de conteúdo.
- Portabilidade - Assim como com qualquer componente, os componentes devem ser criados para serem o mais portáteis possível. O SPA deve ser desenvolvido com componentes portáteis e reutilizáveis.
- AEM controla a estrutura do site - O desenvolvedor de front-end cria componentes e tem a propriedade de sua estrutura interna, mas depende do AEM para definir a estrutura de conteúdo do site.
- Renderização dinâmica - Todas as renderizações devem ser dinâmicas.
- Roteamento Dinâmico - O SPA é responsável pelo roteamento e o AEM o escuta e busca com base nele. Qualquer roteamento também deve ser dinâmico.
Se você considerar esses princípios ao desenvolver seu SPA, ele será o mais flexível e inovador possível e, ao mesmo tempo, ativará todas as funcionalidades de criação compatíveis com AEM.
Se não precisar de suporte para recursos de criação de AEM, talvez seja necessário considerar um Modelo de design SPA.
Portabilidade portability
Assim como no desenvolvimento de qualquer componente, seus componentes devem ser projetados de forma a maximizar sua portabilidade. Quaisquer padrões que funcionem contra a portabilidade ou reutilização dos componentes devem ser evitados para garantir a compatibilidade, a flexibilidade e a manutenção no futuro.
O SPA resultante deve ser construído com componentes altamente portáteis e reutilizáveis.
AEM direciona a estrutura do site aem-drives-site-structure
O desenvolvedor de front-end deve se considerar responsável pela criação de uma biblioteca de componentes SPA usados para criar o aplicativo. O desenvolvedor de front-end tem controle total da estrutura interna dos componentes. No entanto, o AEM, em todos os momentos, é o dono da estrutura do site.
Isso significa que o desenvolvedor de front-end pode adicionar conteúdo do 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 tem controle total sobre como os componentes se aninham, por exemplo.
Renderização dinâmica dynamic-rendering
O SPA deve depender apenas da renderização dinâmica do conteúdo. Essa é a expectativa padrão em que o 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 renderização estática e, embora suportada, não será compatível com os recursos de criação de conteúdo AEM. Isto é igualmente contrário ao princípio da portabilidade.
Roteamento Dinâmico dynamic-routing
Assim como na renderização, todo o roteamento também deve ser dinâmico. No AEM, o SPA sempre deve ser o proprietário do roteamento e o AEM escuta e busca conteúdo com base nela.
Qualquer roteamento estático funciona contra o princípio da portabilidade e limita o autor por não ser compatível com os recursos de criação de conteúdo do AEM. Por exemplo, com o roteamento estático, se o autor de conteúdo quiser alterar uma rota ou alterar uma página, ele terá que solicitar que o desenvolvedor de front-end faça isso.
Arquétipo de projeto do AEM aem-project-archetype
Qualquer projeto do AEM deve utilizar o Arquétipo de projeto do AEM, que aceita projetos SPA que usam o React ou o Angular e utiliza o SDK de SPA.
Modelos de design SPA spa-design-models
Se a variável princípios do desenvolvimento do AEM no SPA forem seguidos, o SPA funcionará com todos os recursos de criação de conteúdo AEM compatíveis.
Pode haver casos em que isso não seja totalmente necessário. A tabela a seguir fornece uma visão geral dos vários modelos de design, suas vantagens e suas desvantagens.
Migração do AEM existente para o SPA migrating-existing-spas-to-aem
Geralmente, se o seu SPA seguir o Princípios de desenvolvimento do SPA para AEM, em seguida, seu SPA funcionará no AEM e será editável usando o editor de AEM do SPA.
Siga estas etapas para preparar seu SPA existente para trabalhar com AEM.
-
Torne seus componentes JS modulares.
Torne-os capazes de ser renderizados em qualquer ordem, posição e tamanho.
-
Use os contêineres fornecidos pelo SDK do Adobe para colocar seus componentes na tela.
O 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.
Instruções para desenvolvedores de front-end instructions-for-front-end-developers
A principal tarefa de envolver um desenvolvedor de front-end para criar um SPA para AEM é chegar a um acordo sobre os componentes e seus modelos JSON.
Veja a seguir um resumo das etapas que um desenvolvedor de front-end precisa seguir ao desenvolver um SPA para AEM.
-
Concordar sobre os componentes e seu modelo JSON
Desenvolvedores de front-end e desenvolvedores de AEM de back-end precisam concordar sobre quais componentes são necessários e um modelo para que haja uma correspondência individualizada entre os componentes de SPA e os componentes de back-end.
Os componentes do AEM ainda são necessários, principalmente para fornecer caixas de diálogo de edição e exportar o modelo de componentes.
-
Nos componentes do React, acesse o modelo via
this.props.cqModel
Quando os componentes forem acordados e o modelo JSON estiver em vigor, o desenvolvedor de front-end poderá desenvolver o SPA e simplesmente acessar o modelo JSON por meio de
this.props.cqModel
. -
Implementar do componente
render()
métodoO desenvolvedor de front-end implementa o
render()
como bem entenderem e podem usar os campos decqModel
propriedade. Isso gera o DOM e os fragmentos de HTML inseridos na página. Essa é a maneira padrão de criar um aplicativo no React. -
Mapear o componente para o tipo de recurso AEM via
MapTo()
O mapeamento armazena classes de componente e é usado internamente pelo
Container
componente para recuperar e instanciar dinamicamente os componentes com base no tipo de recurso especificado.Isso serve como "cola" entre o front-end e o back-end, para que o editor saiba a quais componentes os componentes de reação correspondem.
A variável
Page
eResponsiveGrid
são bons exemplos de classes que estendem a baseContainer
. -
Definir o
EditConfig
como parâmetro paraMapTo()
Esse parâmetro é necessário para informar ao editor como o componente deve ser nomeado, desde que ainda não tenha sido renderizado ou não tenha conteúdo para renderizar.
-
Estender o fornecido
Container
classe para páginas e contêineresOs sistemas de páginas e parágrafos devem estender essa classe para que a delegação para componentes internos funcione conforme esperado.
-
Implementar uma solução de roteamento que use o HTML
History
API.Quando a variável
ModelRouter
está ativado, chamando opushState
ereplaceState
acionar uma solicitação para oPageModelManager
para buscar um fragmento ausente do modelo.A versão atual do
ModelRouter
O suporta apenas o uso de URLs que apontam para o caminho de recurso real dos pontos de entrada do Modelo Sling. Ele não é compatível com o uso de URLs ou aliases personalizados.A variável
ModelRouter
O pode ser desativado ou configurado para ignorar uma lista de expressões regulares.
AEM-Agnóstico aem-agnostic
Esses blocos de código ilustram como os componentes do React e do Angular não precisam de nada que seja específico do Adobe ou do AEM.
- Tudo o que está dentro do componente JavaScript é independente de AEM.
- No entanto, o que é específico do AEM é que o componente JS deve ser mapeado para um componente AEM com o auxiliar MapTo.
A variável MapTo
helper é a "cola" que permite que os componentes de back-end e front-end sejam combinados:
- Informa ao contêiner JS (ou sistema de parágrafo JS) qual componente JS é responsável pela renderização de cada um dos componentes presentes no JSON.
- Ele adiciona um atributo de dados HTML ao HTML que o componente JS renderiza, para que o Editor de SPA saiba qual caixa de diálogo exibir para o autor ao editar o componente.
Para obter mais informações sobre o uso de MapTo
e a criação do AEM para SPA em geral, consulte o guia de Introdução para a estrutura escolhida.
Arquitetura do AEM e SPA aem-architecture-and-spas
A arquitetura geral do AEM, incluindo ambientes de desenvolvimento, criação e publicação, não é alterada ao usar o SPA. No entanto, é útil compreender como o desenvolvimento do SPA se encaixa nessa arquitetura.
-
Ambiente de compilação
É aqui que a origem do aplicativo SPA e a origem do componente são verificadas.
- O gerador de clientlib do NPM cria uma biblioteca do cliente a partir do projeto SPA.
- Essa biblioteca é retirada pelo Maven e implantada pelo plug-in Maven Build, juntamente com o componente, no autor do AEM.
-
Autor do AEM
O conteúdo é criado sobre o autor de AEM, incluindo a criação de SPA.
Quando um SPA é editado usando o Editor de SPA no ambiente de criação:
- O SPA solicita o HTML externo.
- O CSS é carregado.
- O JavaScript do aplicativo SPA é carregado.
- Quando o aplicativo SPA é executado, o JSON é solicitado, permitindo que o aplicativo crie o DOM da página, incluindo o
cq-data
atributos. - Este
cq-data
Os atributos permitem que o editor carregue informações adicionais da página para que saiba quais configurações de edição estão disponíveis para os componentes.
-
Publicação no AEM
É aqui que o conteúdo criado e as bibliotecas compiladas, incluindo artefatos de aplicativos SPA, clientlibs e componentes, são publicados para consumo público.
-
Dispatcher/CDN
O Dispatcher serve como a camada de armazenamento em cache do AEM para os visitantes do site.
- As solicitações são processadas de forma semelhante à do autor AEM. No entanto, não há solicitação de informações da página, pois elas são necessárias somente para o editor.
- JavaScript, CSS, JSON e HTML são armazenados em cache, otimizando a página para entrega rápida.
Próximas etapas next-steps
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 ambos React e Angular.
Para obter um guia passo a passo sobre como criar seu próprio SPA, consulte o Introdução ao editor SPA AEM - Tutorial de eventos do WKND.
SPA Para mais detalhes sobre o modelo dinâmico para mapeamento de componentes e como ele funciona dentro do AEM, consulte o artigo Modelo dinâmico para mapeamento de componentes para SPA.
Se você quiser implementar o SPA no AEM para uma estrutura diferente do React ou do Angular SPA AEM ou simplesmente quiser se aprofundar em como funciona o SDK do para o, consulte o Blueprint SPA artigo.