DEV Community: Erick Gabriel dos Santos Alves

Angular 22: O Framework finalmente encontrou sua identidade?

Erick Gabriel dos Santos Alves — Fri, 12 Jun 2026 17:38:45 +0000

Fala, comunidade dev! 👋

Durante anos, uma crítica acompanhou o Angular em praticamente toda discussão sobre Front-end:

"O Angular é poderoso, mas complexo."

E, para ser justo, essa crítica tinha fundamento.
NgModules, Zone.js, Change Detection global, decorators em excesso, Reactive Forms verbosos e uma curva de aprendizado considerável fizeram muita gente migrar para alternativas consideradas mais simples.

Mas algo interessante aconteceu entre o Angular 16 e o Angular 22.

Pela primeira vez desde o lançamento do Ivy, não parece que estamos vendo apenas uma sequência de novas funcionalidades. Estamos vendo uma direção arquitetural clara.

O Angular 22 não é importante por causa de uma única feature. Ele é importante porque consolida uma transformação iniciada anos atrás: Angular agora é oficialmente um framework Signal-First.

O Angular de 2026 é muito diferente do Angular de 2020

Se você ficou alguns anos longe do framework, provavelmente lembrará de algo assim:

AppModule
SharedModule
Guards em Classes
Change Detection padrão
Zone.js
Reactive Forms
Webpack
RxJS para praticamente tudo

Hoje um projeto Angular moderno nasce com:

Standalone Components
Functional Guards
inject()
Signals
Signal Forms
Resource API
OnPush por padrão
Hydration
Esbuild + Vite
SSR de primeira classe

A quantidade de conceitos obrigatórios diminuiu drasticamente. E talvez essa seja a maior evolução do framework.

1. OnPush finalmente virou o padrão

Durante anos praticamente todo desenvolvedor Angular experiente fazia isso:

@Component({
  selector: 'app-dashboard',
  templateUrl: './dashboard.component.html',
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class DashboardComponent {}

Por quê? Porque o comportamento padrão verificava componentes demais.
Agora o Angular oficializou essa prática. Você não precisa mais adicionar OnPush manualmente em cada componente.

Parece uma mudança pequena. Não é. Ela mostra que o framework assumiu definitivamente uma arquitetura baseada em reatividade explícita.

Menos verificações globais.
Menos trabalho para CPU.
Mais previsibilidade.
Mais performance.

2. Signals deixaram de ser novidade e viraram fundação

Quando Signals apareceram no Angular 16, muita gente tratou como uma funcionalidade interessante. No Angular 22 eles já fazem parte da identidade do framework.

Antes:

export class CounterComponent {
  count = 0;

  increment() {
    this.count++;
  }
}

Agora:

import { signal } from '@angular/core';

export class CounterComponent {
  count = signal(0);

  increment() {
    this.count.update(value => value + 1);
  }
}

Template:

<button (click)="increment()">
  {{ count() }}
</button>

A principal diferença é que o Angular sabe exatamente quem depende daquele estado. Nada de verificações desnecessárias.

3. Computed Signals: reatividade sem esforço

Uma das APIs mais elegantes introduzidas pelo framework.

import { signal, computed } from '@angular/core';

export class PedidoComponent {
  itens = signal([
    { valor: 100 },
    { valor: 200 }
  ]);

  total = computed(() =>
    this.itens().reduce(
      (acc, item) => acc + item.valor,
      0
    )
  );
}

Template:

Total: {{ total() }}

Sempre que a lista mudar, o total será recalculado automaticamente.

Sem subscriptions.
Sem Subjects.
Sem RxJS.
Sem código extra.

4. Signal Forms finalmente ficaram prontos para produção

Quando os Signals foram lançados, a pergunta era inevitável: "Mas e os formulários?"

A resposta demorou alguns releases. Agora chegou. Signal Forms se tornaram uma alternativa moderna aos tradicionais Reactive Forms.

Reactive Forms:

form = new FormGroup({
  nome: new FormControl(''),
  email: new FormControl('')
});

Abordagem baseada em Signals:

import { signal } from '@angular/core';

export class UsuarioComponent {
  form = signal({
    nome: '',
    email: ''
  });

  atualizarNome(nome: string) {
    this.form.update(v => ({
      ...v,
      nome
    }));
  }
}

Os formulários ficam mais próximos da arquitetura reativa moderna do framework.

Menos boilerplate.
Mais previsibilidade.
Melhor tipagem.

5. Resource API: a evolução mais subestimada do Angular

Essa talvez seja a feature mais importante que pouca gente está comentando.
Historicamente tínhamos duas opções: Observable ou Promise.
Agora temos Resources.

Exemplo simplificado:

import { resource } from '@angular/core';

usuarios = resource({
  loader: () =>
    fetch('/api/users')
      .then(r => r.json())
});

Template:

@if (usuarios.isLoading()) {
  <p>Carregando...</p>
}

@if (usuarios.hasValue()) {
  <app-user-list
    [users]="usuarios.value()">
  </app-user-list>
}

A Resource encapsula: Dados, Loading, Error, Reload e Cancelamento. Tudo integrado com Signals. Não substitui RxJS, mas elimina uma enorme quantidade de código para casos simples.

6. `inject()` mudou a forma de escrever Angular

Durante anos escrevemos isso:

constructor(
  private http: HttpClient,
  private router: Router
) {}

Agora:

private http = inject(HttpClient);
private router = inject(Router);

Ou dentro de uma Functional Guard:

export const authGuard: CanActivateFn = () => {
  const auth = inject(AuthService);
  return auth.isLoggedIn();
};

A API ficou mais limpa, mais funcional e mais fácil de compor.

7. O Angular está cada vez mais Zone-less

Se existe uma palavra que define a evolução recente do Angular, ela é: Controle.

Durante anos o framework monitorava tudo através do Zone.js. Hoje temos:

Signals
OnPush
Resources
Renderização mais previsível

Tudo aponta para a mesma direção: Menos mágica. Mais controle. Mais performance. O Angular ainda suporta Zone.js. Mas é evidente que o futuro não gira mais em torno dele.

8. SSR e Hydration estão amadurecendo rapidamente

Durante muito tempo SSR parecia uma funcionalidade opcional. Hoje não.

Configuração básica:

bootstrapApplication(
  AppComponent,
  {
    providers: [
      provideClientHydration()
    ]
  }
);

O Angular reutiliza o HTML renderizado pelo servidor em vez de reconstruir toda a tela.
Benefícios:

Melhor SEO
Melhor LCP
Melhor experiência mobile
Menos JavaScript executado

9. O HTTP Client também evoluiu

Outra mudança pouco comentada. Agora é possível utilizar Fetch como backend principal:

bootstrapApplication(
  AppComponent,
  {
    providers: [
      provideHttpClient(
        withFetch()
      )
    ]
  }
);

Isso aproxima o Angular dos padrões modernos da Web. Menos dependências legadas. Mais alinhamento com o ecossistema JavaScript.

10. Angular e IA: o início de uma nova fase

O time do Angular está investindo cada vez mais em integração com ferramentas de IA. Estamos vendo iniciativas envolvendo:

WebMCP
Agent Skills
Ferramentas para assistentes inteligentes
Melhor suporte a automação

Ainda é cedo para saber o impacto real. Mas o sinal é claro: O Angular quer ser um framework preparado para um futuro onde IA participa ativamente do desenvolvimento.

O que esperar do Angular 23, 24 e além?

Se eu tivesse que apostar no futuro do framework, apostaria em cinco movimentos:

Menos RxJS obrigatório: RxJS continuará relevante, mas cada vez mais opcional.
Mais APIs baseadas em Signals: Signals se tornaram o centro da arquitetura. Tudo novo gira em torno deles.
Zone.js cada vez menos relevante: A direção do framework é clara.
Build ainda mais rápido: Esbuild e Vite foram apenas o começo.
IA integrada ao fluxo de desenvolvimento: O Angular já começou a investir nessa direção.

Conclusão

Angular 22 não impressiona por uma única funcionalidade. Ele impressiona porque fecha vários ciclos iniciados anos atrás.

Signals amadureceram. Signal Forms amadureceram. Resources amadureceram. OnPush virou padrão. SSR evoluiu. O ecossistema de build ficou absurdamente rápido. O framework ficou mais previsível, mais performático e mais alinhado com a Web moderna.

Depois de acompanhar a evolução do Angular desde a era dos NgModules gigantes e do Webpack dominando tudo, talvez a melhor definição seja esta:

O Angular finalmente parece um framework que sabe exatamente para onde está indo. E isso é algo que não acontecia há bastante tempo.

E você? Qual foi a mudança mais importante do Angular nos últimos anos? Deixe nos comentários! 👇

Desconstruindo o Build: A Revolução do Angular (E a diferença entre Compilador e Bundler)

Erick Gabriel dos Santos Alves — Thu, 04 Jun 2026 01:40:40 +0000

Fala, comunidade dev! 👋

Na nossa jornada de migração do YMS (do Angular 16 para o 21), mencionei no primeiro artigo que o tempo de compilação e o hot reload despencaram. A experiência de desenvolvimento foi para outro patamar. Mas por que isso aconteceu?

Muitos desenvolvedores acreditam que o Angular "trocou de compilador" nas versões recentes. Mas isso é um mito. Para entender o que realmente deixou o framework tão rápido, precisamos separar duas ferramentas fundamentais que rodam no seu terminal: o Compilador e o Bundler (Empacotador).

1. Desfazendo a confusão: Compilador vs. Bundler

A. O Compilador (Ivy)
O compilador é o tradutor. O navegador não entende TypeScript, nem entende os decorators do Angular (@Component, @Injectable) ou a sintaxe de template do HTML (@if, {{ variavel }}).

O papel do compilador do Angular (chamado de Ivy) é ler esse código e transformá-lo em instruções JavaScript puras.

A grande sacada aqui é: O compilador não mudou. O Angular usa o Ivy desde a versão 9. Tanto o nosso projeto legado no Angular 16 quanto a versão nova no Angular 21 rodam o mesmíssimo compilador por baixo dos panos.

B. O Bundler (O Empacotador)
O Bundler é o gerente de logística. Depois que o Ivy traduz os arquivos, você fica com milhares de pequenos arquivos JS espalhados. O Bundler pega tudo isso, resolve as dependências (quem importa quem), aplica o Tree-Shaking (que explicamos no artigo anterior), minifica o código e empacota tudo em um ou mais arquivos finais para o navegador baixar.

E é aqui que a mágica da nossa migração aconteceu: nós trocamos o gerente de logística.

2. O Passado: A Era do Webpack

No Angular 16, o padrão absoluto para empacotar a aplicação era o Webpack.

O Webpack é uma ferramenta fantástica, mas tem um problema de arquitetura para o modo de desenvolvimento: ele precisa construir a aplicação inteira antes de poder servi-la.

Em um sistema corporativo pesado como o nosso YMS (cheio de telas, regras logísticas e componentes densos do PrimeNG), o Webpack precisava rastrear milhares de arquivos, compilar tudo, empacotar em memória e só então liberar a tela no localhost. Qualquer mudança num CSS fazia o Webpack recalcular uma parte gigantesca desse pacote. O resultado? Segundos (ou até minutos) olhando para o terminal esperando o reload.

3. O Presente: A Revolução do Esbuild + Vite

A partir das versões mais recentes (consolidado como padrão no 17+), o Angular chutou o Webpack e reescreveu todo o seu pipeline de build utilizando duas ferramentas absurdamente rápidas: o Esbuild e o Vite.

Esbuild: É um bundler escrito em Go (uma linguagem compilada e de altíssima performance). Ao contrário do Webpack (escrito em JavaScript), o Esbuild paraleliza o trabalho usando todos os núcleos do seu processador. Ele constrói dependências pesadas (como o PrimeNG ou o RxJS) em milissegundos.
Vite: Essa é a estrela do modo de desenvolvimento (ng serve). O Vite inverte a lógica do Webpack. Ele não constrói a aplicação inteira antes de iniciar. Ele inicia o servidor instantaneamente e deixa o navegador pedir os arquivos sob demanda (usando Native ES Modules). Se você está na tela de "Login", o Vite só pede para o Angular compilar e entregar os arquivos do Login. O resto do YMS fica ignorado até você navegar para lá.

4. O Impacto na Prática

Essa mudança do Webpack para o Esbuild/Vite mudou a nossa vida no projeto. O Hot Module Replacement (HMR) agora é instantâneo. Você altera a cor de um botão no arquivo SCSS, e a tela pisca e atualiza em frações de segundo, sem perder o estado da página.

Nós não escrevemos código mais rápido, mas paramos de esperar a máquina trabalhar. O ciclo de feedback rápido destrava a produtividade de qualquer equipe de Front-end.

Conclusão

O Angular 21 não é mais rápido porque tem um novo compilador, mas sim porque o ecossistema de build ao redor dele evoluiu para ferramentas de próxima geração.

Se você ainda está preso em versões antigas do Angular, atualize. Nem que seja apenas para sentir o prazer de um ng serve que inicia em menos de 2 segundos.

Você já notou essa diferença de tempo de build nos seus projetos atualizados? Quanto tempo demorava o seu ng serve mais lento na época do Webpack? Deixa aí nos comentários! 👇

Desconstruindo o Build: Como o Tree-Shaking realmente funciona (e por que o Bundle importa)

Erick Gabriel dos Santos Alves — Thu, 04 Jun 2026 01:40:38 +0000

Fala, comunidade dev! 👋

No primeiro artigo da nossa série sobre a migração do YMS (do Angular 16 para o 21), mencionei que uma das maiores vitórias de abandonar o app.module.ts e adotar os Standalone Components foi a melhora drástica no Tree-Shaking.

Teoria é legal, mas na nossa área o que manda são os números. Durante essa refatoração estrutural, matando Módulos, limpando arquivos sem uso e ajustando lógicas legadas, nós conseguimos reduzir o tamanho da nossa pasta de build de assustadores 40MB para cerca de 15MB. Uma redução de mais de 60% no "peso" do sistema!

Como nós, desenvolvedores, adoramos entender como as engrenagens rodam por baixo dos panos, decidi fazer esta pausa na série principal para desconstruir esse processo. Como exatamente o framework conseguiu arrancar 25MB de "gordura" do nosso projeto?

A resposta atende por dois nomes: o novo bundler (Esbuild/Vite) e um Tree-Shaking finalmente eficiente. Mas antes de balançarmos a árvore, precisamos entender exatamente o que é o "cesto de frutas" que estamos enviando para o navegador do nosso usuário.

1. Mas primeiro: O que é esse tal de "Bundle"?

O Bundle (ou empacotamento) é o resultado final do processo de build do Angular.

Quando você escreve o código do seu YMS, você cria centenas (ou milhares, num projeto de 5 anos!) de arquivos TypeScript, HTML e CSS. Mas o navegador do seu usuário não entende TypeScript e nem sabe como carregar essa estrutura complexa de pastas.

O papel do Bundler é ler todo esse código, processá-lo, compilá-lo para JavaScript nativo e juntar tudo em apenas um (ou alguns poucos) arquivos. É esse pacote único que o navegador baixa e executa para rodar o seu sistema.

2. Qual o impacto prático do Bundle?

O tamanho do Bundle tem um impacto direto e brutal tanto na Developer Experience (DX) quanto na User Experience (UX):

Velocidade do Build: Durante o desenvolvimento, um bundle menor significa que o hot reload (ver a alteração na tela ao salvar o arquivo) é quase instantâneo, o que melhora muito a nossa produtividade.
Tempo de Carregamento Inicial: Para o usuário, um bundle menor significa um download mais rápido. Se o seu YMS tem um pacote de dezenas de megabytes, o usuário vai ficar olhando para uma tela branca por muito tempo, especialmente em redes móveis ou conexões instáveis de armazéns logísticos.
Tempo de Análise e Execução: O navegador não apenas baixa o arquivo; ele precisa interpretar e executar todo o JavaScript. Um arquivo maior consome mais CPU e tempo, o que pode travar a interface e gerar uma experiência péssima.

Resumo da ópera: O bundle é o arquivo final que roda o seu sistema, e o tamanho dele dita a velocidade da aplicação. Otimizá-lo é uma prioridade absoluta em sistemas Enterprise.

3. A Analogia da Árvore: Entendendo o Tree-Shaking

Imagine que o seu projeto é uma árvore frutífera. O tronco é o seu main.ts e os galhos são os seus componentes, serviços e bibliotecas externas (como o PrimeNG ou o RxJS). As folhas são as funções e métodos escritos no código.

Quando chega a hora de enviar esse projeto para produção (o momento do build), o seu Bundler balança essa árvore com força. O objetivo? Fazer com que todas as folhas mortas (código que você escreveu ou importou da biblioteca, mas nunca usou de fato na tela) caiam no chão e não sejam enviadas para o pacote final do usuário.

Isso é o Tree-Shaking: a eliminação de código morto (dead-code elimination).

Como o Bundler sabe o que é código morto?
O Tree-Shaking só é possível graças à estrutura estática dos módulos do JavaScript moderno (a famosa sintaxe de import e export). Como essa sintaxe não pode ser condicional (você não pode colocar um import dentro de um if), o bundler consegue ler todos os seus arquivos antes de executá-los e montar um Grafo de Dependências perfeito (um mapa exato de quem chama quem).

Se você importa uma biblioteca inteira de utilitários, mas só usa a função ordenar(), o bundler rastreia isso. As outras 50 funções da biblioteca são marcadas como "código morto" e podadas da árvore.

4. O Problema: Por que o NgModule era o inimigo do Tree-Shaking?

Aqui entra o pulo do gato e o motivo pelo qual nosso build antigo batia a assustadora casa dos 40MB.

Os Módulos do Angular agrupavam as coisas. Pense no famoso SharedModule. Nós costumávamos colocar absolutamente tudo lá dentro: botões, diretivas, pipes de formatação de data, dezenas de componentes de modal do PrimeNG, etc.

Quando você importava o SharedModule no seu DashboardModule, o bundler olhava para aquilo e pensava: "Opa, ele importou o módulo inteiro. Como o Angular injeta isso de forma dinâmica em tempo de execução, eu não tenho certeza de quais partes desse SharedModule o Dashboard realmente vai usar. Na dúvida, vou empacotar TUDO para não quebrar a aplicação em produção."

O resultado? Se o seu Dashboard precisasse de apenas um botão, ele acabava carregando o peso de todos os modais, tabelas e pipes de outras partes do sistema. A árvore não balançava direito. Estávamos enviando código morto para o navegador o tempo todo.

5. A Solução: A Transparência dos Standalone Components

É por isso que os componentes Standalone são uma revolução de performance, e não apenas de sintaxe. Ao remover o Módulo genérico da jogada, o contrato de dependência fica explícito diretamente no componente:

@Component({
  selector: 'app-dashboard',
  standalone: true,
  // O bundler vê EXATAMENTE o que está sendo usado
  imports: [ButtonModule, DatePipe], 
  template: `<button>Clique aqui: {{ dataAtual | date }}</button>`
})
export class DashboardComponent { ... }

Agora, o bundler consegue montar um mapa preciso. Ele sabe que o DashboardComponent só usa o botão e o pipe de data. Todo o resto do PrimeNG ou de componentes compartilhados que não estão nesse array de imports é sumariamente descartado no processo de build. A tesoura finalmente funciona!

Conclusão

Migrar um projeto maduro e complexo como o nosso YMS para componentes Standalone dá um trabalho considerável, mas o pagamento vem na balança: 25MB a menos.

O JavaScript que o navegador do usuário baixa fica estritamente limitado ao que a tela atual precisa. Menos código = carregamento mais rápido = operadores logísticos muito mais felizes.

E você, já chegou a analisar o tamanho do bundle do seu projeto com ferramentas como o source-map-explorer antes e depois do Standalone? Compartilha os resultados aí nos comentários! 👇

Desconstruindo o Build: Chunks, Raio-X e a Anatomia do Navegador

Erick Gabriel dos Santos Alves — Thu, 04 Jun 2026 01:40:36 +0000

Fala, comunidade dev! 👋

No nosso último artigo sobre a desconstrução do build, mostrei como reduzimos o pacote do nosso YMS de 40MB para 15MB através de Standalone Components e Tree-Shaking. Mas, como bons engenheiros, não paramos por aí. 15MB ainda é muita coisa.

Sempre que rodamos o comando ng build, o terminal nos joga uma sopa de letrinhas com centenas de arquivos (chunks) e tamanhos variados. Mas o que exatamente o Angular está gerando? Como o navegador "mastiga" essa pasta de build? E, mais importante, como descobrimos o que está escondido dentro desses megabytes?

Hoje, vamos abrir a caixa preta da compilação, entender a matemática da performance e fazer um Raio-X da nossa aplicação.

1. Como o navegador entende a sua pasta de Build?

Quando você programa em Angular, você escreve TypeScript, usa SCSS e cria templates dinâmicos. Mas o navegador (Chrome, Edge, Safari) é "burro" para isso. Ele só entende o tripé sagrado da web: HTML, CSS e JavaScript puro.

O papel do seu Bundler (no Angular 21, o Esbuild) é traduzir a sua engenharia complexa para esse formato básico. O resultado cai na pasta dist/. Mas como o navegador lê isso?

A Porta de Entrada: O navegador baixa o index.html. Ele é um arquivo minúsculo que não tem quase nada na tela, mas contém as tags <link> para o seu CSS e <script> para o seu JavaScript.
O Download e o Bloqueio: O navegador começa a baixar o seu arquivo principal (main.js). É aqui que a mágica (ou a tragédia) acontece. Diferente de uma imagem de 2MB que apenas aparece na tela, um arquivo JavaScript de 2MB precisa ser Baixado, Interpretado (Parsed), Compilado e Executado pela Main Thread (a linha de execução principal) do navegador.

A Tela Branca: Enquanto o navegador está executando esse JavaScript pesado, ele "trava". Nenhuma interface é desenhada e nenhum clique funciona. É o famoso gargalo de TTI (Time to Interactive). É por isso que arquivos grandes são mortais. O peso do JS custa caro na rede (download) e caríssimo na CPU do celular ou do computador do usuário (execução).

2. Lendo o Terminal: O que são os "Chunks"?

Sabendo que arquivos gigantes travam o navegador, o Angular usa a tática de "dividir para conquistar". Quando rodamos o build do nosso YMS, recebemos o seguinte log:

Initial chunk files                 | Names       | Raw size
styles.css                          | styles      | 1.10 MB 
main.js                             | main        | 19.33 kB 
chunk-DXO7V6OT.js                   | -           | 26.94 kB 
                                    | Initial total | 1.18 MB

Lazy chunk files                    | Names                       | Raw size
chunk-QPFHIJ3Z.js                   | -                           | 513.35 kB 
editar.component-US2MQII7.js        | editar-component            | 342.09 kB 
painel.component-CX2TJGIN.js        | painel-component            | 281.48 kB 
...and 390 more lazy chunks files. Use "--verbose" to show all the files.

Para um desenvolvedor desavisado, ver "390 arquivos" gerados pode parecer um erro. Na verdade, é a prova de uma arquitetura de sucesso.

O que é um Chunk? É um fragmento isolado do seu sistema. O código alfanumérico no nome (DXO7V6OT) serve para o Cache Busting: se você alterar apenas esse arquivo no futuro, o nome muda, forçando o navegador a baixar a nova versão e reaproveitar o resto que está intocado no cache.

Initial Chunk Files (O Kit de Sobrevivência): Essa é a métrica mais importante do seu Front-end. O nosso Initial total deu 1.18 MB. Esse é o pacote absoluto que o navegador precisa baixar e executar para exibir a primeira tela (como o Login). Manter isso baixo é o que garante que o usuário não fique olhando para uma tela branca.
Lazy Chunk Files (A Sobremesa sob Demanda): O Angular pegou nossa tela gigantesca de painel.component, isolou as dependências dela e gerou um arquivo separado de 281 kB. O navegador nunca fará o download desses 281 kB a menos que o usuário clique no botão para acessar o painel. Dividimos 15MB em fatias cirúrgicas de carregamento!

3. Qual é o "Tamanho Ideal" e os Performance Budgets?

Com base em tudo isso, definimos limites estritos (Performance Budgets). No Angular, você pode configurar isso no angular.json para que o build "quebre" (falhe no CI/CD) se você passar do limite.

O nosso alvo corporativo:

O Initial Bundle deve ficar abaixo de 2MB (descompactado). Isso garante que, mesmo em um armazém logístico com internet 3G oscilante, a tela de login apareça em menos de 3 segundos.
Os Lazy Chunks devem ter no máximo 500KB. Se um componente Lazy passa disso, significa que a tela está fazendo coisas demais e precisa ser quebrada em sub-rotas ou blocos @defer no HTML.

4. O Raio-X do Bundle: Achando a "Gordura"

Tínhamos os limites definidos, tínhamos 15MB totais divididos em 390 chunks, mas queríamos saber: o que exatamente tem dentro desses chunks mais pesados?

Na era do Angular 16 (Webpack), usávamos a biblioteca source-map-explorer. Mas com o Esbuild (Angular 17+), a compilação é tão agressiva que as ferramentas antigas quebram.

A solução oficial agora é gerar o relatório nativo do compilador:

ng build --configuration production --stats-json

Depois, basta jogar esse arquivo stats.json no site oficial do Esbuild Bundle Analyzer (esbuild.github.io/analyze). O resultado é um mapa visual interativo que mostra cada byte do sistema. Ao rodar essa auditoria no YMS, encontramos três "vazamentos" clássicos de sistemas corporativos que estavam devorando nossos megabytes:

A Guerra dos Gráficos: Estávamos empacotando TRÊS bibliotecas de gráficos simultaneamente em telas diferentes: ECharts (~1MB), ApexCharts (~1MB) e Chart.js (~190KB). Padronizar a empresa para usar apenas uma delas limparia 1.2MB numa tacada só.
O Mistério do Service Gigante: Achamos um serviço (modelo-carroceria.service.ts) pesando inacreditáveis 500KB. Serviços normais têm 2KB! O motivo? Um JSON estático gigantesco (uma base de dados de caminhões) estava "chumbado" direto no código TypeScript, em vez de vir via API ou de um arquivo JSON estático na pasta assets.
Geradores de PDF Duplicados: O sistema importava a biblioteca jspdf isoladamente, mas também importava um componente pronto de terceiros que já trazia o jspdf embutido. O compilador não conseguiu unificar os dois, cobrando o peso em dobro.

Conclusão

Saber codificar telas bonitas é o básico do desenvolvimento web. Mas entender a anatomia do navegador, dominar a geração de chunks e saber medir o impacto de cada importação usando o Esbuild Analyzer é o que separa "fazer código" de Engenharia de Software.

Você já abriu a caixa preta do build no seu projeto Angular mais recente? Tomou algum susto com o tamanho de alguma biblioteca escondida? Compartilhem as experiências nos comentários! 👇

Migrando um YMS de 5 anos: Do Angular 16 ao 21 (Parte 9) - UX Corporativa: Dark Mode, Grids Dinâmicos e PrimeNG na prática

Erick Gabriel dos Santos Alves — Thu, 04 Jun 2026 01:40:30 +0000

Fala, comunidade dev! 👋

Chegamos ao nono e último artigo da nossa série documentando a evolução estrutural de um YMS (Yard Management System) gigante, saindo do Angular 16 direto para o 21. Já refatoramos o núcleo, as rotas, os Signals, a estrutura de pastas e a internacionalização.

Mas, para o usuário final, a arquitetura invisível do código não importa. O que importa é a tela. E hoje, os usuários de sistemas corporativos B2B (Backoffice, ERPs, YMS) não aceitam mais interfaces cinzas com cara de Windows 95. Eles exigem a mesma fluidez, UX e beleza dos aplicativos que usam no celular.

1. A Evolução do PrimeNG e o Padrão Ouro dos Grids

Nossa interface sempre foi alicerçada no PrimeNG. O pulo de 5 versões do Angular exigiu adequações estruturais pesadas na forma como lidávamos com os estilos. A biblioteca evoluiu muito para adotar um sistema de design baseado em tokens (CSS Variables) e uma integração profunda com Utility Classes (o PrimeFlex).

Sistemas logísticos respiram dados. Tabelas (<p-table>) não são apenas para visualização; elas são a principal ferramenta de trabalho do operador.

Implementamos recursos modernos que mudaram completamente a percepção de performance e usabilidade do usuário:

Filtros e Ordenação no lado do Servidor: Absolutamente essencial quando você tem milhões de registros na base de dados e não pode travar o navegador tentando filtrar isso no Front-end.
Scroll Virtual (Lazy Loading UI): Substituindo a paginação tradicional por um scroll infinito suave. O Angular destrói as linhas HTML que sobem pela tela e recria as que aparecem embaixo. Isso consome recursos de renderização da CPU apenas para as linhas que estão visíveis.
Salvamento de Estado (Stateful Grids): O usuário reordena as colunas, ajusta as larguras, sai da tela e, ao voltar no dia seguinte, a tabela "lembra" exatamente da preferência dele usando o Local Storage.

2. A Inevitável Chegada do Dark Mode

O Dark Mode (Modo Escuro) não é mais um "frufru" visual. Para operadores logísticos que passam 10 horas por dia olhando para painéis de controle e gráficos de pátio em salas escuras de monitoramento, é uma questão de saúde visual e ergonomia.

A Mágica dos Tokens: Com a arquitetura de tokens CSS das versões modernas do Angular e do PrimeNG, a alternância de temas parou de exigir a recarga inteira da página ou a inserção manual de dezenas de classes no HTML com JavaScript. Agora, mudar para o tema escuro é apenas uma substituição de variáveis nativas CSS (como --surface-a ou --text-color) na raiz do documento (:root). A transição é instantânea e extremamente leve para o navegador.

Conclusão: O Veredito da Jornada

Pular 5 versões de um ecossistema complexo exige sangue frio, testes extensivos e muita leitura de changelogs. Mas o resultado final faz cada erro de compilação no terminal valer a pena:

Um código absurdamente mais limpo (Adeus, app.module e ngOnDestroy!).
Uma compilação instantânea no ambiente de desenvolvimento (graças ao novo bundler com Vite e esbuild).
Uma aplicação rápida como um raio no navegador do usuário (com Signals e Zoneless).

Manter sistemas atualizados não é apenas perseguir a novidade tecnológica pelo hype. É garantir agilidade e segurança para continuar entregando valor ao negócio nos próximos 5 anos, sem que o código vire um legado intocável que ninguém na equipe tem coragem de mexer.

Espero que essa série de 9 artigos tenha ajudado a desmistificar alguns conceitos modernos do Angular e inspirado você a encarar a modernização das suas bases de código por aí.

Um grande abraço e até a próxima refatoração! 🚀

Quais foram os maiores desafios de UI/UX que vocês já enfrentaram em sistemas corporativos internos? Deixem nos comentários! 👇

Migrando um YMS de 5 anos: Do Angular 16 ao 21 (Parte 8) - i18n Enterprise e por que escolhemos o Transloco

Erick Gabriel dos Santos Alves — Thu, 04 Jun 2026 01:40:27 +0000

Fala, comunidade dev! 👋

Nesta jornada modernizando o nosso YMS, já passamos por performance, estrutura de pastas e padrões de código. Mas quando falamos de sistemas Enterprise, um requisito não-funcional frequentemente assombra as equipes de Front-end: a Internacionalização (i18n).

Muitos tutoriais ensinam a traduzir um botão de "Salvar" para "Save". Mas na trincheira de um sistema logístico real e de grande porte, as coisas são muito mais complexas. Não se trata apenas de traduzir palavras, mas de definir como essa tradução será processada na arquitetura da aplicação.

1. O Desafio Numérico (Muito além do texto)

Antes de falar de bibliotecas de tradução, precisamos lembrar que i18n afeta a matemática da tela. O peso de um caminhão no Brasil é 45.500,00 kg. Nos EUA, precisa ser renderizado obrigatoriamente como 45,500.00 kg. Uma vírgula no lugar errado em um sistema logístico gera multas milionárias nas rodovias.

Felizmente, aproveitando os Pipes nativos (DecimalPipe e DatePipe) combinados com a injeção do LOCALE_ID correto na inicialização da aplicação, o Angular resolve isso sozinho:

<span>Peso Lido: {{ pesoTotalCapturado | number:'1.2-2' }}</span>
<span>Data: {{ momentoPesagem | date:'short' }}</span>

2. O Dilema Arquitetural: Runtime vs. Build-time

Quando fomos refatorar a tradução dos textos e labels do sistema, esbarramos na grande dúvida: Abraçar o nativo @angular/localize ou utilizar bibliotecas de terceiros?

Para entender a nossa decisão, precisamos separar as abordagens em duas categorias:

A. Tradução em Tempo de Build (AOT) - @angular/localize
A solução nativa do Angular é fantástica para a performance da tela, pois ela embute os textos direto no HTML. Mas ela faz isso gerando uma versão inteira do sistema para cada idioma durante o ng build.

O Problema no YMS: Se temos 3 idiomas (PT, EN, ES), o nosso tempo de build no CI/CD triplica. Para um sistema gigante, gerar e hospedar múltiplas pastas de build (uma para cada língua) começou a travar a nossa esteira de deploy. Além disso, a troca de idioma exigia o recarregamento total da página.

B. Tradução em Tempo de Execução (Runtime) - `@jsverse/transloco`
Foi aqui que a biblioteca Transloco brilhou para nós. Ela carrega arquivos JSON com as traduções enquanto o usuário navega.

A Vitória da Manutenção: Com o Transloco, nós fazemos apenas um build. A grande sacada arquitetural dessa biblioteca são os Escopos (Lazy Load Scopes). Se o usuário acessa o módulo de Balança, o Transloco não baixa o dicionário do sistema inteiro; ele baixa apenas um micro-JSON de 2KB exclusivo daquela tela. O impacto na performance de rede é mínimo, a troca de idioma é em tempo real, e a nossa esteira de CI/CD agradece.

3. Na Prática: Escrevendo código com o Transloco

O Transloco nos oferece uma Developer Experience (DX) incrível, permitindo usar Pipes ou diretivas estruturais, mantendo o HTML limpo e otimizado.

No HTML:
Em vez de usar Pipes isolados para cada palavra (o que força o Angular a criar múltiplas inscrições por baixo dos panos), usamos a diretiva estrutural *transloco. Ela injeta a função de tradução apenas naquele bloco:

<ng-container *transloco="let t; read: 'balanca'">
  <button class="btn-primary">
    {{ t('btnConfirmarPesagem') }}
  </button>

  <p>
    {{ t('msgFila', { qtdCaminhoes: 5 }) }}
  </p>
</ng-container>

No TypeScript:
Para casos onde o texto precisa nascer dentro do código (como notificações de Toast dinâmicas ou mensagens de validação vindas da API), injetamos o TranslocoService:

import { Component, inject } from '@angular/core';
import { MessageService } from 'primeng/api';
import { TranslocoService } from '@jsverse/transloco';

@Component({ ... })
export class OperacaoComponent {
  private messageService = inject(MessageService);
  private translocoService = inject(TranslocoService);

  finalizarOperacao() {
    // Buscando a tradução em tempo real no TypeScript
    const msgSucesso = this.translocoService.translate('operacao.toastSucesso');

    this.messageService.add({ severity: 'success', detail: msgSucesso });
  }
}

Conclusão

O nativo @angular/localize é o rei da performance absoluta de renderização. Porém, para o nosso cenário corporativo, o Transloco entregou o equilíbrio perfeito: resolveu o gargalo do nosso tempo de build no CI/CD, evitou a complexidade de gerenciar múltiplos deploys e manteve a performance da aplicação alta graças ao carregamento sob demanda (Lazy Loading) dos dicionários.

No nosso nono e último artigo da série, vamos fechar com chave de ouro falando sobre UX Corporativa: como implementamos o tão pedido Dark Mode e dominamos as customizações de Grids pesadas do PrimeNG.

E vocês, preferem o modelo em tempo de execução (Transloco/ngx-translate) ou já adotaram o empacotamento em tempo de build do Angular? Conta aí nos comentários! 👇

Migrando um YMS de 5 anos: Do Angular 16 ao 21 (Parte 7) - Clean Architecture: A nova estrutura de pastas por domínios

Erick Gabriel dos Santos Alves — Thu, 04 Jun 2026 01:40:25 +0000

Fala, comunidade dev! 👋

Nas últimas 6 partes dessa série, mergulhamos fundo no código: Standalone Components, Rotas, Signals e Zoneless. Mas refatorar a arquitetura técnica sem arrumar a "casa" (a estrutura de pastas) é colocar motor de Ferrari em chassi de fusca.

Um projeto de 5 anos geralmente sofre do mesmo mal genérico de organização, e hoje vou mostrar como aplicamos conceitos de Clean Architecture e Domain-Driven Design (DDD) no Front-end para salvar a manutenção do nosso YMS (Yard Management System).

1. O Erro Clássico: Organização por Tipo Técnico

Lá no Angular 14/16, a literatura (e as ferramentas de CLI) nos ensinava a agrupar arquivos pelo que eles eram, e não pelo que eles faziam. A estrutura clássica de um sistema parecia assim:

src/app/
 ├── components/ (misturava botões com painéis de negócio)
 ├── models/     (centenas de interfaces jogadas aqui)
 ├── services/   (tudo que era API ficava aqui)
 └── views/      (as páginas em si)

O Pesadelo Cognitivo: Para alterar a tela de "Agendamento", o desenvolvedor precisava abrir a pasta de views para achar o HTML, depois pular para a pasta de models para entender a interface, e depois caçar a chamada de API na pasta de services. O código que mudava junto morava em bairros completamente diferentes do projeto.

2. A Virada: Estrutura Orientada a Domínios (Features)

Na migração para o Angular 21, pivotamos a arquitetura para domínios de negócio. A regra de ouro virou: se o código muda junto, ele deve morar junto.

Nossa nova arquitetura isola responsabilidades. O módulo (agora Standalone) de balanca não faz a menor ideia do que acontece dentro de agendamento.

src/app/
 ├── core/       (Interceptors, Auth, Guards - estritamente técnico e Singleton)
 ├── shared/     (Botões, Pipes, componentes UI "burros" e reaproveitáveis)
 └── features/   (Os Domínios do Negócio)
      ├── agendamento/
      │    ├── models/
      │    ├── services/
      │    └── components/
      ├── balanca/
      │    ├── models/
      │    ├── services/
      │    └── components/

3. Por que isso muda o jogo?

Organizar arquivos pode parecer preciosismo estético, mas em bases de código maduras e sistemas Enterprise, é a linha tênue entre entregar uma feature em 2 horas ou em 2 dias.

Onboarding rápido: Um desenvolvedor júnior entra no time hoje para arrumar um bug na tela da Balança. Ele abre a pasta features/balanca e absolutamente tudo que ele precisa para entender aquele contexto está lá dentro.
Escalabilidade e Desacoplamento: Se o negócio crescer absurdamente, nós podemos extrair a pasta balanca inteira e transformá-la em uma biblioteca independente (Angular Workspace/Nx) ou até mesmo em um Micro-frontend sem esforço, pois ela não compartilha "lixo" com outros domínios.

Conclusão

Ter um código moderno usando Signals e rodando sem o zone.js é maravilhoso, mas é a arquitetura de pastas que dita a velocidade e a sanidade mental do time no longo prazo.

No próximo post (Parte 8), vamos abordar um desafio Enterprise raiz que costuma dar muita dor de cabeça em sistemas legados: a Internacionalização de dados e traduções dinâmicas.

E como está a pasta src/app dos projetos de vocês hoje? Mais parecida com o primeiro modelo (técnico) ou com o segundo modelo (orientado a domínio)? Comentem aí! 👇

Migrando um YMS de 5 anos: Do Angular 16 ao 21 (Parte 6) - Zoneless Angular: O fim do zone.js e a verdadeira performance

Erick Gabriel dos Santos Alves — Thu, 04 Jun 2026 01:40:23 +0000

Fala, comunidade dev! 👋

Se você acompanhou o artigo anterior sobre a introdução dos Signals no nosso projeto corporativo, deve ter notado que a reatividade do Angular ficou mais "esperta". Mas para entender o ganho absurdo de performance que tivemos pulando para o Angular 21, precisamos falar do elefante na sala: o zone.js.

1. O que era o zone.js e por que ele virou um problema?

Desde o Angular 2, o framework usava uma biblioteca chamada zone.js para saber quando atualizar a tela. O zone.js atua como um "espião". Ele intercepta absolutamente tudo o que acontece no navegador do usuário: cliques de botão, setTimeout, chamadas HTTP (fetch/XHR).

Sempre que um desses eventos terminava, o zone.js gritava para o Angular: "Ei! Algo aconteceu. Verifique a árvore de componentes inteira para ver se alguma variável mudou!".

O Gargalo de Performance: Em um sistema pequeno, varrer a tela inteira é imperceptível. Mas em um YMS (sistema de gestão de pátios) com 5 anos de idade, exibindo grids de milhares de linhas e componentes pesados do PrimeNG, essa verificação constante (Change Detection Cycle) custava muito caro à CPU. Um simples setInterval rodando nos bastidores podia causar pequenos engasgos na interface inteira.

2. O Futuro Estável: Zoneless Angular

Com a chegada dos Signals, o Angular agora sabe exatamente qual variável mudou e qual pedaço mínimo do HTML precisa ser redesenhado. Ele não precisa mais do espião (zone.js) gritando para verificar o sistema inteiro.

No Angular 21, essa abordagem atingiu a maturidade. A API deixou de ser experimental e se tornou totalmente estável. Ativar a aplicação sem o Zone agora é o padrão recomendado e incrivelmente simples. Mudamos apenas o nosso arquivo de inicialização (main.ts):

// main.ts
import { bootstrapApplication } from '@angular/platform-browser';
import { provideZonelessChangeDetection } from '@angular/core';

bootstrapApplication(AppComponent, {
  providers: [
    provideZonelessChangeDetection(), // A mágica oficial e estável acontece aqui!
    // ... outros providers de rotas e HTTP
  ]
});

3. O Impacto no Projeto

Desligar o zone.js reduziu imediatamente o peso inicial do nosso pacote JavaScript (são cerca de 100KB a menos para o navegador baixar). Mas o principal benefício foi sentido na UX (Experiência do Usuário).

A interação com tabelas de dados dinâmicos, modais e filtros complexos passou a rodar cravada em 60 frames por segundo, sem que a Main Thread do navegador fosse bloqueada por dezenas de verificações desnecessárias a cada clique.

Atenção na Migração: Migrar um sistema legado para Zoneless exige cuidado. Você precisa garantir que o seu estado local já está usando Signals ou que você está chamando o ChangeDetectorRef.markForCheck() corretamente caso ainda dependa de bibliotecas de terceiros assíncronas que não foram atualizadas para Signals.

Conclusão

Remover o zone.js foi como tirar os "pesos de treinamento" das pernas do nosso Angular. O retorno em fluidez de tela e velocidade de carregamento é imediato e brutal.

No próximo post (Parte 7), vamos sair do nível do código e ir para o nível de arquitetura de pastas. Vou mostrar como organizamos um sistema gigantesco e escalável usando princípios de Clean Architecture.

Você já ativou o provideZonelessChangeDetection() nas suas aplicações mais recentes? Deu tudo certo de primeira ou alguma biblioteca antiga quebrou a renderização da tela? Conta aí nos comentários! 👇

Migrando um YMS de 5 anos: Do Angular 16 ao 21 (Parte 5) - Reatividade Limpa: Deixando o ngOnDestroy no passado com Signals

Erick Gabriel dos Santos Alves — Thu, 04 Jun 2026 01:40:21 +0000

Fala, comunidade dev! 👋

Na nossa jornada modernizando um sistema corporativo de 5 anos (do Angular 16 para o 21), já limpamos o app.module.ts, modernizamos as rotas, abraçamos o inject() e enxugamos o HTML. Mas existe um fantasma que assombra projetos legados: os vazamentos de memória (memory leaks).

Em sistemas pesados com dezenas de formulários e grids, assinar eventos do RxJS (subscribe) sem limpá-los no ngOnDestroy é o caminho mais rápido para travar o navegador do usuário. Hoje, vamos ver como os Signals mudaram o jogo da reatividade, especialmente lidando com Formulários Reativos.

1. O Fantasma do RxJS em Formulários

Sistemas Enterprise têm formulários gigantescos. Imagine uma tela de cadastro com dezenas de campos, onde a mudança de uma opção (como selecionar "Pessoa Jurídica") dispara validações ou desabilita outras partes da tela.

No Angular 16, ouvíamos essas mudanças assim:

O Antes (Poluição visual e risco de vazamento):

@Component({ ... })
export class CadastroComponent implements OnInit, OnDestroy {
  private destroy$ = new Subject<void>();
  formulario: FormGroup;

  ngOnInit() {
    // Ouve as mudanças do formulário
    this.formulario.get('tipoEntidade')?.valueChanges
      .pipe(takeUntil(this.destroy$)) // O boilerplate de sempre...
      .subscribe(valor => {
        this.atualizarRegrasDeTela(valor);
      });
  }

  ngOnDestroy() {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

A Bomba-Relógio: Multiplique esse boilerplate por 50 telas. É código repetitivo, propenso a falhas (quem nunca esqueceu um takeUntil ou esqueceu de implementar o ngOnDestroy?) e difícil de ler. Um único subscribe esquecido aberto fica rodando na memória RAM do navegador para sempre, mesmo após o usuário trocar de tela.

2. A Revolução dos Signals nos Formulários

Os Signals (signal(), computed(), effect()) introduziram uma reatividade síncrona, granular e livre de inscrições manuais. O Angular 21 permite transformar Observables (como o valueChanges do seu form) diretamente em Signals usando a função toSignal.

Olha como o mesmo código fica agora, sem implementar interfaces de ciclo de vida e sem o famigerado ngOnDestroy:

O Depois (Reativo, Limpo e Seguro):

@Component({ ... })
export class CadastroComponent {
  private fb = inject(FormBuilder);

  formulario = this.fb.group({
    tipoEntidade: ['']
  });

  // Transforma o Observable em um Signal reativo!
  tipoEntidadeSignal = toSignal(this.formulario.get('tipoEntidade')!.valueChanges);

  constructor() {
    // Reage automaticamente às mudanças. O Angular destrói isso sozinho!
    effect(() => {
      const valor = this.tipoEntidadeSignal();
      if (valor !== undefined) {
        this.atualizarRegrasDeTela(valor);
      }
    });
  }
}

A Mágica por baixo dos panos: O toSignal automaticamente se inscreve no Observable e, o mais importante, cancela a inscrição sozinho quando o componente é destruído. O effect rastreia suas dependências e só executa quando o valor realmente muda. Adeus, memory leaks!

Conclusão

Nós não abandonamos o RxJS. Ele continua sendo o rei absoluto para chamadas HTTP e fluxos assíncronos complexos baseados em eventos no tempo. Mas para gerenciamento de estado local da tela e formulários, os Signals removeram toneladas de código inútil do nosso projeto. O código ficou previsível, fácil de testar e livre de vazamentos de memória.

No próximo artigo (Parte 6), vamos falar sobre o impacto direto dessa reatividade síncrona: a possibilidade de finalmente desligarmos o motor antigo do Angular que causava tantos gargalos de performance, o zone.js. Vamos falar sobre o Zoneless Angular!

Você já começou a refatorar seus formulários velhos para usar Signals e toSignal? Conta aí a sua experiência! 👇

Migrando um YMS de 5 anos: Do Angular 16 ao 21 (Parte 4) - Templates Modernos: O Adeus ao ngIf e ngFor e a mágica do @defer

Erick Gabriel dos Santos Alves — Thu, 04 Jun 2026 01:40:12 +0000

Fala, comunidade dev! 👋

No artigo anterior desta nossa jornada de migração de um sistema YMS (do Angular 16 para o 21), exploramos como a função inject() limpou as nossas classes TypeScript e resolveu o "inferno" dos construtores. Mas hoje, vamos fechar os arquivos .ts e olhar para os nossos templates HTML.

O Angular passou por uma mudança drástica na forma como renderizamos o HTML. É hora de dar o adeus definitivo às velhas diretivas estruturais (*ngIf, *ngFor, *ngSwitch) e abraçar a nova sintaxe de Control Flow e o poderoso bloco @defer.

1. O Adeus ao CommonModule e à sintaxe pesada

Durante anos, para fazer um simples if/else no Angular, precisávamos importar o CommonModule (ou as diretivas de forma isolada nos componentes Standalone) e lidar com a criação de <ng-template> para blocos else.

Em uma tela de listagem de motoristas, o código clássico era assim:

O Antes (Angular 16):

<div *ngIf="motoristas.length > 0; else semMotoristas">
  <ul>
    <li *ngFor="let motorista of motoristas; trackBy: trackPorId">
      {{ motorista.nome }}
    </li>
  </ul>
</div>

<ng-template #semMotoristas>
  <p>Nenhum motorista encontrado na fila.</p>
</ng-template>

2. O Novo Control Flow: Limpo, Nativo e Direto

A partir do Angular 17, o framework introduziu uma nova sintaxe de bloco embutida diretamente no compilador. Não precisamos importar mais nada para fazer verificações lógicas. O código aproxima-se muito da fluidez de motores de template de outras linguagens (como o Razor ou o Blade).

Olhem como o mesmo cenário acima fica agora, no Angular 21:

O Depois (Angular 21):

@if (motoristas().length > 0) {
  <ul>
    @for (motorista of motoristas(); track motorista.id) {
      <li>{{ motorista.nome }}</li>
    }
  </ul>
} @else {
  <p>Nenhum motorista encontrado na fila.</p>
}

As grandes vitórias aqui:

Menos Imports: O @if e o @for são nativos, reduzindo o boilerplate do componente.

Track Obrigatório: O @for obriga a utilização da cláusula track. Isto previne um dos erros de performance mais comuns em projetos legados: renderizar listas gigantes de grids dinâmicas sem identificar os itens de forma unívoca, o que causava re-renderizações desnecessárias.

Leitura Fluida: Acabaram os <ng-template> perdidos no final do arquivo apenas para gerenciar estados de else ou loading.

3. A Verdadeira Mágica em Sistemas Enterprise: O `@defer`

Se o Control Flow melhora a Developer Experience (DX), o bloco @defer é um divisor de águas absoluto para a User Experience (UX) e Web Performance.

Num sistema logístico complexo, temos telas que carregam gráficos pesados de dashboards, modais com mapas de pátios e componentes complexos do PrimeNG que só são usados se o usuário interagir com eles. Antigamente, dividir o carregamento destes componentes exigia código complexo e Lazy Loading manual.

Agora, o Angular faz isso diretamente no HTML de forma declarativa.

O Exemplo Prático:
Imaginem um componente muito pesado de "Mapa de Pátio Logístico" que só deve ser carregado pelo navegador do usuário quando ele fizer scroll para baixo na página e o componente entrar na área visível (viewport):

@defer (on viewport) {
  <app-mapa-patio-pesado [dados]="dadosPatio"></app-mapa-patio-pesado>
} @placeholder {
  <p-skeleton width="100%" height="400px"></p-skeleton>
} @loading {
  <div class="spinner-logistico">Carregando o mapa...</div>
}

O Esbuild/Vite (o nosso novo bundler) entende este @defer durante o build, corta o componente app-mapa-patio-pesado e coloca-o num arquivo .js separado. Este pedaço de código só trafega na rede quando o usuário precisa realmente dele. Reduzimos dezenas de megabytes no carregamento inicial da aplicação com algumas linhas de HTML!

Conclusão

Atualizar o HTML de um projeto com 5 anos de idade assusta, mas felizmente a equipe do Angular disponibilizou esquemas de migração automatizados (ng generate @angular/core:control-flow) que fazem o trabalho pesado por nós.

Os novos templates deixaram as nossas views mais legíveis e deram-nos um controle de Lazy Loading granular sem paralelo.

No próximo artigo (Parte 5), vamos unir o HTML limpo com um estado TypeScript impecável. Vamos falar de reatividade, do adeus ao velho ngOnDestroy e mergulhar fundo no uso de Signals!

Já utilizaram o comando de migração automática de HTML nos projetos de vocês? Como foi a experiência de refatorar os antigos *ngIf e *ngFor? Compartilhem nos comentários! 👇

Migrando um YMS de 5 anos: Do Angular 16 ao 21 (Parte 3) - A Revolução Silenciosa da Função inject()

Erick Gabriel dos Santos Alves — Thu, 04 Jun 2026 01:40:03 +0000

Fala, comunidade dev! 👋

Na segunda parte da nossa série sobre a modernização de um sistema corporativo (saindo do Angular 16 e indo direto para o 21), vimos como o roteamento ficou muito mais limpo com o fim das antigas classes Guards. Mas eu deixei um gancho no ar: essa limpeza nas rotas só foi possível graças a uma pequena função que mudou para sempre a forma como escrevemos Angular.

Hoje vamos falar da verdadeira revolução silenciosa do framework: a função inject().

1. O Pesadelo do Construtor em Sistemas Corporativos

Quem trabalha com aplicações Enterprise sabe que uma única tela muitas vezes precisa se comunicar com diversas partes do sistema.

Imagine um cenário clássico que todo desenvolvedor já enfrentou: uma tela complexa de Cadastro de Usuários. Para essa tela funcionar, você precisa buscar dados do usuário, validar o CEP em uma API externa, checar permissões, montar o formulário e gerenciar alertas na tela.

No Angular 16, a única forma de trazer essas dependências para dentro do componente era através do constructor. O resultado era um bloco de código gigantesco, onde a injeção de dependência engolia a lógica de negócio:

O Antes (Poluição visual no Angular 16):

@Component({ ... })
export class CadastroUsuarioComponent {
  constructor(
    private usuarioService: UsuarioService,
    private viaCepService: ViaCepService,
    private permissoesService: PermissoesService,
    private fb: FormBuilder,
    private router: Router
  ) { }
}

Metade do arquivo do componente era apenas boilerplate (código repetitivo) para injetar dependências. Mas o problema real nem era a estética. O verdadeiro inferno começava quando precisávamos usar herança.

2. O Fim do "Inferno do super()"

Em arquiteturas limpas, é extremamente comum criarmos classes base para reaproveitar lógica. Um exemplo perfeito é um BaseFormComponent que concentra a lógica de exibição de toasts de erro, spinners de loading e validações genéricas.

A dor da herança antes do inject():
Se o seu BaseFormComponent precisasse injetar o MessageService e o LoadingService, todos os componentes filhos que estendessem essa classe precisavam injetar esses serviços em seus próprios construtores, apenas para passá-los para cima através da chamada do super().

// O componente filho precisava resolver dependências que não eram dele!
constructor(
  private usuarioService: UsuarioService,
  private fb: FormBuilder,
  // O componente filho nem usa esses dois, mas precisa injetar para o pai!
  private messageService: MessageService, 
  private loadingService: LoadingService
) {
  super(messageService, loadingService); 
}

Se um dia você precisasse adicionar mais um serviço genérico na classe base, você quebrava a aplicação inteira. Era necessário abrir e refatorar o construtor de dezenas (ou centenas) de telas filhas.

3. A Chegada da Injeção Baseada em Propriedades

Com a maturidade da função inject(), a injeção de dependências deixou de ser uma exclusividade do construtor e passou a ser declarada diretamente na inicialização das propriedades da classe.

O Depois (Limpo e escalável no Angular 21):

@Component({ ... })
export class CadastroUsuarioComponent extends BaseFormComponent {
  // A injeção agora vai direto na propriedade
  private usuarioService = inject(UsuarioService);
  private viaCepService = inject(ViaCepService);
  private fb = inject(FormBuilder);

  // O constructor sumiu! 
  // O BaseFormComponent se vira sozinho para buscar suas próprias dependências.
}

Nessa nova abordagem, a classe base (BaseFormComponent) usa o inject() internamente para pegar seus próprios serviços de alerta e loading. O componente filho não precisa mais saber (nem repassar) o que o pai está consumindo. O acoplamento despenca, e a refatoração vira uma tarefa segura e simples.

4. Fora das Classes: Interceptors Funcionais

Além de salvar a nossa sanidade na hora de estender classes, o inject() abriu as portas para o Angular ser muito mais funcional.

Assim como as rotas, os velhos HttpInterceptors (que interceptam requisições de API e também eram classes verbosas) viraram funções puras. Em qualquer sistema corporativo, injetar o Bearer Token de autenticação em todas as chamadas HTTP é regra. Olha como esse código ficou absurdamente simples e direto agora:

export const authInterceptor: HttpInterceptorFn = (req, next) => {
  const authService = inject(AuthService); // Injeção fora de uma classe!
  const token = authService.getToken();

  const requestModificada = req.clone({
    setHeaders: { Authorization: `Bearer ${token}` }
  });

  return next(requestModificada);
};

Conclusão

Adotar o inject() em todo o projeto reduz drasticamente a quantidade de linhas de código, melhora a legibilidade e blinda o seu sistema contra refatorações dolorosas em classes base. É uma mudança de paradigma que separa os projetos legados engessados dos códigos modernos e fluidos.

E por falar em reduzir código, no nosso próximo artigo da série (Parte 4), vamos sair do TypeScript e olhar para o HTML. Vamos dar o adeus definitivo ao *ngIf e ao *ngFor, e entender como o novo Control Flow e a mágica do @defer otimizam a renderização de telas pesadas.

Como está a adoção do inject() nos projetos de vocês? Ainda preferem o bom e velho construtor ou já abraçaram as propriedades dinâmicas? Comentem aí! 👇

Migrando um YMS de 5 anos: Do Angular 16 ao 21 (Parte 2) - Roteamento Moderno e o Fim das Classes Guards

Erick Gabriel dos Santos Alves — Thu, 04 Jun 2026 01:39:58 +0000

Fala, comunidade dev! 👋

No primeiro artigo da nossa série sobre a evolução arquitetural de um YMS (do Angular 16 para a versão 21), mostrei como deletamos o app.module.ts e abraçamos os Standalone Components. Se você perdeu, recomendo dar uma olhada lá antes de seguir.

Mas depois de remover o módulo principal, uma dúvida natural surge: como fica o roteamento? Afinal, a navegação de um sistema corporativo gigantesco costuma ser um emaranhado complexo de rotas protegidas e carregamento sob demanda (Lazy Loading).

Neste artigo, vou detalhar como o roteamento no Angular deixou de ser verboso para se tornar uma das APIs mais elegantes do ecossistema Front-end.

1. Lazy Loading sem Módulos: Mais direto e eficiente

No passado, para não carregar o YMS inteiro no primeiro clique do usuário, nós usávamos o Lazy Loading apontando para Módulos. O código era mais ou menos assim:

O Antes (Baseado em Módulos):

const routes: Routes = [
  {
    path: 'balanca',
    loadChildren: () => import('./balanca/balanca.module').then(m => m.BalancaModule)
  }
];

Agora que nossos componentes são independentes e gerenciam suas próprias dependências, não precisamos mais do intermediário (o módulo). O Angular introduziu o loadComponent para rotas simples e modernizou o loadChildren para carregar um arquivo de rotas filhas diretas.

O Depois (Standalone):

const routes: Routes = [
  // Carregando um único componente preguiçosamente
  {
    path: 'dashboard',
    loadComponent: () => import('./dashboard/dashboard.component').then(c => c.DashboardComponent)
  },
  // Carregando um grupo de rotas preguiçosamente
  {
    path: 'balanca',
    loadChildren: () => import('./balanca/balanca.routes').then(r => r.BALANCA_ROUTES)
  }
];

A mudança parece sutil, mas arquiteturalmente é brilhante. Você carrega apenas a árvore de componentes que a tela exige, potencializando o Tree-Shaking que discutimos no artigo anterior.

2. O Fim das Classes Guards: A verdadeira revolução silenciosa

Se o Lazy Loading ficou mais limpo, a segurança de rotas sofreu uma transformação radical. Em um YMS, temos dezenas de bloqueios: verificar se o usuário está logado, se ele tem permissão de "Operador de Balança" ou se a Ordem de Pesagem está no status correto para ser acessada.

Até o Angular 14/15, nós éramos obrigados a criar Classes Guards. Isso gerava um boilerplate imenso:

Criar uma classe.
Usar o decorator @Injectable().
Implementar a interface CanActivate.
Injetar serviços no constructor.

O Antes (Verboso e pesado):

@Injectable({
  providedIn: 'root'
})
export class AuthGuard implements CanActivate {
  constructor(private authService: AuthService, private router: Router) {}

  canActivate(): boolean {
    if (this.authService.isLoggedIn()) {
      return true;
    }
    this.router.navigate(['/login']);
    return false;
  }
}

No Angular 21, as classes Guards foram totalmente substituídas por Functional Guards.

Uma Guard agora é apenas uma função pura. Para acessar serviços dentro dessa função, o Angular nos deu a mágica função inject().

O Depois (Limpo e Direto):

export const authGuard: CanActivateFn = () => {
  const authService = inject(AuthService);
  const router = inject(Router);

  return authService.isLoggedIn() || router.createUrlTree(['/login']);
};

3. O Impacto no Arquivo de Rotas

Quando você junta o novo Lazy Loading com as Functional Guards, o seu arquivo de definição de rotas deixa de ser uma lista de declarações de classes complexas e passa a ser altamente declarativo e compositivo.

export const APP_ROUTES: Routes = [
  {
    path: 'balanca/ordem-pesagem',
    loadComponent: () => import('./ordem-pesagem.component').then(c => c.OrdemPesagemComponent),
    canActivate: [authGuard, operadorBalancaGuard] // Funções puras, encadeadas!
  }
];

Conclusão

A migração das rotas no nosso sistema exigiu refatorar dezenas de arquivos de Guards. Porém, ao transformar dezenas de linhas de classes verbosas em simples arrow functions, a base de código ficou infinitamente mais leve de ler, de dar manutenção e, principalmente, de escrever testes unitários (já que não precisamos mais instanciar classes gigantescas nos testes).

Essa limpeza extrema nas Guards só foi possível graças à introdução da função inject(). E é exatamente ela que vai ser a estrela do nosso próximo artigo, onde vamos explorar como o inject() mudou a forma como compartilhamos lógica e injeção de dependências em toda a aplicação.

Você já migrou suas antigas classes Guards para funções? Sentiu diferença na facilidade de manutenção? Deixe seu relato nos comentários! 👇

DEV Community: Erick Gabriel dos Santos Alves

Angular 22: O Framework finalmente encontrou sua identidade?

O Angular de 2026 é muito diferente do Angular de 2020

1. OnPush finalmente virou o padrão

2. Signals deixaram de ser novidade e viraram fundação

3. Computed Signals: reatividade sem esforço

4. Signal Forms finalmente ficaram prontos para produção

5. Resource API: a evolução mais subestimada do Angular

6. inject() mudou a forma de escrever Angular

7. O Angular está cada vez mais Zone-less

8. SSR e Hydration estão amadurecendo rapidamente

9. O HTTP Client também evoluiu

10. Angular e IA: o início de uma nova fase

O que esperar do Angular 23, 24 e além?

Conclusão

Desconstruindo o Build: A Revolução do Angular (E a diferença entre Compilador e Bundler)

1. Desfazendo a confusão: Compilador vs. Bundler

2. O Passado: A Era do Webpack

3. O Presente: A Revolução do Esbuild + Vite

4. O Impacto na Prática

Conclusão

Desconstruindo o Build: Como o Tree-Shaking realmente funciona (e por que o Bundle importa)

1. Mas primeiro: O que é esse tal de "Bundle"?

2. Qual o impacto prático do Bundle?

3. A Analogia da Árvore: Entendendo o Tree-Shaking

4. O Problema: Por que o NgModule era o inimigo do Tree-Shaking?

5. A Solução: A Transparência dos Standalone Components

Conclusão

Desconstruindo o Build: Chunks, Raio-X e a Anatomia do Navegador

1. Como o navegador entende a sua pasta de Build?

2. Lendo o Terminal: O que são os "Chunks"?

3. Qual é o "Tamanho Ideal" e os Performance Budgets?

4. O Raio-X do Bundle: Achando a "Gordura"

Conclusão

Migrando um YMS de 5 anos: Do Angular 16 ao 21 (Parte 9) - UX Corporativa: Dark Mode, Grids Dinâmicos e PrimeNG na prática

1. A Evolução do PrimeNG e o Padrão Ouro dos Grids

2. A Inevitável Chegada do Dark Mode

Conclusão: O Veredito da Jornada

Migrando um YMS de 5 anos: Do Angular 16 ao 21 (Parte 8) - i18n Enterprise e por que escolhemos o Transloco

1. O Desafio Numérico (Muito além do texto)

2. O Dilema Arquitetural: Runtime vs. Build-time

3. Na Prática: Escrevendo código com o Transloco

Conclusão

Migrando um YMS de 5 anos: Do Angular 16 ao 21 (Parte 7) - Clean Architecture: A nova estrutura de pastas por domínios

1. O Erro Clássico: Organização por Tipo Técnico

2. A Virada: Estrutura Orientada a Domínios (Features)

3. Por que isso muda o jogo?

Conclusão

Migrando um YMS de 5 anos: Do Angular 16 ao 21 (Parte 6) - Zoneless Angular: O fim do zone.js e a verdadeira performance

1. O que era o zone.js e por que ele virou um problema?

2. O Futuro Estável: Zoneless Angular

3. O Impacto no Projeto

Conclusão

Migrando um YMS de 5 anos: Do Angular 16 ao 21 (Parte 5) - Reatividade Limpa: Deixando o ngOnDestroy no passado com Signals

1. O Fantasma do RxJS em Formulários

2. A Revolução dos Signals nos Formulários

Conclusão

Migrando um YMS de 5 anos: Do Angular 16 ao 21 (Parte 4) - Templates Modernos: O Adeus ao *ngIf e *ngFor e a mágica do @defer

1. O Adeus ao CommonModule e à sintaxe pesada

2. O Novo Control Flow: Limpo, Nativo e Direto

3. A Verdadeira Mágica em Sistemas Enterprise: O @defer

Conclusão

Migrando um YMS de 5 anos: Do Angular 16 ao 21 (Parte 3) - A Revolução Silenciosa da Função inject()

1. O Pesadelo do Construtor em Sistemas Corporativos

2. O Fim do "Inferno do super()"

3. A Chegada da Injeção Baseada em Propriedades

4. Fora das Classes: Interceptors Funcionais

Conclusão

Migrando um YMS de 5 anos: Do Angular 16 ao 21 (Parte 2) - Roteamento Moderno e o Fim das Classes Guards

1. Lazy Loading sem Módulos: Mais direto e eficiente

2. O Fim das Classes Guards: A verdadeira revolução silenciosa

3. O Impacto no Arquivo de Rotas

Conclusão

6. `inject()` mudou a forma de escrever Angular

Migrando um YMS de 5 anos: Do Angular 16 ao 21 (Parte 4) - Templates Modernos: O Adeus ao ngIf e ngFor e a mágica do @defer

3. A Verdadeira Mágica em Sistemas Enterprise: O `@defer`