Compartilhar via



Agosto de 2017

Volume 32 - Número 8

O programador: Como ser MEAN: Up-Angular-izing

Por Ted Neward | Agosto de 2017

Ted Neward

Bem-vindos de volta, MEANers.

Faz dois anos que eu comecei esta série específica sobre a pilha MEAN (Mongo, Express, Angular, Node). E, tal como era previsto acontecer, várias partes da pilha MEAN evoluíram desde que a série começou. A maioria dessas atualizações (especificamente com as versões do Node, Express e Mongo) são transparentes e adotá-las representa um não evento: Basta atualizar os bits subjacentes para tudo funcionar.

Porém, as atualizações do Angular deixaram o mundo da Web front-end um pouco preocupado por um tempo, especialmente porque as mudanças significativas entre o AngularJS (v1) e o Angular (v2 e posterior) geraram alguns problemas sérios de compatibilidade com versões anteriores. (Eu uso o termo “compatibilidade com versões anteriores” de forma livre neste artigo, pois a história da compatibilidade com versões anteriores da v1 e v2 foi, essencialmente, “Reescreva tudo e confie em nós, será ótimo!”). Por isso, era com alguma tristeza que o mundo do Angular aguardava pela primeira grande atualização, e quando a atualização foi anunciada como uma versão principal de aprimoramento, a ansiedade cresceu.

No fim das contas, enquanto estávamos ocupados escrevendo o front-end do aplicativo de exemplo, a equipe do Angular fez aquilo que deveria e lançou uma nova versão do Angular. Isso significa que chegou a hora de reservar um momento e fazer o sacrifício de atualizar o aplicativo para a nova versão do Angular: v4. (A equipe do Angular decidiu pular a versão 3 e passar diretamente para a 4.) Alerta de spoiler: A atualização acabou provando ser muito menos complicada do que as pessoas imaginavam e dá muita esperança em relação ao futuro das atualizações do Angular, o que é positivo, pois a equipe do Angular prometeu que vai lançar cadência de forma muito mais alinhada com os projetos de código-fonte aberto tradicionais. O que significa, francamente, muitas atualizações incrementais pequenas lançadas muito mais rapidamente (a cada 6 meses) do que a norma até o momento.

Atualização do Angular

Fundamentalmente, a atualização para o Angular 4 significa usar o pacote do Node Package Manager (npm) para atualizar os pacotes npm usados nas versões mais recentes. Isso adota a forma do famoso comando “inpm install”, usando a marca de versão (“@latest”) para cada pacote e o argumento “--save” para capturar a versão mais recente no pacote do arquivo .json do aplicativo. Para os que executam em um sistema *nix (normalmente Linux ou macOS), o comando assume a seguinte forma, devendo ser tudo digitado em uma linha:

npm install @angular/{common,compiler,compiler-cli,core,forms,http,platform-browser,platform-browser-dynamic,platform-server,router,animations}@latest typescript@latest --save

Os shells do comando *nix permitem que vários pacotes sejam capturados em pares “{“/”}”, apesar de cada um deles ser nomeado “@angular/common,” “@angular/compiler” e assim por diante. Para os que usam o Windows, a versão é um ligeiramente maior:

npm install @angular/common@latest @angular/compiler@latest @angular/compiler-cli@latest @angular/core@latest @angular/forms@latest @angular/http@latest @angular/platform-browser@latest @angular/platform-browser-dynamic@latest @angular/platform-server@latest @angular/router@latest @angular/animations@latest typescript@latest --save

Quando a “npm install” terminar de executar, a atualização está concluída para todos os fins. Basta executar o aplicativo usando “ng serve” novamente e tudo deve voltar ao status de execução.

2 a 4 pontos problemáticos do Angular

A equipe do Angular admitiu que a transição nem sempre é tranquila, no entanto, as notas de versão têm o cuidado de destacar que a maioria dos problemas (aparentemente) está localizada para o uso de animações, um tema que eu ainda não explorei. Especificamente, a equipe removeu animações de @angular/core e colocou-as em seu próprio pacote Node, @angular/animations (que você pode ser no comando “npm install” anterior). Assim, se o aplicativo não usar animações, ele não tem que transportar o código de animações no pacote do núcleo.

Novos recursos do Angular 4

As notas de versão do Angular 4 carregam todo o peso da história, mas há algumas coisas específicas que vale a pena chamar.

Primeiro, a equipe do Angular está empenhada em reduzir o tamanho/peso de superfície das bibliotecas do Angular. Isso é bom por motivos óbvios, especialmente para aqueles usuários que não possuem conexão de fibra óptica de alta velocidade com o resto do mundo. A equipe do Angular diz que ainda não está pronta, por isso, é provável que cada nova versão do Angular procure diminuir sua superfície ainda mais.

Neste mesmo contexto, a equipe do Angular reduziu o tamanho geral dos modelos de exibição code-behind gerados em até 60%. Novamente, isto significa que o aplicativo que você criar será muito menor e mais leve.

Em seguida, a equipe aprimorou as diretivas “*ngIf” e “*ngFor” usadas nos modelos de exibição para cenários de branch e iteração, respectivamente. Você ainda não viu essas diretivas, por isso, os novos recursos ainda não estarão visíveis, mas aguente firme que eles estarão em breve.

Por fim, a equipe do Angular também trouxe as bibliotecas do Angular até as últimas versões do TypeScript (2.2), que inclui melhor verificação de valores anuláveis, suporte de tipo um pouco melhor para misturas de estilo do ECMAScript (ES) 2015 e um tipo de “objeto” para representar um tipo que é o tipo base de todos os tipos declarados no TypeScript, parecidos com a função que o System.Object serve na maior parte do código .NET. Isto também traz, implicitamente, suporte para o TypeScript 2.1, que por si só conta com alguns recursos interessantes, como o operador “keyof”, tipos mapeados (que fornecem os tipos utilitários Partial, Readonly, Pick e Record), e suporte para os operadores “spread” e “rest” do ES 2015. Tudo isso vai muito além do escopo do próprio Angular, mas qualquer tutorial do TypeScript de boa qualidade (ou o próprio site do TypeScript) explicará o seu uso. Sobretudo, eles não mudarão o código que você escreve no angular, pelo menos não imediatamente, mas conforme esses recursos vão sendo mais usados na biblioteca do Angular, eles podem começar a encontrar seu caminho na área de superfície da API do Angular. Provavelmente, isso não acontecerá por um tempo, porém, no momento, o mais importante a ter em mente é o fato de o Angular estar acompanhando a evolução do TypeScript.

Conclusão

Espero que eu tenha ajudado você a entender que fazer esta atualização não custa praticamente nada e é o melhor tipo de atualização de versão. Mais importante, é animador saber que como os aplicativos do Angular crescem e se expandem, o trabalho necessário para mantê-los atualizados com as versões mais recentes do Angular é (por enquanto, pelo menos) algo simples.

Como usar o MEAN: Passados dois anos

Ao trabalhar nesta coluna, o redator-chefe da MSDN Magazine, Michael Desmond, ressaltou que a série Como ser MEAN estava fazendo dois anos nesta edição. Como pode eu ainda estar trabalhando nas minas MEAN? Uma parte disto tem a ver com o fato de que esta série está lidando com um assunto bastante grande — uma plataforma baseada em middleware API REST, de armazenamento completo front-end para dados, do início ao fim, em vez de apenas uma biblioteca ou estrutura. Porém, um pouco disto tem a ver com a própria natureza da pilha MEAN.

A plataforma MEAN é diferente da plataforma .NET Framework, mas não em termos do que fornece, pois as duas têm linguagem de programação, uma estrutura/biblioteca HTTP para receber dados JSON enviados, drivers para acessar bancos de dados e assim por diante. Ela é diferente justamente naquilo que não fornece. Ou seja, a plataforma MEAN, construída por cima da plataforma Node.js enfatiza uma sensação de “minimalismo”, ao contrário da plataforma .NET.

Isso pode parecer que estou desmerecendo uma ou outra plataforma, dizendo que o Node.js ainda não está totalmente pronto ou que o .NET é pesado demais. Porém, não é minha intenção julgar. Enquanto o .NET surgiu na Microsoft e continua a ser extremamente direcionado em função do que a equipe do .NET Framework vem criando ao longo dos anos, a plataforma Node.js foi unida por bibliotecas criadas por centenas de equipes e milhares de desenvolvedores em todo o mundo. Há prós e contras em cada abordagem, mas não é meu objetivo falar sobre isto.

O fato é que ambas as plataformas estão disponíveis para você, a seu critério. E mesmo há apenas dois anos, a ideia de a Microsoft ser uma plataforma pela qual os desenvolvedores pudessem usar o .NET ou o Node.js (ou mesmo Java ou PHP) para criar aplicativos no ou próximos do sistema operacional da Microsoft (ou plataforma de nuvem) parecia absurda. Havia sinais que sugeriam que a Microsoft pudesse alcançar este tipo de mentalidade de que “todas as plataformas são criadas iguais”, mas o histórico da empresa já sugeria que pudéssemos ver uma abordagem na qual o .NET seria a primeira entre essas plataformas iguais.

Considere o seguinte por um momento: A letra “A” na pilha MEAN representa o Angular. Quando eu comecei esta série, o Angular não era a plataforma de aplicativos de página única (SPA) poderosa e avançada de cliente que é atualmente — ela era apenas uma das várias apostas possíveis de ser feita no panorama front-end do JavaScript. O interesse pelo Angular definitivamente aumentou, e as páginas desta revista foram decoradas com várias referências ao Angular, tanto dentro dos limites desta coluna quanto em artigos de destaque escritos por outras pessoas.

O que é impressionante é que esse interesse está em uma tecnologia front-end escrita no mundo do código-fonte aberto por uma equipe que não só não trabalha para a Microsoft, como também para uma das concorrentes da Microsoft. Ainda assim, ela usa a linguagem de código-fonte aberto desenvolvida pela Microsoft. Isso é o suficiente para deixar sua cabeça a mil por hora.

A pilha MEAN e a cobertura do MEAN nesta revista articula de muitas maneiras tudo sobre o que “há de novo na Microsoft”. Isso é uma demonstração excelente de como a Microsoft de 2017 está tão diferente da Microsoft de 2007 ou 2000. A Microsoft que valorizava competição em vez de cooperação e senso de comunidade já não existe mais. A empresa que vemos hoje certamente compete com outras empresas, mas não com sua comunidade. A Microsoft de 2017 quer que você use a pilha de tecnologia de sua preferência, idealmente dentro de sua nuvem ou em seu sistema operacional, mas se você tiver uma opção diferente desta, bem, fica a seu critério.

Ao fim do dia, a pilha MEAN é “apenas” uma pilha composta de três partes (MongoDB, Angular e Node.js/Express) que podem interoperar umas com as outras. E o fato de a Microsoft não abranger somente isso, mas também incentivar este tipo de situação, mostra o quanto as coisas evoluíram desde então.

Faz pensar no que os próximos anos nos reservam, não é mesmo? Boa codificação.


Ted Neward é consultor, palestrante e mentor em politecnologia baseado em Seattle e atualmente trabalha como diretor de relações com desenvolvedores na Smartsheet.com. Ele já escreveu mais de 100 artigos, é autor e coautor de dezenas de livros e colabora em todo o mundo. Entre em contato com ele em ted@tedneward.com ou leia seu blog em blogs.tedneward.com.


Discuta esse artigo no fórum do MSDN Magazine