---

Fevereiro de 2017

Volume 32 - Número 2

O programador: Como ser MEAN: Como trabalhar com o Angular

Por Ted Neward | Fevereiro de 2017

Bem-vindos de volta, MEANers. Conforme mencionado no mês anterior, é hora de começar a trabalhar no front-end da pilha MEAN e isso significa aprofundar-se no Angular. A partir deste texto (e provavelmente nos próximos dois anos), um problema é apresentado: o Angular tem um certo problema de identidade. O Angular tem sido fundamental no mundo dos Aplicativos de Página Única por vários anos. No entanto, à medida que foi se desenvolvendo, ele cresceu em um paradigma arquitetônico diferente e, como resultado, o Angular "moderno" cresceu e tornou-se incompatível com as versões anteriores do Angular.

Com isso, os desenvolvedores se depararam com o dilema: qual versão usar?

Embora não haja nunca uma resposta única para o problema, a história tem demonstrado que, com raras exceções, a versão posterior acabará por levar vantagem. Isso leva a uma regra básica geral: Se estiver começando a trabalhar no projeto (um projeto denominado "raiz") e não houver códigos existentes para serem mantidos ou estendidos, use a versão mais recente e estável da estrutura. Como meu aplicativo (o minúsculo portal de avaliações do palestrante no qual tenho me distraído) está definitivamente inserido na categoria raiz ("greenfield"), isso significa que, nas páginas desta série de colunas, usarei o Angular 2 para a versão moderna do Angular e o Angular 1 para o produto original.

Sim, a decisão poderia ter sido inversa. Felizmente, a Internet contém dezenas de bons tutoriais do Angular (e vai ser bom, amigo, se você escolher o Angular 1 para deixar felizes todos os escritores de tutoriais do Angular 1). No entanto, esteja ciente de que a "portabilidade" de um aplicativo Angular 1 para o Angular 2 parece ser mais do que uma reescrita completa, portanto, leve isso em consideração em planos futuros.

Enquanto isso, temos o Angular 2 para explorar.

Introdução

A primeira etapa do trabalho com qualquer nova tecnologia consiste em escrever o universal "Olá Mundo" para ela. No entanto, dois aspectos interessantes surgem imediatamente ao planejar o desenvolvimento de um aplicativo "Olá Mundo" do Angular 2 e que é importante discutir antes de avançar no processo.

Em primeiro lugar, com uma estrutura Web como o Angular, geralmente o processo de instalação é quase que absurdamente leve (em comparação com a instalação de novas linguagens de programação, IDEs, bancos de dados, etc.), pois, na maioria das vezes, a própria biblioteca real pode ser obtida diretamente de uma CDN ou do servidor host. No entanto, para a maioria das tarefas de desenvolvimento, é melhor ter a biblioteca executando o sistema de arquivos local e, como começar com o Angular 2 é o modo padrão, esse será o caminho que vou tomar.

Em segundo lugar, o Angular 2 decide fazer sua estreia através de um repositório Git, ou seja, a abordagem padrão de "introdução" consiste em clonar um repositório Git existente no GitHub, ao contrário de um "modelo de projeto" hospedado pelo IDE. Essa é uma abordagem que está começando a se popularizar com outras linguagens e outras estruturas. Ela tem a vantagem distinta de ser fácil de entender, é trivial de manter e (talvez o mais importante) é simples de ser estendida para incluir recursos adicionais (estrutura, conteúdo, etc.), diferentemente do modelo original.

Assim, supondo que o Node.js esteja instalado na sua máquina (e ele deve estar para os leitores que estiverem acompanhando esta série), o Git solicita o projeto "quickstart" do Angular 2:

git clone https://github.com/angular/quickstart.git hello

Supondo que haja uma conexão com o GitHub e o projeto seja clonado com êxito, uma tonelada de arquivos agora está localizada no subdiretório "olá". Há muito mais, na verdade, do que parece absolutamente necessário para um simples aplicativo "Olá Mundo" e a equipe do Angular já admite isso. No arquivo LEIAME do repositório, eles especificam que estão disponibilizando vários arquivos adicionais para promover alguns bons hábitos desde o início, como testes de unidade e de ponta a ponta (e2e) do código front-end.

Um exame detalhado de tudo isso será realizado posteriormente. Por enquanto, uma olhada pelo diretório revelará alguns itens que devem ser familiares para os MEANers: o pacote.json (o arquivo de manifesto npm) e o tsconfig.json (o arquivo de configuração TypeScript) destacam-se imediatamente. Lembre-se de que a prática padrão ao efetuar pull de um projeto Node.js do controle de origem consiste em inicializar as dependências no local, portanto, antes de executar qualquer outro procedimento, elimine as dependências e dê um sinal de alerta ao projeto executando o procedimento a seguir e, em seguida, navegue para a porta 3000 em um navegador (na verdade, o script geralmente será aberto para você se um servidor HTTP local estiver sendo executado nessa porta):

npm install

npm start

Depois disso, aproveite as cordiais saudações de uma estrutura Web, como mostra a Figura 1.

Figura 1 Estrutura Web Olá do Angular 2

Intrinsecamente, é sempre bom saber que tudo está funcionando, mas os programadores querem ver o código. Volte para o shell da linha de comando que está executando o servidor HTTP e pressione Ctrl+C para desligar tudo. (Se preferir, abra um segundo shell de linha de comando para o mesmo diretório, o que for mais fácil.)

Vamos dar uma olhada nisso?

Olá, Código

É claro que o primeiro lugar em que você pode procurar um código em um aplicativo Angular 2 é no arquivo index.html, mas, na verdade, isso vai ser mais confuso do que útil no momento. Por enquanto, vamos deixá-lo onde está e procurar em outro lugar.

A equipe do Angular será a primeira a admitir que a estrutura de diretórios do Quickstart não foi projetada para ser um guia prescritivo de como estruturar o código, mas geralmente todos os aplicativos do Angular 2 terão algum tipo de diretório de "origem" em que o aplicativo reside fora da raiz principal do projeto. (Isso facilita muito o agrupamento sem que seja necessário efetuar pull de todos os tipos de arquivos somente para desenvolvedores, como o package.json.) No Quickstart, esse diretório é chamado de "app" e contém três arquivos: main.ts e dois arquivos que aparentemente estão estritamente relacionados, o app.component.ts e o app.module.ts. (Observe que o transpilador TypeScript modificará esses arquivos no local para que o diretório possa conter mais do que apenas esses arquivos, mas será um tanto óbvio que eles estejam todos relacionados, por exemplo, main.ts gerará main.js e main.js.map.) O primeiro, main.ts, é claro quanto ao seu propósito. Ele é o ponto de entrada principal para o aplicativo Angular 2. No entanto, os outros dois são um pouco menos óbvios. Porém, vamos examinar todos os três.

Ponto de entrada: Main.ts

O conteúdo de main.ts é um pouco enigmático inicialmente:

import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
import { AppModule } from './app.module';
platformBrowserDynamic().bootstrapModule(AppModule);

Isso não está muito claro. No entanto, vamos examinar cada parte dele. De acordo com a minha última coluna sobre TypeScript, você sabe que a instrução "import" acessa símbolos de um outro arquivo e consegue ver que está importando símbolos de dois locais diferentes. O primeiro, platformBrowserDynamic, é proveniente de algum local nas bibliotecas do Angular, portanto, esse é provavelmente o clichê padrão para inicializar o ambiente e a biblioteca do Angular 2. (A última linha definitivamente confirma isso.) O segundo, no entanto, importa a partir de um arquivo local, o app.module, que parece suspeito por conter o código.

Para a maior parte, main.ts permanece inalterado durante todo o desenvolvimento do Angular 2 com qualquer item relacionado ao aplicativo, pelo menos, residindo no arquivo de módulo (app.module.ts), mas ele é sempre útil para entender o contexto. (Embora não seja recomendado neste ponto, se seguir a trilha de index.html, você acabará encontrando o local em que main.js é carregado através do mecanismo carregador de módulos System.js.) Portanto, isso significa que a maior parte da ação ocorre em app.module e em suas relações.

O Módulo de Aplicativo: App.module.ts

Assim como seu antecessor, o Angular 2 preocupa-se muito com a modularização do código do aplicativo em partes pequenas e gerenciáveis, e a primeira etapa para isso consiste em colocar os elementos de todo o aplicativo em um único local e isso, na linguagem do Angular 2, é um módulo. Assim, este arquivo acessará alguns conceitos do Angular 2 e, em seguida, declarará o módulo de aplicativo e o que ele, por sua vez, utiliza:

import { NgModule }      from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { AppComponent }  from './app.component';
@NgModule({
  imports:      [ BrowserModule ],
  declarations: [ AppComponent ],
  bootstrap:    [ AppComponent ]
})
export class AppModule { }

Por enquanto, isso mais uma vez abrange principalmente todas as declarações de importação: Primeiro, acessando alguns materiais relacionados ao Angular 2 (NgModule e BrowserModule) e, em seguida, a importando um componente de aplicativo, sobre o qual discutirei em um segundo. Observe, no entanto, que NgModule é (como discutido na minha última coluna) um decorador TypeScript. Em suma, é isso que permite ao Angular 2 ter toda a funcionalidade esperada, permitindo que os desenvolvedores usem a estrutura para permanecerem concentrados apenas nos recursos específicos do aplicativo, na classe específica do aplicativo (aqui chamada de AppModule).

É realmente muito importante compreender que o Angular 2 tem uma forte postura em relação à segregação de código e recursos em módulos e componentes. Esse tema será sempre repetido no Angular 2 ao passo que, no Angular 1, foi possível pensar sobre o código sendo organizado mais ou menos de qualquer modo escolhido pelo desenvolvedor (ou, geralmente, quando ele decide não organizar nada). No Angular 2, a biblioteca força os desenvolvedores a lidar com o esquema de organização imediatamente. O Angular 2 permite escolher a granularidade de seus módulos e componentes, no tamanho de sua preferência, mas você deve, mesmo assim, organizá-los em módulos e componentes. Isso é simplesmente "The Angular Way" e você deve seguir o processo.

O decorador do NgModule fornece metadados sobre esse módulo, incluindo de quais outros módulos ele depende, quais declarações ele exporta (o que você verá usado em um segundo) e qual inicialização precisa ser feita. O NgModule tem várias opções que você pode passar aqui e, à medida que um aplicativo Angular 2 for ficando mais complexo, essas listas aumentarão. Marque este arquivo como favorito em algum local, pois você retornará a ele com frequência.

Um Componente de Olá Mundo: App.component.ts

A última parte a ser discutida é o componente de aplicativo real. Ele é o único, até agora, que define a interface do usuário (enfim, toda a linha dele). É o arquivo app.component.ts:

import { Component } from '@angular/core';
@Component({
  selector: 'my-app',
  template: `<h1>Hello {{name}}</h1>`,
})
export class AppComponent  { name = 'Angular'; }

Mais uma vez, o componente depende de um constructo do Angular 2, o decorador Component, portanto, ele importa-o do local apropriado dentro das bibliotecas do Angular. Em seguida, ele declara uma classe exportada, chamada AppComponent, para ser um componente do Angular, com dois parâmetros: um seletor e um modelo. O modelo é simples: Este é o trecho de código HTML aplicado ao local em que este componente é declarado (completo com a associação de interpolação de cadeia de caracteres ECMAScript, neste caso para o parâmetro "name" no HTML). Como esse modelo às vezes pode ficar um pouco grande, ou pelo menos maior do que a única linha de HTML definida aqui, em vez de "template", você também pode usar templateUrl para especificar um arquivo externo no qual o modelo poderá ser encontrado, o que será realizado nas versões posteriores.

O parâmetro selector é um pouco mais sutil. Ele declara o local na interface do usuário onde esse componente deve ser aplicado. Praticamente falando, isso significa que sempre que uma marca my-app aparecer em HTML, esse componente será aplicado. Até agora você não viu marcas <my-app>, mas é simplesmente porque essa marca específica está declarada dentro do arquivo index.html (que ainda não foi discutido):

<!DOCTYPE html>
<html>
  <head>
    <title>Angular QuickStart</title>
    <!-- bunch of other stuff snipped for simplicity -->
  </head>
  <body>
    <my-app>Loading AppComponent content here ...</my-app>
  </body>
</html>

Observe como a marca my-app envolve texto. Principalmente um texto de espaço reservado que pode ou não aparecer, dependendo da rapidez com que o navegador carrega e processa o aplicativo.

Conclusão

Foi muito trabalho para um simples "Olá Mundo". Aparentemente seria muito mais fácil simplesmente escrever o HTML direto e deixar o resto de fora. No entanto, uma grande parte do modo "The Angular Way" consiste em compilar o aplicativo a partir de componentes em vez de apenas usar HTML e CSS e JS em todos os lugares. Além disso, esse tipo de organização e estrutura gera uma sobrecarga com o Angular. Na verdade, praticamente 90 por cento do que discuti até agora é essencialmente sobre a sobrecarga do Angular. À medida que o aplicativo for escalado verticalmente em tamanho, a sobrecarga diminuirá proporcionalmente para que os desenvolvedores de aplicativos se concentrem inteiramente no "cerne" de seu aplicativo. E isso é exatamente o que supostamente uma estrutura de aplicativo deve fazer.

Evidentemente, ainda não terminamos. Há muito mais no Angular 2 para explorar e temos um aplicativo barebones para compilar, para inicializar. Nas próximas colunas, explorarei a criação de componentes, criando especificamente um CRUD básico da lista de alto-falantes (usando um "banco de dados" em memória para iniciar) e mostrarei como o Angular 2 pode manter tudo bem definido e simples. Aguarde. Ainda há muito mais por vir. Até lá, feliz codificação!

---

Ted Neward é um consultor de politecnologia, palestrante e mentor de Seattle. Ele já escreveu mais de 100 artigos, é MVP em F# e é autor e coautor de dezenas de livros. Entre em contato com ele pelo email ted@tedneward.com se desejar que ele venha trabalhar com sua equipe ou leia seu blog em blogs.tedneward.com.

Agradecemos ao seguinte especialista técnico pela revisão deste artigo: Ward Bell