Aprender conceitos arquitetônicos

Objetivos de aprendizagem

Após concluir esta unidade, você estará apto a:
  • Descrever como o paradigma da página do Visualforce e o paradigma do componente do Aura são diferentes.
  • Explicar o conceito de diferentes contêineres e como inserir um aplicativo ou componente do Aura em um contêiner.

Conceito: Aplicativo página a página vs. de página única

Ao projetar um aplicativo tradicional baseado no Visualforce, você normalmente cria um conjunto de páginas, e os usuários do aplicativo o navegam indo de uma página para outra. Você começa em uma página de modo de exibição de lista, clica em um link de exibição para ir para uma página de exibição de registro, clica em um botão editar para ir para uma página de edição de registro e assim por diante.

Aplicativos com componentes do Aura são muito diferentes. Há apenas uma “página” para todo o aplicativo! Esses são os chamados “aplicativos de página única” (“single-page applications” ou SPAs). SPAs carregam uma única página e um monte de JavaScript. Depois de carregado, o JavaScript é executado e atualiza a interface de usuário da “página” daí em diante.

Em vez de navegar de uma página para outra, os usuários navegam de um estado para outro. Um estado representa o modo em que seu aplicativo se encontra no momento: o estado de modo de exibição de lista, o estado de exibição de registro e assim por diante.

O SPA sabe quais componentes carregar para cada estado, e esses componentes sabem como se desenhar ou se renderizar.

Há duas coisas que você deve ter em mente. A primeira é que a navegação é muito diferente nos componentes do Aura. Dependendo de quão complexo é seu aplicativo e onde ele é executado, talvez você nunca precise se preocupar com a navegação. Diga adeus a PageReference, $Action e ao antipadrão de URLs criadas manualmente. (Que horror!)

O mais provável, porém, é que você precise aprender alguns truques novos. Consulte a seção Recursos para obter algumas sugestões.

A segunda coisa... na verdade, vamos dividir isso em um novo conceito.

Conceito: Página vs. Componente

Mais cedo, falamos sobre como as páginas do Visualforce e os componentes do Aura são armazenados no Salesforce. Embora existam algumas diferenças nos detalhes, nesse nível eles ainda são mais ou menos iguais. São um bloco de código, e esse bloco de página ou de componente é o bloco de construção fundamental com o qual você trabalha.

Mas a maneira como você constrói com os dois diferentes tipos de blocos é (você sabia que isso estava vindo) muito diferente.

Nota

Nota

Por enquanto, vamos ignorar os componentes do Visualforce. Falaremos sobre eles na próxima seção.

Em termos simples, uma página do Visualforce é um bloco de construção “grande”. Embora você possa incluí-lo como um “widget” em um layout de página ou deslocar uma página para outra com a marca <apex:include>, você só faria isso com umas poucas páginas. Você não reúne uma coleção de páginas “pequenas” para construir uma página “média”, depois junta várias destas para construir uma página “grande”. O Visualforce não foi projetado para isso e, se você tentar, vai obter... um comportamento problemático.

Um componente do Aura é diferente. Um componente “grande” do Aura pode ser composto de dezenas ou até centenas de componente menores, que podem eles mesmos ser compostos de vários componentes ainda menores. O modelo de programação do Aura foi projetado para tratar milhares de componentes reunidos em um único aplicativo.

Pegar componentes pequenos, bastante específicos, e reuni-los para formar um componente do “nível acima”, depois repetir, repetir e repetir, é o processo de design fundamental ao se utilizar componentes do Aura. Em design de software, isso se chama composição, e pode-se ver claramente a similaridade entre as palavras “componente” e “composição” (com é a raiz latina que significa junto ou simplesmente com). Isso não é acidental.

De modo geral, uma página do Visualforce é concebida para ser autônoma. Essa é uma das razões, entre outras, pelas quais é possível acessá-la com uma URL exclusiva e permanente.

Um componente do Aura, no entanto, deve ser uma parte de um todo maior — independentemente de quão “grande” seja esse componente. Não é possível acessar um componente individual em uma URL específica. Para executar um componente, você deve adicioná-lo a algo maior, como fizemos no módulo Habilidades e ferramentas para componentes do Aura .

Isso envolve mais, muito mais, do que podemos discutir aqui — existem livros inteiros escritos sobre o uso de componentes no design de software. Por enquanto, lembre-se apenas do seguinte: Não trate um componente como uma página!

Conceito: Componente vs. Componente

Nas seções anteriores, ignoramos os componentes do Visualforce. Isso não parece justo. Afinal de contas, as muitas “marcas” integradas da estrutura do Visualforce são nada mais do que componentes chamados por outro nome. Obviamente, o Visualforce tem componentes, e as páginas do Visualforce podem usar centenas das “marcas” integradas, o que soa bastante similar aos componentes do Aura. Qual é a diferença?

Em termos simples, quando nós, da Salesforce, criamos um novo componente (ou marca) do Visualforce, temos acesso a mais recursos do que você, quando desenvolve componentes personalizados do Visualforce. Colocamos muitos desses recursos de volta no lado dos componentes do Aura voltado para os clientes. Os componentes personalizados do Visualforce são menos avançados, menos funcionais do que os componentes personalizados do Aura.

Observação importante! Temos muitos clientes que criam componentes do Visualforce de forma eficaz. Os componentes personalizados do Visualforce são bons! Usá-los é ótimo! Eles são um sinal de uma empresa de desenvolvimento sofisticada e normalmente levam a custos reduzidos de desenvolvimento de software com o decorrer do tempo. Não estamos dizendo que os componentes personalizados do Visualforce são ruins.

Mas os componentes do Aura são melhores. São mais sofisticados e mais avançados. Com o decorrer do tempo e com o uso correto, é possível criar software melhor e mais avançado a um custo comparável.

Vamos ver especificamente algumas das maiores diferenças.

  • Os componentes do Aura podem acionar e receber eventos para se comunicar entre componentes. Você pode trabalhar com eventos de estrutura ou contêiner ou definir seus próprios eventos. Você escreve manipuladores de evento e a estrutura se encarrega dos detalhes de invocá-los quando o evento certo ocorrer. Isso é algo enorme e abre fronteiras totalmente novas no design de seus aplicativos. Não há nada comparável no Visualforce, a menos que você mesmo o crie. Nesse caso, parabéns, você tem sua própria estrutura! Agora você só precisa de um nome irônico para ela, um repositório do GitHub e um chapéu de hipster.
  • A estrutura do pacote de componentes do Aura possui artefatos separados para funções separadas e os “conecta automaticamente”. Poder agrupar as dependências essenciais de um componente e, ao mesmo tempo, manter elementos diferentes separados é uma ferramenta organizacional incrível. Provedores de valor, entre outros, fazem com que seja fácil usar os diferentes elementos com mínima cerimônia. Mais uma vez, para se conseguir algo comparável no Visualforce significa que você precisa escrever o código da estrutura, não o código do recurso.
  • Os componentes do Aura podem ser usados em mais contextos. Na verdade, como se trata de código do lado do cliente, você pode usar o Lightning Out para deslocar os seus recursos do “Salesforce” para outros aplicativos e contextos que não têm nada a ver com o Salesforce — alguém aí falou em SharePoint? O Visualforce, por estar vinculado ao servidor, só funciona no Salesforce.

Esta lista poderia continuar, mas é melhor passarmos para os conceitos adicionais. Esperamos que, ao fim deste módulo, você tenha uma boa ideia dos motivos pelos quais deve considerar dar uma conferida nos componentes do Aura.

Conceito: Contêineres de aplicativos

Contêineres de aplicativos (ou apenas contêineres, para abreviar) são um novo conceito para a maioria dos desenvolvedores Salesforce. Em termos simples, um contêiner é um contexto de aplicativo, ou um ambiente onde seu código é executado. O contêiner mais óbvio para seus componentes do Aura é o Lightning Experience. Como o Lightning Experience e o aplicativo Salesforce compartilham muito código em comum, que é acessado por meio da mesma URL, às vezes nos referimos aos dois combinados como “contêiner one.app”. (A URL comum para ambos termina em one.app.)

Nota

Nota

Há diferenças importantes entre o Lightning Experience e o aplicativo Salesforce, porque o aplicativo Salesforce é mais comumente acessado por meio de um aplicativo nativo em um dispositivo móvel, em vez de em um navegador da Web. Não vamos discutir isso aqui, mas preste atenção.

Talvez você tenha adivinhado que pelo menos um contêiner adicional é o contêiner do Salesforce Classic. Abaixo se encontra uma lista (não necessariamente completa) de contêineres distintos onde seu código pode ser executado.

  • Salesforce Classic
  • Visualforce
  • Aplicativo Salesforce
  • Lightning Experience
  • Criador de aplicativo Lightning (LAB)
  • Aplicativos do console do Lightning
  • Comunidades
  • Componentes do Lightning para Visualforce (LC4VF)
  • Lightning Out
  • Lightning para Outlook e Lightning para Gmail
  • Aplicativo autônomo my.app

Você provavelmente está pensando duas coisas após ter lido essa lista.

  1. Isso é muito contêiner. Qual é a diferença? Por que isso me interessa? (A resposta curta: serviços de contêiner.)
  2. Um momento. Alguns desses não são a mesma coisa? As páginas do LAB não são simplesmente Lightning Experience? Por que o Visualforce é seu próprio contêiner e como ele difere do LC4VF? (A resposta curta: bonecas russas.)

Serviços de contêiner

Lembre-se de que um contêiner é um contexto de aplicativo, ou um ambiente onde seu código é executado. Diferentes ambientes oferecem diferentes serviços.

Por exemplo, o contêiner one.app (Lightning Experience e aplicativo Salesforce) oferece diversos serviços, incluindo tratar eventos para acessar um registro, criar ou editar um registro, abrir uma URL e assim por diante.

Outros contêineres não oferecem esses serviços. Um componente que depende de serviços em um contêiner não funciona em um contêiner diferente que não tem esses serviços. Por exemplo, se você usar o evento force:createRecord para criar novos registros, isso funciona muito bem no Lightning Experience, mas se usar esse componente em um aplicativo autônomo ou no Lightning Experience Out, ele para de funcionar, pois não há nada para tratar aquele evento.

Se uma árvore cair em uma floresta, mas não houver ninguém lá para ouvir, ela produz um som? Vamos deixar essa pergunta para os filósofos.

Mas... se você aciona um evento em um contêiner onde não há nada escutando, ele produz um efeito? Essa podemos responder nós mesmos. Não.

Ir além das noções básicas

Qual a solução alternativa? Escrever seu próprio serviço de contêiner para criar registros e um manipulador de evento para pegar o evento force:createRecord e enviá-lo a seu serviço personalizado.

Se parece trabalhoso é porque, de fato, é. Oferecer serviços de contêiner robustos é difícil. Há equipes de engenharia inteiras dedicadas só a isso. Vá progredindo até chegar a esse tópico avançado e, enquanto isso, verifique o AppExchange se precisar de serviços para uso fora do Lightning Experience e do aplicativo Salesforce.

Não temos espaço aqui para fornecer uma lista completa de serviços e mapeá-los para os contêineres. Leia a documentação sobre os recursos que quer usar e fique atento a avisos como este.

Este evento é tratado pelo contêiner one.app. Só tem suporte no Lightning Experience e no aplicativo Salesforce.

Contenção de contêiner (também conhecida como a Situação das “bonecas russas”)

Um contêiner possui limites. Paredes. Barreiras. Um contêiner mantém dentro o que deve estar dentro e fora o que deve estar fora.

Isso também se aplica a contêineres de aplicativos. Com estruturas e aplicativos da Web os limites são frequentemente baseados em um iframe de HTML, que é imposto pelo navegador. O código dentro do iframe não pode acessar diretamente elementos fora do iframe.

Há ainda outros limites. Por exemplo, o próprio contêiner pode impor um limite, interceptando eventos acionados dentro dele.

Aqui está a parte divertida. Você pode colocar contêineres menores dentro de contêineres maiores, criando múltiplas “camadas” na hierarquia de contenção. As matrioskas, popularmente conhecidas como bonecas russas, são uma ótima metáfora para os contêineres de aplicativos para seus componentes do Aura. Contêineres contendo contêineres contendo contêineres...

Você pode ter componentes do Aura (4) sendo executados em uma página do Visualforce (3) usando LC4VF. Depois, você pode adicionar essa página do Visualforce ao Lightning Experience. Aí já são três contêineres. Ou você pode usar o LAB para adicionar a página do Visualforce a uma página do Lightning Experience (2), depois adicionar essa página do Lightning Experience ao Lightning Experience (1). Aí são quatro contêineres. E não é difícil chegar a cinco ou até seis camadas de contêineres.

Aqui está a parte importante. O código do seu componente do Aura pode acessar apenas os serviços do contêiner dentro do qual está sendo executado, mesmo que esse contêiner esteja dentro de outro contêiner.

O que acontece então com aquele componente do Aura dentro de uma página do Visualforce? Ele não consegue acionar eventos do Lightning Experience que funcionem, pois o contêiner do Visualforce não entende os eventos ou os passa para o contêiner seguinte acima dele, mesmo que você adicione aquela página do Visualforce ao Lightning Experience. O limite do iframe entre o Visualforce e o Lightning Experience bloqueia esses eventos.

Resumindo: Seu componente só pode contar com os serviços do contêiner no qual está sendo executado. Se você criar um componente para múltiplos contextos, precisará de múltiplos caminhos de código para diferentes conjuntos de serviços. Consulte Componentes do Lightning no Visualforce com Lightning Out para obter um exemplo dessa técnica.