Aprender sobre pacotes e o ciclo de vida da solicitação

Objetivos de aprendizagem

Após concluir esta unidade, você estará apto a:
  • Descrever a diferença entre uma página do Visualforce e um pacote de componentes do Aura e como cada um deles é representado em recursos localmente e no Salesforce.
  • Descrever as diferenças básicas entre o ciclo de vida da solicitação do componente do Aura e do Visualforce e onde o código do componente é executado.

Conceitos centrais

Neste módulo, discutimos conceitos e recursos do Visualforce, depois descrevemos os equivalentes mais próximos para os componentes do Aura. Nem tudo possui uma equivalência exata. O Visualforce e o Aura têm diferenças de arquitetura fundamentais e diferentes requisitos com relação à maneira como são usados para criar aplicativos. Vamos explicar tantas dessas diferenças quanto pudermos, usando os recursos individuais como referências.

Observe que não vamos explicar aqui de maneira detalhada como usar os recursos dos componentes do Aura. (Isso é discutido no módulo Noções básicas sobre componentes do Aura.) Em vez disso, vamos nos concentrar em esclarecer as diferenças essenciais, para que você possa evitar transformar coisas que parecem ser iguais em deslizadores nos quais você vai perder seu tempo deslizando para baixo.

Conceito: Página vs. Pacote

Antes de lidarmos com alguns dos conceitos abstratos, vamos discutir algo relativamente concreto: como uma página ou componente individual é armazenado no Salesforce.

Páginas do Visualforce (e componentes do Visualforce, mas vamos deixar estes últimos de lado por enquanto) são armazenadas no Salesforce como uma única entidade, uma ApexPage. Quando você usa Extensões do Salesforce para Visual Studio Code ou outra ferramenta para copiar suas páginas do Visualforce no armazenamento local e trabalhar com elas, uma página individual do Visualforce é representada como dois arquivos no diretório de metadata/pages:

  • yourPageName.page
  • yourPageName.page-meta.xml

O primeiro é o código para a página e o segundo são os metadados da página (versão da API, configurações móveis, etc.).

Embora sua página possa ter dependências em outros artefatos, como uma extensão ou um controlador do Apex, recursos estáticos e assim por diante, elas são separadas da página. Sua página faz referência a elas, mas não as inclui.

Um componente do Aura é mais do que apenas um único artefato de código mais metadados, podendo incluir até oito artefatos de código hoje em dia, além de metadados (total de nove). Por essa razão, um componente individual fica armazenado em um pacote que inclui recursos. Esse pacote é representado como uma pasta de arquivos quando você o salva em seu armazenamento local. Um componente complexo pode ter esta aparência: Um exemplo de pacote de componentes

Vamos falar sobre os recursos mais importantes no pacote de componentes durante todo o resto deste módulo. Para o restante, consulte os detalhes em Pacotes de componentes e em outras partes do Guia do desenvolvedor de componentes do Aura do Lightning.

Escada! Use essas etapas para criar um pacote de componentes do Aura no Visual Studio Code com a ferramenta Extensões do Salesforce instalada:
  1. Pressione Command+Shift+P no Mac ou Ctrl+Shift+P no Windows ou no Linux para abrir a Paleta de comandos.
  2. Crie um projeto na Paleta de comandos usando SFDX:Create Project.
  3. Crie um pacote de componentes na Paleta de comandos usando SFDX:Create Aura Component. NotaNo desafio desta unidade, você autoriza o Visual Studio Code a implantar arquivos em sua organização. Você precisa saber o nome de usuário e a senha de sua organização. Para obter seu nome de usuário e senha para o Trailhead Playground, consulte o módulo Gerenciamento do Trailhead Playground.
    Para saber mais, consulte o módulo Habilidades e ferramentas para componentes do Aura.

Conceito: Lado do servidor v. Lado do cliente

Essa é uma das duas coisas importantes “óbvias”. Embora, na verdade, ela não tenha nada de óbvio. Vamos esclarecer o que isso significa e depois esclarecer também algumas das implicações.

O Visualforce clássico é executado “no lado do servidor”. Ou seja, quando uma página é solicitada, um servidor do Salesforce processa a marcação, depois o HTML resultante é enviado ao navegador do usuário solicitante para exibição. Se a página tem uma expressão (aquelas coisas dentro dos delimitadores “{! }”), ela é avaliada pelo servidor. Referências a variáveis globais são resolvidas no servidor. Se a página acessar uma propriedade do controlador, isso é processado no servidor. E assim por diante. Para os fins desta conversa, todo o “processamento da estrutura” acontece no servidor. (Observe que estamos desconsiderando o uso do Visualforce + JavaScript Remoting como mero contêiner para seu aplicativo em JavaScript. Mas nesse caso você não está de fato usando o Visualforce, exceto como um servidor Web.)

O processo para componentes do Aura é o oposto. Quando um componente é solicitado, os recursos do componente são empacotados e enviados ao navegador do usuário solicitante. A maior parte disso é JavaScript, com alguma marcação para fornecer a estrutura. O navegador executa esse JavaScript, que renderiza o HTML resultante e o insere na “página” existente. (Daqui a pouco vamos explicar essas aspas.) Avaliação de expressão, variáveis globais, propriedades do controlador — tudo isso é resolvido no cliente.

Ciclo de solicitação do Visualforce Ciclo de solicitação dos componentes do Aura
Ciclo de vida da solicitação do Visualforce Ciclo de vida da solicitação dos componentes do Lightning
  1. O usuário solicita uma página
  2. O servidor executa o código subjacente da página e envia o HTML resultante ao navegador
  3. O navegador exibe o HTML
  4. Quando o usuário interage com a página, volte à etapa um
  1. O usuário solicita um aplicativo ou um componente
  2. O pacote do aplicativo ou componente é enviado ao cliente
  3. O navegador carrega o pacote
  4. O aplicativo JavaScript gera a IU
  5. Quando o usuário interage com a página, o aplicativo JavaScript modifica a interface de usuário conforme o necessário (voltar à etapa anterior)

Essa diferença arquitetônica importante possui consequências consideráveis. Por exemplo, seu componente pode interagir com um usuário sem precisar de uma nova solicitação do servidor, mas se seu componente precisar salvar ou carregar novos dados, isso requer, de fato, uma solicitação do servidor.

Isso parece simples, ou até óbvio. Mas tenha em mente que, com o Visualforce clássico, essa interação pode vir com uma nova solicitação e recarregamento de página visível. Com um componente do Aura, a interação do usuário com o JavaScript no lado do cliente parece mais “dinâmica”, mais reativa, então quando chega a hora de carregar novos dados, a latência de uma solicitação do servidor pode de repente parecer lenta para o usuário — mesmo se a experiência como um todo leva menos tempo do que uma solicitação do Visualforce!

Você verá que os componentes do Aura têm um bom desempenho global. Contudo, sem um design cuidadoso de suas solicitações do servidor e de como elas afetam a experiência do usuário, seus usuários podem muito bem achar que o aplicativo é “lento”.

Cobriremos aspectos adicionais dessa diferença nos próximos tópicos, mas você precisa manter toda essa coisa de lado do cliente vs. lado do servidor clara em sua mente ao pensar sobre como as estruturas se comportam.