DEV Community: Erick Gabriel dos Santos Alves

Turbinando o Pipeline: Caches, Matrix Builds e Branch Protection (Parte 4)

Erick Gabriel dos Santos Alves — Mon, 03 Aug 2026 17:15:33 +0000

Chegamos ao grande final da nossa jornada! Recapitulando o que construímos até aqui:

Criamos um pipeline que testa e compila nosso Frontend (Angular) e Backend (.NET) em paralelo.
Tiramos a automação da nuvem paga e colocamos em um Self-Hosted Runner gratuito.
Automatizamos a criação de Tags e do Changelog.

Neste ponto, você já tem um processo melhor do que muitas empresas grandes por aí. Mas, se você observar os logs de execução, vai notar um gargalo frustrante: a instalação das dependências.

A cada push, seu robô perde minutos preciosos baixando a mesma pasta node_modules (o famoso buraco negro do universo) e os mesmos pacotes NuGet do zero. Hoje, vamos resolver isso e, de quebra, blindar a sua branch main contra códigos quebrados.

1. A Mágica do Cache

Em CI/CD, "Cache" significa guardar um backup das suas dependências da execução anterior. Se o seu arquivo package-lock.json ou .csproj não mudou, o GitHub Actions simplesmente restaura a pasta do cache em questão de segundos, pulando totalmente a etapa de download.

Otimizando o Frontend (Angular / Node)

Se você está usando a versão mais recente da action setup-node, o cache já vem embutido! Só precisamos ativá-lo e dizer onde está o nosso arquivo de lock, já que nosso projeto está dentro da pasta /frontend.

Vá no seu .yml da Parte 1 e atualize a etapa do Node.js:

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm' # Ativa o cache mágico!
          cache-dependency-path: './frontend/package-lock.json' # Aponta para a subpasta

Pronto. Só de adicionar essas duas linhas, o tempo do seu npm ci vai cair drasticamente.

Otimizando o Backend (.NET / NuGet)

Para o C#, precisamos usar a action oficial de cache (actions/cache). Ela exige três coisas: o que salvar (caminho), como nomear o backup (key) e de onde tentar recuperar se não achar o exato (restore-keys).

Adicione este bloco logo ANTES da etapa de dotnet restore:

      - name: Cache NuGet Packages
        uses: actions/cache@v4
        with:
          path: ~/.nuget/packages
          # Cria uma chave única baseada no SO e nos arquivos de projeto
          key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj', '**/packages.lock.json') }}
          restore-keys: |
            ${{ runner.os }}-nuget-

Na próxima vez que o pipeline rodar, a primeira execução ainda fará o download, mas salvará o cache no final. Nas execuções seguintes, você verá a magia da restauração rápida.

2. Testando Multiversos com Matrix Builds

E se você estiver construindo uma biblioteca ou ferramenta que precisa funcionar em múltiplas versões do Node (ex: 18 e 20) ou em vários Sistemas Operacionais simultaneamente?

Você não precisa copiar e colar o seu código YAML. Basta usar a estratégia de Matrix.

jobs:
  build-frontend:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18.x, 20.x, 22.x] # O GitHub vai rodar este Job 3 vezes simultaneamente!

    steps:
      - uses: actions/checkout@v4
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}

Com a matrix, o GitHub Actions cria caminhos paralelos automaticamente. Se uma versão falhar e as outras passarem, você sabe exatamente onde está o problema de compatibilidade.

3. O Leão de Chácara: Branch Protection Rules

De que adianta ter um pipeline que roda testes incríveis se um desenvolvedor apressado pode simplesmente clicar em "Merge Pull Request" ignorando que tudo ficou vermelho?

A automação só é útil se for obrigatória. Para isso, usamos as Regras de Proteção de Branch.

Vá na aba Settings do seu repositório no GitHub.
Na barra lateral, clique em Branches.
Clique em Add branch ruleset (ou edite a regra da sua branch main).
Marque a opção Require a pull request before merging.
O MAIS IMPORTANTE: Marque a opção Require status checks to pass before merging.
Na barra de pesquisa que aparecer, digite os nomes exatos dos seus Jobs (ex: Build Angular App e Build & Test .NET API) e adicione-os como obrigatórios.

O Resultado: A partir de agora, o botão verde de Merge no GitHub ficará bloqueado. Ele só será liberado se o nosso GitHub Actions rodar, compilar o Angular, passar nos testes do .NET e retornar a luz verde.

Conclusão da Série

Parabéns! Se você aplicou os conceitos desta série de 4 partes, você evoluiu de "alguém que arrasta arquivos para o FTP" para um administrador de infraestrutura ágil, segura e profissional.

Dominar pipelines, gestão de secrets, runners locais e versionamento semântico são habilidades que diferenciam desenvolvedores de alto nível no mercado. O GitHub Actions é uma ferramenta incrivelmente poderosa que vai muito além de apenas subir código.

Como ficou a sua esteira de CI/CD? Qual foi o tempo que você conseguiu economizar usando o sistema de Caches? Compartilhe o link do seu repositório (ou os perrengues que passou configurando) aqui nos comentários!

Versionamento Profissional: Automatizando Tags, Releases e Changelog (Parte 3)

Erick Gabriel dos Santos Alves — Mon, 03 Aug 2026 17:15:32 +0000

Se você acompanhou as partes anteriores desta série, seu projeto Full-Stack (Angular + .NET) já está sendo testado e compilado automaticamente em um Self-Hosted Runner gratuito. A infraestrutura está perfeita.

Mas e a organização do código?

Imagine a seguinte situação: você trabalha com mais três desenvolvedores. Vocês abrem PRs, fazem merge na branch main e o deploy acontece. Chega sexta-feira e o cliente pergunta: "O que exatamente entrou na versão 1.2.0 que acabou de ir pro ar?"

Se você responde revirando um histórico de commits cheio de "fix bug", "ajuste no layout", ou "wip", nós temos um problema.

Nesta Parte 3, vamos transformar seu repositório bagunçado em uma máquina de versionamento profissional. Vamos padronizar os commits, gerar o CHANGELOG.md magicamente e usar o GitHub Actions para criar Releases visuais.

Passo 1: O Fim do "Commit Bagunça"

A automação de versões depende de previsibilidade. O robô não sabe ler mentes, mas ele sabe ler padrões. É aqui que entra o Conventional Commits.

Em vez de escrever o que vier à cabeça, você passa a iniciar seus commits com prefixos específicos:

feat: adiciona dark mode no dashboard (Uma nova funcionalidade - vai gerar uma nova minor version ex: 1.1.0 -> 1.2.0)
fix: corrige erro no grid do canvas (Uma correção de bug - vai gerar um patch ex: 1.2.0 -> 1.2.1)
chore: atualiza dependências do Angular (Tarefas de manutenção que não afetam o usuário final)

Se você tem dificuldade de lembrar as regras, recomendo usar a biblioteca Commitizen. Ela transforma o comando git commit em um questionário interativo no seu terminal, forçando o padrão correto.

Passo 2: Gerando a Versão Magicamente

Agora que seus commits estão organizados no projeto, vamos usar uma ferramenta maravilhosa chamada commit-and-tag-version (um fork moderno do antigo standard-version).

Como nosso frontend é em Angular, podemos instalar isso facilmente na pasta do projeto usando o NPM:

cd frontend
npm i -D commit-and-tag-version

Agora, abra o seu package.json e adicione este script:

"scripts": {
  "release": "commit-and-tag-version"
}

O que esse comando faz? Quando você rodar npm run release, a ferramenta vai:

Ler todo o seu histórico de commits desde a última versão.
Descobrir automaticamente qual é a próxima versão (baseado nos seus feat: e fix:).
Atualizar o número da versão dentro do package.json.
Criar ou atualizar um arquivo CHANGELOG.md com um resumo lindíssimo de tudo que foi feito.
Fazer um commit automático com esses arquivos.
Criar uma Git Tag (ex: v1.2.0).

Passo 3: O Workflow de Release no GitHub

O nosso repositório local já está tagueado e o changelog foi gerado. Agora precisamos que o GitHub Actions perceba isso e crie uma aba de "Release" oficial lá no site do GitHub, para que qualquer pessoa possa baixar os binários ou ver as notas de atualização.

Vamos criar um novo arquivo de workflow. Crie .github/workflows/release.yml:

name: Generate GitHub Release

# Esse robô NÃO roda no push convencional. Ele só acorda quando uma Tag é enviada.
on:
  push:
    tags:
      - 'v*' # Aciona quando a tag começa com "v", ex: v1.0.0

jobs:
  create-release:
    name: Create Official Release
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0 # Essencial: baixa o histórico completo para ler as tags anteriores

      - name: Create GitHub Release
        # Uma action super popular para gerar a interface visual de Release no GitHub
        uses: softprops/action-gh-release@v2
        with:
          generate_release_notes: true # O próprio GitHub ajuda a agrupar as PRs na tela
          # files: se quiser, pode anexar um .zip do backend compilado aqui!

O Fluxo de Trabalho Completo (Dia a Dia)

Parece muita coisa, mas olha como a sua vida e da sua equipe fica simples no dia a dia:

Você trabalha no seu código normalmente.
Faz o commit usando o padrão: git commit -m "feat: integra API C# com o kanjidex"
Quando a equipe decide que é hora de ir para produção, você roda: npm run release
A ferramenta processa tudo, cria a tag e o CHANGELOG.md localmente.
Você envia tudo para o GitHub com um comando especial que empurra as tags junto com o código: git push --follow-tags

Pronto! O seu workflow principal da Parte 1 vai fazer o deploy da aplicação, e o nosso novo workflow da Parte 3 vai criar uma Release oficial no repositório. Documentação em dia sem você precisar escrever uma única linha de relatório.

Resumo e Próximos Passos

Temos integração contínua (CI), entrega contínua (CD), servidores gratuitos e versionamento semântico automatizado. É uma arquitetura de DevOps invejável!

Contudo, conforme o repositório fica gigante, as execuções começam a demorar. Ficar baixando a pasta node_modules e os pacotes NuGet do zero a cada execução não faz o menor sentido e atrasa a esteira.

Na Parte 4 (O Grande Final), vamos turbinar a performance do nosso pipeline implementando Caches inteligentes e explorando as Matrix Builds para testar múltiplos ambientes de uma só vez.

A Conta Chegou? Como Fugir do Limite de 2.000 Minutos do GitHub Actions (Parte 2)

Erick Gabriel dos Santos Alves — Mon, 03 Aug 2026 17:12:41 +0000

No episódio anterior desta série, nós configuramos um pipeline incrível que compila e testa nossa aplicação Full-Stack (Angular e .NET) em paralelo a cada push. A sensação de ver tudo verde e o deploy acontecendo sozinho é indescritível.

Mas então, o projeto cresce. A equipe começa a mandar dezenas de Pull Requests por dia. O tempo de build aumenta. E de repente, você recebe aquele e-mail assustador do GitHub: "You have used 100% of your included Action minutes".

A lua de mel com a automação acabou. A conta chegou.

No artigo de hoje, vamos resolver esse problema pela raiz. Vou te ensinar a configurar um Self-Hosted Runner: um jeito de fazer o GitHub rodar o seu pipeline de graça usando a sua própria máquina (ou uma VPS de 5 dólares).

O Problema dos 2.000 Minutos

Se o seu repositório for público (Open Source), o GitHub Actions é 100% gratuito e ilimitado. Porém, se o seu repositório for privado (o que é o caso de 99% dos projetos de empresas e startups), o GitHub te dá uma cota de 2.000 minutos por mês no plano gratuito.

Parece muito, mas faça as contas:

Seu build de Angular demora 2 minutos.
Seu build e testes de .NET demoram 3 minutos.
Total: 5 minutos por execução.
Com 20 pushes por dia em uma equipe média, você queima 100 minutos por dia. Em 20 dias úteis, sua cota zerou.

Depois disso, o GitHub começa a cobrar por minuto excedente, e a fatura em dólar pode assustar.

A Solução: Self-Hosted Runners

Por padrão, quando escrevemos runs-on: ubuntu-latest no nosso arquivo YAML, estamos alugando uma máquina virtual dos servidores da Microsoft/GitHub para rodar nossos comandos.

Um Self-Hosted Runner é um agente (um programinha) que você instala em um computador seu. Ele fica ouvindo o GitHub e diz: "Ei, não precisa alugar uma máquina. Pode mandar os comandos pra cá que eu executo localmente!".

Vantagens:

Fim do limite de minutos (você roda quantas vezes quiser de graça).
Você pode usar uma máquina muito mais potente que a do GitHub.
O agente pode acessar seu banco de dados local ou sua rede interna com facilidade.

Mão na Massa: Criando o seu Runner

Vamos configurar um runner na sua própria máquina para testes (o processo é idêntico se você for fazer em uma VPS Linux na nuvem).

Passo 1: Gerando o Token no GitHub

Vá até o seu repositório no GitHub.
Clique em Settings > Actions > Runners (na barra lateral esquerda).
Clique no botão verde New self-hosted runner.
Escolha o Sistema Operacional da máquina onde você vai instalar o agente (Linux, Windows ou macOS).

O GitHub vai gerar uma tela com vários comandos prontos. É só copiar e colar no seu terminal.

Passo 2: Instalando o Agente (Exemplo em Linux/WSL)

Abra o seu terminal e cole os comandos fornecidos pelo GitHub. Geralmente, eles se parecem com isso:

# 1. Cria uma pasta para o runner e entra nela
mkdir actions-runner && cd actions-runner

# 2. Baixa o pacote do runner
curl -o actions-runner-linux-x64-2.311.0.tar.gz -L [https://github.com/actions/runner/releases/download/](https://github.com/actions/runner/releases/download/)...

# 3. Extrai os arquivos
tar xzf ./actions-runner-linux-x64-2.311.0.tar.gz

# 4. Configura o runner e vincula ao seu repositório (O GitHub já coloca seu token aqui automaticamente)
./config.sh --url [https://github.com/SEU_USUARIO/SEU_REPOSITORIO](https://github.com/SEU_USUARIO/SEU_REPOSITORIO) --token ABCD1234EFGH5678

Durante a configuração, ele vai pedir um nome para o seu runner. Pode dar Enter para aceitar o padrão ou chamar de meu-servidor-01.

Passo 3: Ligando o Motor

Para ligar o agente, basta rodar:

./run.sh

Você verá a mensagem: Connected to GitHub e Listening for Jobs. Pronto! Sua máquina agora é uma extensão oficial do GitHub.

Atualizando o seu YAML (A Mágica Acontece)

Agora precisamos dizer para o nosso pipeline da Parte 1 parar de usar as máquinas pagas do GitHub e começar a usar a nossa.

Abra o seu arquivo .github/workflows/main.yml. Vá nos seus jobs e troque a linha runs-on: ubuntu-latest por runs-on: self-hosted.

Veja como fica:

jobs:
  build-frontend:
    name: Build Angular App
    # A MÁGICA ESTÁ AQUI 👇
    runs-on: self-hosted
    defaults:
      run:
        working-directory: ./frontend

    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      # ... resto dos passos iguais ...

  build-backend:
    name: Build & Test .NET API
    # A MÁGICA ESTÁ AQUI 👇
    runs-on: self-hosted
    defaults:
      run:
        working-directory: ./backend

    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      # ... resto dos passos iguais ...

Faça um commit dessa alteração e olhe para o seu terminal. Você vai ver os comandos do Angular e do .NET passando voando na sua própria tela!

Dica de Ouro: Rodando em Background

Se você fechar o terminal onde rodou o ./run.sh, o runner morre e seu pipeline para de funcionar. Para um ambiente de produção (como uma VPS), você precisa instalar o runner como um serviço do sistema, para que ele ligue sozinho se o servidor reiniciar.

O GitHub já manda o script pronto para isso. Dentro da pasta do runner, basta parar a execução (Ctrl+C) e rodar:

sudo ./svc.sh install
sudo ./svc.sh start

Agora ele está rodando silenciosamente no fundo (background) e você pode fechar o terminal tranquilamente.

O Que Vem a Seguir?

Se livrar dos custos com Self-Hosted Runners é um alívio gigante, especialmente em projetos corporativos. Agora você tem infraestrutura de sobra.

Mas, à medida que a equipe desenvolve e lança novas features, surge outro problema: como saber exatamente o que foi para produção? Como organizar as versões (v1.0.0, v1.1.0) do seu software sem fazer isso na mão?

No próximo episódio desta série, vamos transformar nosso pipeline em uma máquina de versionamento profissional usando automação de Tags, Releases e criação de Changelogs automáticos.

Do Zero ao Deploy: Seu Primeiro Pipeline de CI/CD Full-Stack com GitHub Actions (Parte 1)

Erick Gabriel dos Santos Alves — Wed, 29 Jul 2026 13:45:24 +0000

Seja honesto: quantas vezes você já terminou uma feature incrível, testou na sua máquina, e na hora de colocar em produção teve que rodar uma dezena de comandos manuais no terminal? Ou pior, teve que zipar pastas e arrastar para um servidor via FTP?

Fazer deploy manual não é apenas chato; é uma receita garantida para erros humanos. Esquecer de rodar os testes, subir com a connection string errada ou esquecer de instalar um pacote novo são clássicos do desenvolvimento de software.

Nesta série, vamos resolver isso de uma vez por todas. Hoje, na Parte 1, vamos criar um "robô" no GitHub Actions que vai testar e compilar sua aplicação Full-Stack (Frontend e Backend) em paralelo toda vez que você fizer um push.

O que é CI/CD de forma simples?

Esqueça as definições acadêmicas complexas:

CI (Continuous Integration): É a garantia de que o seu código novo não quebrou o que já funcionava. Nosso pipeline vai baixar o código e rodar o build e os testes automaticamente.
CD (Continuous Deployment): Se o CI passar e tudo estiver verde, o código é enviado automaticamente para o servidor de produção.

O Cenário Real: Angular + C# (.NET)

Em vez de um tutorial genérico com um site estático, vamos simular a vida real. Temos um repositório com uma API robusta em C# (.NET) e um Frontend dinâmico em Angular.

Queremos que o GitHub Actions rode os dois processos simultaneamente para economizar tempo.

Criando o nosso Workflow

No seu repositório, crie um arquivo no seguinte caminho: .github/workflows/main.yml. É aqui que a mágica acontece.

name: Full-Stack CI/CD Pipeline

# Quando esse robô deve trabalhar?
on:
  push:
    branches: [ "main" ] # Roda sempre que houver código novo na main

jobs:
  # JOB 1: O Frontend (Angular)
  build-frontend:
    name: Build Angular App
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: ./frontend

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '22'

      - name: Install Dependencies & Build
        run: |
          npm ci
          npm run build

  # JOB 2: O Backend (.NET C#) - Roda em paralelo com o Frontend!
  build-backend:
    name: Build & Test .NET API
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: ./backend

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.0.x'

      - name: Restore, Build, and Test
        run: |
          dotnet restore
          dotnet build --no-restore
          dotnet test --no-build --verbosity normal
        env:
          # Injetando variáveis de ambiente seguras no ambiente de teste
          DB_CONNECTION: ${{ secrets.DB_CONNECTION_STRING }}

  # JOB 3: O Deploy (Só roda se os dois de cima passarem)
  deploy:
    name: Deploy to Production
    needs: [build-frontend, build-backend] # A regra de ouro
    runs-on: ubuntu-latest

    steps:
      - name: Deploying Magic
        run: echo "🚀 Fazendo deploy seguro para o servidor..."
        # Aqui entrariam os scripts da sua nuvem (AWS, Azure, Vercel, etc.)

Entendendo a anatomia do YAML

Se você nunca lidou com GitHub Actions, essas palavras podem parecer confusas. Vamos traduzir o que acabamos de escrever:

on: Define o "gatilho" (trigger). É aqui que dizemos ao GitHub quando rodar nosso pipeline. No nosso caso, configuramos push na branch main. Ou seja: enviou código novo para a main, o robô acorda.
jobs: São as tarefas maiores que precisam ser feitas. Cada job (como build-frontend e build-backend) roda em um ambiente isolado. Por padrão, se você não disser o contrário, o GitHub tenta rodar todos os jobs ao mesmo tempo.
runs-on: Diz ao GitHub qual sistema operacional queremos usar. ubuntu-latest significa que o GitHub vai nos emprestar uma máquina virtual Linux novinha e limpa para cada execução.
steps: É a receita do bolo. É a lista sequencial de passos que devem ser executados dentro de um Job.
uses: Quando usamos uses, estamos pegando "atalhos" — ações pré-fabricadas pela comunidade. Por exemplo, actions/checkout@v4 é uma ação pronta que diz: "baixe o código desse repositório para dentro da máquina virtual".
run: É aqui que você digita comandos de terminal, exatamente como faria na sua máquina local (ex: npm run build ou dotnet test).

O Poder do Paralelismo e a Regra do Deploy

Repare que dividimos nossa automação em partes estratégicas:

Paralelismo: Como colocamos build-frontend e build-backend como jobs separados, o GitHub Actions vai rodar os dois ao mesmo tempo. Isso corta o tempo do seu CI pela metade!

Como você pode ver, enquanto o Angular é compilado, a API .NET já está sendo construída e testada.

A Regra do Deploy (needs): O job de deploy tem a propriedade needs: [build-frontend, build-backend]. Isso significa que ele vai esperar os dois builds terminarem.

Se o teste do C# quebrar, o deploy é cancelado e o código com bug não vai para produção. Tudo verde? O deploy é liberado!

Você também pode inspecionar cada etapa clicando nos jobs. É fantástico ver seus comandos sendo executados passo a passo em uma máquina virtual limpa:

Os logs mostram detalhadamente desde o setup do .NET até a execução dos testes.

Segurança Real: O uso de Secrets

No job do Backend, usamos ${{ secrets.DB_CONNECTION_STRING }}.

Nunca suba credenciais, senhas ou chaves de API no seu código-fonte!
Para passar essas informações de forma segura para o GitHub Actions:

Vá na aba Settings do seu repositório no GitHub.
Na barra lateral, clique em Secrets and variables > Actions.

Acessando a área de configuração segura do repositório.

Clique no botão verde New repository secret.
Defina o nome (exatamente como você chamou no arquivo YAML) e cole o valor real da sua string de conexão.

O valor inserido aqui é criptografado e nunca mais poderá ser lido diretamente, apenas atualizado ou apagado.

Uma vez salvo, o GitHub Actions vai injetar essa senha dinamicamente durante a execução, mantendo seus dados a salvo!

Secret configurado com sucesso.

E agora?

Missão cumprida! Com esse workflow, você elevou o padrão tecnológico do seu projeto. Ter um processo de validação automatizado garante que o seu código seja testado de forma isolada, limpa e padronizada.

Mas há um detalhe que ninguém te conta quando você começa a automatizar tudo: o limite gratuito.

O GitHub te dá 2.000 minutos grátis por mês para rodar essas Actions. Com uma aplicação Full-Stack e a equipe crescendo, esses minutos evaporam rápido. Quando a cota acaba, a conta chega (literalmente).

No próximo episódio da série, vou te ensinar como fugir dessa limitação hospedando um robô do GitHub (Self-Hosted Runner) de graça na sua própria máquina ou em uma VPS barata. Não perca!

Além da Teoria: Implementando WCAG no Angular Moderno (v21+)

Erick Gabriel dos Santos Alves — Tue, 21 Jul 2026 17:02:11 +0000

Acessibilidade web (WCAG) é o tipo de tema que todo mundo concorda que é crucial, mas que raramente recebe a atenção prática que merece durante a nossa formação. Seja na faculdade ou na grande maioria dos cursos de desenvolvimento, o assunto ou é completamente ignorado ou é tratado de forma puramente teórica. São raros os conteúdos que mostram como aplicar as diretrizes da WCAG na realidade de um framework componentizado.

Recentemente, passei pela experiência de implementar conformidade com a WCAG em um sistema corporativo real utilizando as versões mais recentes do Angular. Neste artigo, vamos entender o que é essa sopa de letrinhas, por que ela importa e como aplicar 4 abordagens práticas no ecossistema do Angular moderno.

Entendendo a WCAG: O que é e por que devemos nos importar?

WCAG significa Web Content Accessibility Guidelines (Diretrizes de Acessibilidade para Conteúdo Web). Desenvolvido pelo W3C (World Wide Web Consortium), trata-se do padrão ouro global que define como tornar o conteúdo da web mais acessível para pessoas com deficiências visuais, auditivas, físicas, cognitivas e neurológicas.

As diretrizes são organizadas sob 4 princípios fundamentais conhecidos como POUR:

Perceptível: A informação e os componentes da interface devem ser apresentados de forma que os usuários possam percebê-los (ex: texto alternativo para imagens, contraste adequado).
Operável: Os componentes da interface e a navegação devem ser operáveis através de diferentes dispositivos (ex: navegação completa apenas via teclado, sem armadilhas de foco).
Compreensível: A informação e a operação da interface devem ser fáceis de entender (ex: mensagens de erro claras em formulários).
Robusto: O conteúdo deve ser robusto o suficiente para ser interpretado de forma confiável por uma ampla variedade de tecnologias assistivas (como leitores de tela).

Por que devemos seguir a WCAG?

Inclusão e Alcance: Desenvolver pensando na WCAG garante que o seu software possa ser utilizado por qualquer pessoa, independentemente de suas limitações permanentes, temporárias ou situacionais.
Qualidade de Engenharia: Código acessível exige HTML semântico. Interfaces acessíveis possuem uma estrutura de árvore do DOM muito mais limpa, o que melhora indiretamente o SEO (Search Engine Optimization) e a manutenibilidade do projeto.
Conformidade Legal: Em escala global, governos e empresas estão tornando a acessibilidade um requisito obrigatório por lei. Negligenciar a WCAG pode resultar em barreiras comerciais e até processos jurídicos para sistemas corporativos.

Longe da teoria dos slides, o jogo muda quando precisamos abrir o repositório. Vamos ao código.

1. Atributos ARIA Dinâmicos com Signals

Acessibilidade em Single Page Applications (SPAs) precisa ser reativa. Quando o estado da interface muda, o leitor de tela precisa ser notificado imediatamente.

Em formulários de login, por exemplo, a ação de alternar a visibilidade da senha exige que o aria-label mude dinamicamente para que o usuário saiba exatamente o que o botão fará a seguir. Com a reatividade dos Signals, conseguimos vincular isso diretamente ao DOM utilizando o prefixo attr..

<div class="input-group">
  <input 
    [type]="showPassword() ? 'text' : 'password'" 
    id="password" 
    formControlName="password" 
  />
  <button 
    type="button"
    [attr.aria-label]="showPassword() ? 'Esconder senha' : 'Mostrar senha'"
    (click)="togglePasswordVisibility()"
  >
    <i [class]="showPassword() ? 'pi pi-eye-slash' : 'pi pi-eye'"></i>
  </button>
</div>

2. Navegação por Teclado e Gerenciamento de Foco

Um dos maiores problemas de acessibilidade na web moderna é a quebra de navegação por teclado. Elementos nativos como <button> e <a> já possuem comportamento de foco nativo, mas quando criamos componentes customizados (como timelines ou itens de menu baseados em div), eles ficam invisíveis para a tecla Tab.

Para resolver isso, precisamos injetar explicitamente o tabindex="0" (colocando o elemento na sequência natural de tabulação) e capturar os eventos de teclado correspondentes ao clique (Enter ou Espaço).

<div 
  class="timeline-item" 
  tabindex="0"
  role="button"
  (click)="selectEvent(event)"
  (keydown.enter)="selectEvent(event)"
>
  <div class="timeline-marker"></div>
  <div class="timeline-content">
    <h3>{{ event.title }}</h3>
    <p>{{ event.description }}</p>
  </div>
</div>

3. Papéis Semânticos (Roles) Explícitos para Interfaces Ricas

Quando a árvore do DOM é gerada através de múltiplos componentes aninhados do Angular, a semântica nativa do HTML pode se perder facilmente em meio a um mar de tags customizadas e invólucros estruturais.

Se você está construindo estruturas complexas, como uma barra de navegação ou um menu de configurações, o uso do atributo role ajuda o leitor de tela a mapear a árvore de acessibilidade corretamente.

<nav class="sidebar-menu" role="menu">
  @for (item of menuItems(); track item.id) {
    <div class="menu-item" role="menuitem" tabindex="0" (keydown.enter)="navigate(item.path)">
      <i [class]="item.icon"></i>
      <span>{{ item.label }}</span>
    </div>

    @if (item.hasSeparator) {
      <div class="menu-separator" role="separator"></div>
    }
  }
</nav>

4. Alternativas de Texto para Botões Apenas com Ícones

Botões que contêm apenas ícones (como botões de busca com uma lupa, exclusão com uma lixeira ou fechamento com um "X") são visualmente limpos, mas completamente mudos para um leitor de tela se não forem tratados. O software de acessibilidade tentará ler a classe CSS do ícone (ex: pi-search), resultando em uma experiência confusa.

Adicionar um aria-label descritivo garante que a função do botão seja anunciada perfeitamente.

<button 
  type="button" 
  class="p-button-rounded"
  aria-label="Pesquisar registros"
  (click)="executeSearch()"
>
  <i class="pi pi-search"></i>
</button>

Conclusão e Fluxo de Testes

Escrever código acessível não aumenta a complexidade da sua arquitetura; pelo contrário, força a escrita de um HTML mais limpo, semântico e robusto. Acessibilidade não é uma feature secundária para entregar no final do projeto, é parte fundamental da qualidade da engenharia do software.

Para validar essas implementações no dia a dia, recomendo fortemente integrar testes manuais ao seu fluxo de desenvolvimento:

Desconecte o mouse: Tente realizar o fluxo principal do seu sistema (como autenticação e navegação) usando apenas as teclas Tab, Shift + Tab e Enter.
Use Leitores Reais: Utilize ferramentas como o NVDA (Windows) ou o VoiceOver (macOS) em conjunto com o navegador para ouvir como a sua aplicação está se comportando em tempo real.

O ecossistema do Angular nos dá todas as ferramentas necessárias para criar aplicações inclusivas. Cabe a nós, desenvolvedores, virar a chave da teoria para a prática.

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í! 👇

DEV Community: Erick Gabriel dos Santos Alves

Turbinando o Pipeline: Caches, Matrix Builds e Branch Protection (Parte 4)

1. A Mágica do Cache

Otimizando o Frontend (Angular / Node)

Otimizando o Backend (.NET / NuGet)

2. Testando Multiversos com Matrix Builds

3. O Leão de Chácara: Branch Protection Rules

Conclusão da Série

Versionamento Profissional: Automatizando Tags, Releases e Changelog (Parte 3)

Passo 1: O Fim do "Commit Bagunça"

Passo 2: Gerando a Versão Magicamente

Passo 3: O Workflow de Release no GitHub

O Fluxo de Trabalho Completo (Dia a Dia)

Resumo e Próximos Passos

A Conta Chegou? Como Fugir do Limite de 2.000 Minutos do GitHub Actions (Parte 2)

O Problema dos 2.000 Minutos

A Solução: Self-Hosted Runners

Mão na Massa: Criando o seu Runner

Passo 1: Gerando o Token no GitHub

Passo 2: Instalando o Agente (Exemplo em Linux/WSL)

Passo 3: Ligando o Motor

Atualizando o seu YAML (A Mágica Acontece)

Dica de Ouro: Rodando em Background

O Que Vem a Seguir?

Do Zero ao Deploy: Seu Primeiro Pipeline de CI/CD Full-Stack com GitHub Actions (Parte 1)

O que é CI/CD de forma simples?

O Cenário Real: Angular + C# (.NET)

Criando o nosso Workflow

Entendendo a anatomia do YAML

O Poder do Paralelismo e a Regra do Deploy

Segurança Real: O uso de Secrets

E agora?

Além da Teoria: Implementando WCAG no Angular Moderno (v21+)

Entendendo a WCAG: O que é e por que devemos nos importar?

Por que devemos seguir a WCAG?

1. Atributos ARIA Dinâmicos com Signals

2. Navegação por Teclado e Gerenciamento de Foco

3. Papéis Semânticos (Roles) Explícitos para Interfaces Ricas

4. Alternativas de Texto para Botões Apenas com Ícones

Conclusão e Fluxo de Testes

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

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