Aplicativos de página única (SPAs) podem oferecer experiências interessantes para usuários de sites. Os desenvolvedores desejam criar sites usando estruturas de SPA, e os autores desejam editar o conteúdo de um site criado usando essas estruturas diretamente no AEM.
Este artigo apresenta questões 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 no que diz respeito à implantação do no SPA 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 funcionará com AEM e seus recursos de criação de conteúdo.
Se você considerar esses princípios ao desenvolver seu SPA, ele se tornará o mais flexível e inovador possível e, ao mesmo tempo, ativará todas as funcionalidades de criação compatíveis com AEM.
Se você não precisar de suporte para recursos de criação de AEM, considere Modelo de design SPA.
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.
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 sempre é o dono da estrutura do site.
Esse controle 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 uma chamada 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.
O SPA deve depender apenas da renderização dinâmica do conteúdo. Essa expectativa é o padrão onde 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 seja compatível, é compatível com os recursos de criação de conteúdo AEM. É igualmente contrário ao princípio da igualdade portabilidade.
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 uma página, ele deverá solicitar que o desenvolvedor de front-end faça isso.
Qualquer projeto AEM deve usar o Arquétipo de projeto AEM, que oferece suporte a projetos SPA usando o React ou o Angular e usa o SDK do SPA.
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.
No entanto, pode haver casos em que essa funcionalidade não seja totalmente necessária. A tabela a seguir fornece uma visão geral dos vários modelos de design, suas vantagens e suas desvantagens.
Modelo de design |
Vantagens | Desvantagens |
---|---|---|
O AEM é usado como um CMS headless sem usar o Estrutura do SDK do editor de SPA. | O desenvolvedor front-end tem controle total sobre o aplicativo. | Os autores de conteúdo não podem usar a experiência de criação de conteúdo AEM. 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 modelos, portanto, o desenvolvedor de front-end deve manter modelos editáveis por meio do JCR. |
O desenvolvedor de front-end usa a estrutura do SDK do Editor de SPA, mas abre apenas algumas áreas para o autor de conteúdo. | O desenvolvedor mantém controle sobre o aplicativo, habilitando apenas a criação em áreas restritas do aplicativo. | Os autores de conteúdo estão restritos a um conjunto limitado de experiências de criação de conteúdo no AEM. O código corre o risco de não ser portátil ou reutilizável se contiver referências estáticas ou roteamento. Não permite o uso do editor de modelos, portanto, o desenvolvedor de front-end deve manter modelos editáveis por meio do JCR. |
O projeto usa 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 ao AEM. | O aplicativo é reutilizável e portátil. O autor de conteúdo pode editar o aplicativo usando a experiência de criação de conteúdo AEM. O SPA é compatível com o editor de modelos. |
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 no AEM, somente implementando o terceiro (e seguindo o recomendado) Princípios de desenvolvimento do SPASPA ) são os autores de conteúdo capazes de interagir com o AEM e editar seu conteúdo.
Geralmente, se o seu SPA seguir o Princípios de desenvolvimento do SPA para AEM, em seguida, o SPA funciona no AEM e pode ser editado usando o Editor de AEM do SPA.
Siga estas etapas para preparar seu SPA existente para trabalhar com AEM.
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 esboço das etapas que um desenvolvedor de front-end deve 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 devem 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 viathis.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étodo
O desenvolvedor de front-end implementa o render()
como bem entenderem e podem usar os campos de cqModel
propriedade. Esse método gera os fragmentos DOM e HTML inseridos na página. Esse método também é a maneira padrão de criar um aplicativo no React.
Mapear o componente para o tipo de recurso AEM viaMapTo()
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.
Este mapa 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
e ResponsiveGrid
são bons exemplos de classes que estendem a base Container
.
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êineres
Os 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 o pushState
e replaceState
acionar uma solicitação para o PageModelManager
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.
Esses blocos de código ilustram como os componentes do React e do Angular não precisam de nada específico do Adobe ou do AEM.
A variável MapTo
helper é a "cola" que permite que os componentes de back-end e front-end sejam combinados:
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.
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
Nesse ambiente, a origem do aplicativo SPA e a origem do componente são verificadas.
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:
cq-data
atributos.cq-data
Os atributos permitem que o editor carregue informações de página adicionais para que saiba quais configurações de edição estão disponíveis para os componentes.AEM Publish
Onde o conteúdo criado e as bibliotecas compiladas, incluindo artefatos de aplicativo SPA, bibliotecas de clientes 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.
Dentro do AEM, não há necessidade de executar mecanismos de criação JavaScript ou executar o próprio JavaScript. O AEM hospeda somente os artefatos compilados do aplicativo SPA.