Novidades no Angular V16 🔥

Como parte do lançamento da v16, estamos empolgados em compartilhar uma prévia para desenvolvedores de um novo modelo de reatividade para o Angular, que traz melhorias significativas no desempenho e na experiência do desenvolvedor.

Lembre-se essas informações foram retiradas e traduzidas do blog Angular.

Ele é totalmente compatível com versões anteriores e interoperável com o sistema atual, e possibilita:

Melhor desempenho em tempo de execução, reduzindo o número de cálculos durante a detecção de mudanças. Uma vez que a implementação completa dos Sinais do Angular (Angular Signals) seja concluída, esperamos melhorias significativas na métrica de INP Core Web Vital para aplicativos construídos com sinais. 

Apresenta um modelo mental mais simples para a reatividade, deixando claro quais são as dependências da visualização e como os dados fluem pelo aplicativo. Permite reatividade refinada, o que nas futuras versões nos permitirá verificar as alterações apenas nos componentes afetados. 

Acompanhe o Blog e o meu Curso de Angular

Torna o Zone.js opcional em futuras versões, utilizando sinais para notificar o framework quando o modelo foi alterado. Oferece propriedades calculadas sem a penalidade de recálculo em cada ciclo de detecção de mudanças. 

Permite melhor interoperabilidade com o RxJS, delineando um plano para introduzir entradas reativas. A discussão inicial no GitHub recebeu 682 comentários e, desde então, compartilhamos uma série de RFCs que receberam mais de 1.000 comentários adicionais!

Na v16, você encontrará uma nova biblioteca de sinais que faz parte do @angular/core e um pacote de interoperabilidade com o RxJS – @angular/core/rxjs-interop. A integração completa dos sinais no framework será lançada ainda este ano.

Sinais do Angular (Angular Signals) 

A biblioteca de sinais do Angular permite que você defina valores reativos e expresse dependências entre eles. Você pode aprender mais sobre as propriedades da biblioteca no respectivo RFC. Aqui está um exemplo simples de como usá-la com o Angular:

@Component({
 selector: 'my-app',
 standalone: true,
 template: `
   {{ fullName() }} <button (click)="setName('Dener')">Click</button>
 `,
})
export class App {
 firstName = signal('Nay');
 lastName = signal('Troquatte');
 fullName = computed(() => `${this.firstName()} ${this.lastName()}`);

 constructor() {
   effect(() => console.log('Name changed:', this.fullName()));
 }

 setName(newName: string) {
   this.firstName.set(newName);
 }
}

O trecho acima cria um valor calculado fullName, que depende dos sinais firstName e lastName. Também declaramos um efeito, cujo callback será executado sempre que alterarmos o valor de qualquer um dos sinais que ele lê – neste caso, fullName, o que significa que ele também depende, de forma transitiva, de firstName e lastName.

Quando definimos o valor de firstName como “Dener”, o navegador registrará no console:

“Nome alterado: Dener Troquatte”

Interoperabilidade com o RxJS (RxJS interoperability)

 A partir do lançamento da v16, você poderá “elevar” facilmente sinais para observáveis através das funções do @angular/core/rxjs-interop, que estão disponíveis como prévia para desenvolvedores!

Veja como você pode converter um sinal em um observável:

import { toObservable } from '@angular/core/rxjs-interop';

@Component({...})
export class App {
 count = signal(0);
 count$ = toObservable(this.count);

 ngOnInit() {
   this.count$.subscribe(() => ...);
 }
}

…e aqui está um exemplo de como você pode converter um observável em um sinal para evitar o uso do pipe assíncrono:

import {toSignal} from '@angular/core/rxjs-interop';

@Component({
 template: `
   <li *ngFor="let row of data()"> {{ row }} </li>
 `
})
export class App {
 dataService = inject(DataService);
 data = toSignal(this.dataService.data$, []);
}

Usuários do Angular frequentemente desejam concluir um fluxo quando um assunto relacionado é concluído. O seguinte padrão ilustrativo é bastante comum:

destroyed$ = new ReplaySubject<void>(1);
data$ = http.get('...').pipe(takeUntil(this.destroyed$));

ngOnDestroy() { 
  this.destroyed$.next(); 
}

Estamos introduzindo um novo operador do RxJS chamado takeUntilDestroyed, que simplifica este exemplo para o seguinte:

data$ = http.get('...').pipe(takeUntilDestroyed());

Por padrão, esse operador injetará o contexto de limpeza atual. Por exemplo, quando usado em um componente, ele usará a vida útil do componente.

takeUntilDestroyed é especialmente útil quando você deseja vincular o ciclo de vida de um Observable ao ciclo de vida de um componente específico.

Acompanhe o Blog e o meu Curso de Angular

Próximos passos para os sinais (Next steps for signals)

Em seguida, estaremos focados em componentes baseados em sinais, que terão um conjunto simplificado de ganchos de ciclo de vida e uma forma alternativa e mais simples de declarar entradas e saídas. Também trabalharemos em um conjunto mais completo de exemplos e documentação.

Uma das questões mais populares no repositório do Angular é “Proposta: Entrada como Observável.” Há alguns meses, respondemos que queremos oferecer suporte a esse caso de uso como parte de um esforço maior no framework. Temos o prazer de compartilhar que ainda este ano implementaremos um recurso que permitirá entradas baseadas em sinais – você poderá transformar as entradas em observáveis através do pacote de interoperabilidade!

Renderização e hidratação no lado do servidor (Server-side rendering and hydration)

Com base na nossa pesquisa anual com desenvolvedores, a renderização no lado do servidor é a principal oportunidade de melhoria para o Angular.

Nos últimos meses, nos unimos à equipe do Chrome Aurora para melhorar o desempenho e a experiência do desenvolvedor na hidratação (Hydration) e na renderização no lado do servidor.

Hoje, temos o prazer de compartilhar a prévia para desenvolvedores da hidratação (Hydration) não destrutiva completa de aplicativos!

Na nova hidratação (Hydration) não destrutiva completa de aplicativos, o Angular não renderiza mais a aplicação do zero. Em vez disso, o framework busca nós DOM existentes ao construir estruturas de dados internas e anexa ouvintes de eventos a esses nós.

Os benefícios são:

Ausência de piscamento de conteúdo na página para os usuários finais. Melhores indicadores principais da Web em determinados cenários.

Arquitetura preparada para o futuro que permite o carregamento de código de granularidade refinada com os recursos que serão lançados ainda este ano.

Atualmente, isso é visível na hidratação(Hydration) progressiva de rotas preguiçosas. Integração fácil com aplicativos existentes, com apenas algumas linhas de código (consulte o trecho de código abaixo).

Adoção incremental da hidratação (Hydration) com o atributo ngSkipHydration nos templates de componentes que realizam manipulação manual do DOM. Nos testes iniciais, observamos uma melhoria de até 45% no Largest Contentful Paint com a hidratação (Hydration) completa do aplicativo!

Alguns aplicativos já habilitaram a hidratação (Hydration) em produção e relataram melhorias nos indicadores principais da Web: Para começar, é tão fácil quanto adicionar algumas linhas ao seu main.ts:

import { bootstrapApplication, provideClientHydration, } from '@angular/platform-browser';
...
bootstrapApplication(RootCmp, 
{ 
  providers: [provideClientHydration()] 
});

Você pode encontrar mais detalhes sobre como funciona na documentação.

Novos recursos de renderização no lado do servidor (New server-side rendering features) 

Como parte do lançamento da v16, também atualizamos os esquemas do “ng add” para o Angular Universal, o que permite adicionar a renderização no lado do servidor a projetos usando APIs independentes.

Também introduzimos suporte para uma Política de Segurança de Conteúdo mais restrita para estilos inline.

Acompanhe o Blog e o meu Curso de Angular

Próximos passos da hidratação e renderização no lado do servidor ( Next steps of hydration and server-side rendering )

Há mais coisas que planejamos fazer aqui e o trabalho na v16 é apenas um passo inicial. Em certos casos, existem oportunidades para adiar o carregamento do JavaScript que não é essencial para a página e hidratar os componentes associados posteriormente.

Essa técnica é conhecida como hidratação parcial (partial hydration) e a exploraremos em seguida.

Desde que o Qwik popularizou a ideia de resumibilidade no framework proprietário da Google, Wiz, recebemos muitos pedidos para esse recurso no Angular.

A resumibilidade está definitivamente em nosso radar, e estamos trabalhando em estreita colaboração com a equipe do Wiz para explorar essa área.

Estamos cautelosos em relação às restrições na experiência do desenvolvedor que isso acarreta, avaliando as diferentes compensações e manteremos você informado sobre nosso progresso.

Você pode ler mais sobre nossos planos futuros em “O que vem a seguir para a renderização no lado do servidor no Angular”.

Melhorias nas ferramentas para componentes independentes, diretivas e pipes (Improved tooling for standalone components, directives, and pipes) 

O Angular é um framework usado por milhões de desenvolvedores em muitos aplicativos essenciais, e levamos mudanças importantes a sério.

Começamos a explorar APIs independentes há anos e, em 2022, lançamos-as como prévia para desenvolvedores. Agora, depois de mais de um ano coletando feedback e iterando nas APIs, gostaríamos de incentivar ainda mais a adoção delas!

Para ajudar os desenvolvedores a migrar seus aplicativos para APIs independentes, desenvolvemos esquemas de migração e um guia de migração independente. Uma vez no diretório do seu projeto, execute o seguinte comando:

ng generate @angular/core:standalone

Os esquemas converterão seu código, removerão classes NgModules desnecessárias e, por fim, alterarão a inicialização do projeto para usar APIs independentes.

Coleção standalone ng new (Standalone ng new collection)

Como parte do Angular v16, você pode criar novos projetos como independentes desde o início!

Para experimentar a prévia do desenvolvedor dos esquemas independentes, certifique-se de estar usando o Angular CLI v16 e execute o seguinte comando:

ng new –standalone 

Você terá uma saída de projeto mais simples, sem nenhum NgModules. Além disso, todos os geradores do projeto produzirão diretivas, componentes e pipes independentes!

Configurando o Zone.js (Configure Zone.js)

Após o lançamento inicial das APIs independentes, ouvimos dos desenvolvedores que vocês gostariam de poder configurar o Zone.js com a nova API bootstrapApplication.

Adicionamos uma opção para isso por meio do provideZoneChangeDetection:

bootstrapApplication(App, 
{ 
  providers: [provideZoneChangeDetection({ eventCoalescing: true })]
});

Aprimorando as ferramentas de desenvolvimento (Advancing developer tooling)

Agora, vamos compartilhar alguns destaques de recursos do Angular CLI e do serviço de idioma.

Prévia do desenvolvedor do sistema de construção baseado em esbuild (Developer preview of the esbuild-based build system) 

Há mais de um ano, anunciamos que estamos trabalhando no suporte experimental ao esbuild no Angular CLI para tornar suas compilações mais rápidas. Hoje, estamos animados em compartilhar que, na v16, nosso sistema de construção baseado em esbuild entra em prévia do desenvolvedor! Testes iniciais mostraram mais de 72% de melhoria nas compilações de produção frias.

No ng serve, agora estamos usando o Vite como servidor de desenvolvimento, e o esbuild alimenta tanto suas compilações de desenvolvimento quanto de produção!

Acompanhe o Blog e o meu Curso de Angular

Queremos enfatizar que o Angular CLI depende exclusivamente do Vite como servidor de desenvolvimento. Para suportar a correspondência de seletores, o compilador do Angular precisa manter um grafo de dependências entre seus componentes, o que requer um modelo de compilação diferente do Vite.

Você pode experimentar o Vite + esbuild atualizando o seu angular.json:

... 
"architect": { "build": { /* Adicione o sufixo esbuild */ "builder": "@angular-devkit/build-angular:browser-esbuild",
...

Em seguida, abordaremos o suporte para i18n antes de formarmos este projeto fora da prévia do desenvolvedor.

Melhores testes unitários com Jest e Web Test Runner (Better unit testing with Jest and Web Test Runner) 

Com base em pesquisas de desenvolvedores na comunidade Angular e na comunidade JavaScript em geral, o Jest é um dos frameworks e executores de testes mais amados. Recebemos inúmeros pedidos para suportar o Jest, que possui uma complexidade reduzida, uma vez que nenhum navegador real é necessário.

Hoje, temos o prazer de anunciar que estamos introduzindo o suporte experimental ao Jest. Em uma versão futura, também moveremos projetos existentes do Karma para o Web Test Runner para continuar dando suporte aos testes unitários baseados em navegador. Isso será transparente para a maioria dos desenvolvedores.

Você pode experimentar o Jest em novos projetos instalando o Jest com npm install jest –save-dev e atualizando o seu arquivo angular.json:

{
 "projects": {
   "my-app": {
     "architect": {
       "test": {
         "builder": "@angular-devkit/build-angular:jest",
         "options": {
           "tsConfig": "tsconfig.spec.json",
           "polyfills": ["zone.js", "zone.js/testing"]
         }
       }
     }
   }
 }
}

Você pode aprender mais sobre nossa estratégia futura de testes unitários em postagem recente no blog do Angular.

Auto-completar importações em templates (Autocomplete imports in templates) 

Quantas vezes você usa um componente ou um pipe em um template e recebe um erro do CLI ou do serviço de idioma informando que você não importou a implementação correspondente? Aposto que muitas vezes!

O serviço de idioma agora permite a importação automática de componentes e pipes.

E tem mais! (And there’s more!) 

No v16, também estamos habilitando o suporte ao TypeScript 5.0, com suporte a decoradores ECMAScript, removendo a sobrecarga do ngcc, adicionando suporte a service workers e app shell em aplicativos autônomos, expandindo o suporte a CSP no CLI e muito mais!

Melhorando a Experiência do Desenvolvedor (Improving Developer Experience)

Junto com as grandes iniciativas nas quais estamos focados, também estamos trabalhando para trazer recursos muito solicitados.

Inputs obrigatórios (Required inputs)

Desde que introduzimos o Angular em 2016, não tem sido possível obter um erro de compilação se você não especificar um valor para uma determinada entrada.

A mudança não adiciona nenhuma sobrecarga em tempo de execução, pois o compilador do Angular realiza a verificação em tempo de compilação. Os desenvolvedores pediram por esse recurso ao longo dos anos e recebemos uma forte indicação de que isso será muito útil!

No v16, agora você pode marcar uma entrada como obrigatória:

@Component(...)
export class App {
 @Input({ required: true }) title: string = '';
}

Passando dados do roteador como inputs do componente (Passing router data as component inputs) 

A experiência do desenvolvedor do roteador tem avançado rapidamente. Uma solicitação de recurso popular no GitHub é a capacidade de vincular parâmetros de rota às entradas correspondentes do componente. Ficamos felizes em compartilhar que esse recurso agora está disponível como parte do lançamento v16!

Acompanhe o Blog e o meu Curso de Angular

Agora você pode passar os seguintes dados para as entradas de um componente de roteamento:

Dados da rota – resolvers e propriedades de dados Parâmetros de caminho Parâmetros de consulta Aqui está um exemplo de como você pode acessar os dados de um resolvedor de rota:

const routes = [
 {
   path: 'about',
   loadComponent: import('./about'),
   resolve: { contact: () => getContact() }
 }
];

@Component(...)
export class About {
 // O valor de "contact" é passado para a entrada
 @Input() contact?: string;
}

Você pode habilitar esse recurso usando withComponentInputBinding como parte do provideRouter.

Suporte a CSP para estilos inline (CSP support for inline-styles) 

Os elementos de estilo inline que o Angular inclui no DOM para estilos de componente violam a Política de Segurança de Conteúdo (CSP) padrão para style-src.

Para corrigir isso, eles devem conter um atributo nonce ou o servidor deve incluir um hash do conteúdo do estilo no cabeçalho CSP. Embora no Google não tenhamos encontrado um vetor de ataque significativo para essa vulnerabilidade, muitas empresas impõem CSP estrito, levando à popularidade de uma solicitação de recurso no repositório do Angular.

No Angular v16, implementamos um novo recurso que abrange o framework, Universal, CDK, Material e o CLI, permitindo que você especifique um atributo nonce para os estilos dos componentes que o Angular incorpora. Existem duas maneiras de especificar o nonce: usando o atributo ngCspNonce ou por meio do token de injeção CSP_NONCE.

Acompanhe o Blog e o meu Curso de Angular

O atributo ngCspNonce é útil se você tiver acesso a um sistema de modelagem do lado do servidor que possa adicionar o nonce tanto no cabeçalho quanto no index.html ao construir a resposta.

<html>
<body>
 <app ngCspNonce="{% nonce %}"></app> 
</body>
</html>

A outra maneira de especificar o nonce é por meio do token de injeção CSP_NONCE. Use essa abordagem se você tiver acesso ao nonce em tempo de execução e quiser ser capaz de armazenar em cache o index.html:

import {bootstrapApplication, CSP_NONCE} from '@angular/core';
import {AppComponent} from './app/app.component';

bootstrapApplication(AppComponent, {
 providers: [{
   provide: CSP_NONCE,
   useValue: globalThis.myRandomNonceValue
 }]
});

Flexible ngOnDestroy (Flexible ngOnDestroy)

Os hooks de ciclo de vida do Angular fornecem muita flexibilidade para se conectar a diferentes momentos da execução do seu aplicativo.

Uma oportunidade ao longo dos anos tem sido possibilitar maior flexibilidade, por exemplo, fornecer acesso a OnDestroy como um observável.

No v16, tornamos OnDestroy injetável, o que permite a flexibilidade que os desenvolvedores têm solicitado.

Esse novo recurso permite que você injete DestroyRef correspondente a um componente, diretiva, serviço ou pipe – e registre o gancho de ciclo de vida onDestroy.

O DestroyRef pode ser injetado em qualquer lugar dentro de um contexto de injeção, incluindo fora do seu componente – nesse caso, o gancho onDestroy é executado quando o injetor correspondente é destruído:

import { Injectable, DestroyRef } from '@angular/core';

@Injectable(...)
export class AppService {
 destroyRef = inject(DestroyRef);

 destroy() {
   this.destroyRef.onDestroy(() => /* limpeza */ );
 }
}

Tags de fechamento automático (Self-closing tags)

Um recurso muito solicitado que implementamos recentemente permite que você use tags de fechamento automático para componentes nos templates do Angular. É uma pequena melhoria na experiência do desenvolvedor que pode economizar digitação!

Agora você pode substituir:

<super-duper-long-component-name [prop]="someVar"></super-duper-long-component-name> por isso:
<super-duper-long-component-name [prop]="someVar"/>

Componentes melhores e mais flexíveis (Better and more flexible components)

Nos últimos trimestres, trabalhamos em estreita colaboração com a equipe de Material Design do Google para fornecer a implementação de referência Material 3 para a Web com o Angular Material. Os componentes baseados em MDC Web que lançamos em 2022 estabeleceram a base para esse esforço.

Como próximo passo, estamos trabalhando para lançar ainda este ano uma API de temas baseada em tokens expressivos que permite uma maior personalização dos componentes de material do Angular.

Lembramos que estaremos removendo os componentes legados não baseados em MDC na v17.

Continuando nossa iniciativa de acessibilidade (Continuing our accessibility initiative)

Seguindo a missão do Google, o Angular permite que você crie aplicativos da web para todos! É por isso que estamos continuamente investindo em uma melhor acessibilidade para os componentes do Angular CDK e Material.

Destaques das contribuições da comunidade (Community contribution highlights) 

Dois dos recursos introduzidos pela comunidade que queremos destacar são:

As diagnósticos estendidos para o uso adequado do ngSkipHydration por Matthieu Riegler A introdução do provideServiceWorker para permitir o uso do service worker do Angular sem NgModules por Julien Saguet Mais de 175 pessoas contribuíram para o v16 no GitHub e milhares de outras contribuíram por meio de postagens em blogs, palestras, podcasts, vídeos, comentários nas RFCs de reatividade, etc.

Queremos agradecer a todos que nos ajudaram a tornar este lançamento especial.

Lembre-se essas informações foram retiradas e traduzidas do blog Angular.