Vamos converter esses longos conceitos em códigos. Crie um novo aplicativo Lightning expensesApp.app com a seguinte marcação.
O que está acontecendo é o seguinte. O atributo extends="force:slds" ativa o SLDS neste aplicativo, incluindo os mesmos estilos do Lightning Experience Design System fornecidos pelo Lightning Experience e pelo aplicativo Salesforce. Mas veja que esse aplicativo de aproveitamento é apenas uma cobertura, uma casca. O aplicativo real é o componente expenses, que nós não criamos. (É a parte <!-- c:expenses/ -->; não foi comentada porque não podemos salvar nosso aplicativo até que o componente expenses realmente exista.)
Através do aplicativo de cobertura, nossos componentes usam o mecanismo extends="force:slds" para obter acesso ao SLDS quando eles são executados de dentro deste aplicativo. Quando eles são executados dentro do Lightning Experience ou do aplicativo Salesforce, sem mudanças no código, eles usam a inclusão automática de SLDS daquele contêiner.
Nesse caso, o resultado é o mesmo. Mas esse conceito de usar o aplicativo de aproveitamento externo para definir um contexto para que o aplicativo real não precise se preocupar com diferenças de contexto não está limitado a recursos de estilo. Você pode usar isso para fornecer manipuladores de eventos de substituição, por exemplo... apesar de que isso é falar antes de tempo. Vamos aprender a andar antes de tentarmos voar!
A próxima etapa é criar o componente que é o nível mais alto de nosso aplicativo de despesas. (Lembre-se, apesar de chamarmos de “aplicativo”, na verdade é só mais um componente do Lightning). No Developer Console, crie um novo componente do Aura chamado “expenses” e substitua a marcação padrão pelo seguinte.
O que estamos criando aqui é o cabeçalho da página que usa o layout de grade fornecido pelos componentes <lightning:layout> e <lightning:layoutItem>. size="6" cria um contêiner <div> que representa 50% da largura total (ou tamanho 6 de 12). Como você deve ter reparado, os componentes no namespace lightning se parecem com componentes no Lightning Experience e no aplicativo Salesforce. Além dos botões e layouts, você encontrará muitos outros componentes úteis nesse namespace que funcionam perfeitamente com o estilo SLDS automaticamente.
Reparou na marca <lightning:icon>? Esse componente processa seus ícones SLDS favoritos em um piscar de olhos. Criar um componente auxiliar para exibir ícones SLDS é coisa do passado.
Agora, você pode excluir os comentários na marca <c:expenses/> no próprio .app, e abrir a visualização do que é, no momento, nada mais do que uma casca vazia. Você deverá ver algo mais ou menos como o seguinte.
Ainda não tem muita coisa acontecendo, mas é animador ver que a modelagem SLDS já está causando um efeito. Lembre-se que não vamos explicar a maioria das marcações SLDS, mas vamos incluir comentários na marcação. Você pode ver como criamos o cabeçalho do aplicativo e começar a entender a ideia.
Antes de começarmos com o formulário, vamos já admitir algo sem rodeios: O que vamos fazer aqui é temporário. Lembra de toda aquela conversinha sobre decompor seu aplicativo em componentes menores separados, e depois construir em cima disso? Não vamos fazer isso aqui – ainda não – e para ser honesto é um pouco uma trapaça.
Mas é uma trapaça útil para impedir o código de ficar muito complicado, muito rápido. Estamos fazendo isso desse jeito para que possamos nos concentrar em uma lição de cada vez. Além do mais, não é um jeito ruim de você descobrir as coisas por si mesmo: construir dentro de um componente até que ele fique muito “ocupado” e depois refatorar e decompor em subcomponentes menores. Desde que você se lembre de refatorar novamente!
OK, </preaching>. No componente expenses, substitua o comentário <!-- [[ expense form goes here ]] --> pelo código a seguir para o formulário Adicionar despesa.
Eu sei que parece muito código para entrar na cabeça de uma vez. Não é. Quando você remove as classes e marcações SLDS, esse formulário se resume a uma série de campos de entrada e um botão para o envio de formulários.
<lightning:input> é o canivete suíço para campos de entrada combinado com a beleza do estilo SLDS. Use-o sempre que estiver procurando a variedade de componente <ui:input>, como <ui:inputText>, <ui:inputNumber> e outros. Os componentes no namespace ui não vêm com estilo SLDS e são considerados componentes legados.
Primeiro, observe que estamos criando várias instâncias do componente <lightning:input> com tipos de dados específicos. Ou seja, não é nenhuma surpresa querer usar o type="date" com um campo de data, e assim por diante. Existe uma gama de tipos diferentes, bem além desses especificados, e é sempre melhor combinar o tipo de componente com o tipo de dados. Se você não especificar um tipo, ele será texto por padrão. O motivo pode ainda não ser óbvio, mas será quando você experimentar esse aplicativo em um telefone – componentes específicos do tipo podem fornecer widgets de entrada mais adequados ao fator de formulário. Por exemplo, o seletor de data é otimizado para mouse ou ponta do dedo, dependendo de onde for acessado.
A seguir, perceba que cada componente de entrada tem um rótulo definido e que o texto de rótulo é exibido automaticamente junto do campo de entrada. Existem alguns outros atributos que não vimos antes: required, placeholder, type, min e step. A maioria desses atributos é semelhante a seus equivalentes HTML. Por exemplo, min especifica o valor mínimo para a entrada. Se não conseguir adivinhar para o que eles servem, você pode procurar seu significado na biblioteca de componentes do Lightning. (E vamos voltar para aquele required enganador.)
Em seguida, há um atributo aura:id definido em cada marca. Para que ele serve? Ele define uma ID única (localmente) em cada marca à qual é adicionado, e essa ID é como você vai ler os valores dos campos de formulário. Todos os campos compartilham a mesma ID neste exemplo, para que possamos acessá-los como uma matriz na validação do campo. Vamos ver como fazer isso muito em breve.
Mas primeiro precisamos ver o atributo value. Cada marca tem um valor, definido para uma expressão. Por exemplo, {!v.newExpense.Amount__c}. Do formato da expressão, você deve conseguir deduzir algumas coisas.
v significa que é uma propriedade do provedor de valor de visualização. Isso significa que é um atributo no componente. (Que ainda não criamos.)
Com base na notação de ponto, é possível dizer que newExpense é como um tipo de dados estruturado. Ou seja, o próprio newExpense tem propriedades. Ou... campos?
A partir do “__c” que está no final da maioria dos nomes de propriedade, é possível adivinhar que eles são mapeados de volta para os campos personalizados, provavelmente no objeto personalizado Despesa.