Perguntas de entrevista Angular 19: Signals, SSR e conceitos essenciais

As entrevistas de Angular em 2026 vão muito além de componentes e serviços. O Angular 19, lançado em novembro de 2024, introduziu mudanças arquiteturais fundamentais: Signals estáveis, SSR com hidratação incremental e detecção de mudanças sem Zone.js. Dominar esses conceitos separa candidatos de nível médio dos seniores.

Angular 19 Signals: o novo modelo de reatividade

Os Signals representam a mudança mais profunda no Angular desde a introdução da detecção de mudanças. Um Signal é um valor reativo síncrono que notifica automaticamente seus consumidores quando muda.

Pergunta típica: "Qual a diferença entre um Signal e um Observable do RxJS?"

A resposta esperada distingue claramente os dois modelos:

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

// Signal: synchronous, value always available
const count = signal(0);
const doubled = computed(() => count() * 2); // Recomputed only when count changes

// Effect: reacts to signal changes
effect(() => {
  console.log(`Count: ${count()}, Doubled: ${doubled()}`);
});

count.set(5); // Immediate, synchronous notification

Os Signals usam um grafo de dependências granular. Diferente do RxJS, que gerencia fluxos assíncronos complexos (retry, debounce, merge), os Signals otimizam a reatividade síncrona da UI. O Angular 19 recomenda Signals para o estado de componentes e RxJS para fluxos assíncronos (requisições HTTP, WebSockets).

Signal Inputs e Queries: migrando do @Input()

O Angular 19 estabiliza as APIs baseadas em signals para inputs, outputs e queries. Essa pergunta aparece com frequência nas entrevistas.

Pergunta típica: "Como migrar um @Input() clássico para um Signal Input?"

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

@Component({
  selector: 'app-user-card',
  template: `
    <div class="card">
      <h3>{{ fullName() }}</h3>
      <span>{{ role() }}</span>
    </div>
  `
})
export class UserCardComponent {
  // Signal inputs: strict typing, optional default value
  firstName = input.required<string>();
  lastName = input.required<string>();
  role = input<string>('developer'); // Default value

  // Computed derived from inputs: automatically recomputed
  fullName = computed(() => `${this.firstName()} ${this.lastName()}`);
}

A principal vantagem: os Signal Inputs permitem criar valores computed() diretamente, sem hooks de ciclo de vida. Não é mais necessário usar ngOnChanges para reagir a mudanças nos inputs. O Angular fornece o schematic signal-input-migration para automatizar a migração.

linkedSignal: sincronizando estado dependente

linkedSignal é uma API experimental do Angular 19 que cria um signal gravável vinculado a uma fonte. Esse conceito aparece com frequência em entrevistas de nível sênior.

Pergunta típica: "Como lidar com estado derivado mutável usando linkedSignal?"

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

// Category list that can change
const categories = signal(['frontend', 'backend', 'devops']);

// Linked selection: resets when categories change
const selectedCategory = linkedSignal({
  source: categories,
  computation: (cats) => cats[0] // Reset to first element
});

// Manual modification still possible
selectedCategory.set('backend');

// When categories changes, selectedCategory resets automatically
categories.set(['mobile', 'data', 'cloud']);
// selectedCategory() === 'mobile'

Caso de uso concreto: um dropdown de filtro cuja seleção é reiniciada quando a lista fonte muda. Sem linkedSignal, esse padrão exigia um effect() com set(), um antipadrão que cria loops de atualização.

Resource API: carregando dados assíncronos com Signals

O Angular 19 introduz a API experimental resource para carregamento de dados assíncronos. Essa API substitui o padrão clássico de serviço + subscribe nos componentes.

import { resource, signal } from '@angular/core';
import { inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';

const userId = signal(42);
const http = inject(HttpClient);

// Resource: links a source signal to an async loader
const userResource = resource({
  request: () => ({ id: userId() }),  // Recomputed when userId changes
  loader: async ({ request }) => {
    const response = await fetch(`/api/users/${request.id}`);
    return response.json();
  }
});

// Access in template
// userResource.value()   -> data (or undefined)
// userResource.isLoading() -> boolean
// userResource.error()    -> error if any

Demonstrar conhecimento de resource versus rxResource (versão RxJS) em uma entrevista evidencia uma vigilância tecnológica ativa. rxResource usa Observables como loaders, útil para times com base de código RxJS existente.

SSR e hidratação incremental no Angular 19

O Angular 19 leva o SSR ao próximo nível com hidratação incremental em developer preview. Esse recurso, testado em escala do Google Search, é um tópico cada vez mais comum em entrevistas.

Pergunta típica: "Como funciona a hidratação incremental do Angular 19?"

A hidratação clássica recria toda a árvore de componentes no cliente após a renderização no servidor. A hidratação incremental hidrata apenas os componentes necessários, no momento em que se tornam visíveis ou interativos.

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

@Component({
  template: `
    <app-header />
    <app-product-details [id]="productId" />

    <!-- Hydrated only when visible in viewport -->
    @defer (on viewport) {
      <app-reviews [productId]="productId" />
    }

    <!-- Hydrated only on user interaction -->
    @defer (on interaction) {
      <app-comment-form />
    }
  `
})
export class ProductPageComponent {
  productId = 'angular-19-guide';
}

A diretiva @defer controla com precisão o momento da hidratação. Triggers disponíveis: on viewport (visível), on interaction (clique, focus), on idle (navegador ocioso), on timer(5s) (atraso). O conteúdo permanece visível como HTML estático antes da hidratação, sem flash.

Render mode por rota: SSR granular por rota

O Angular 19 introduz o render mode no nível de rota, permitindo a coexistência de SSR, SSG e CSR na mesma aplicação.

import { RenderMode, ServerRoute } from '@angular/ssr';

export const serverRoutes: ServerRoute[] = [
  // Marketing pages: pre-rendered at build time (SSG)
  { path: '', renderMode: RenderMode.Prerender },
  { path: 'pricing', renderMode: RenderMode.Prerender },

  // Dashboard: server-rendered on each request (SSR)
  { path: 'dashboard/**', renderMode: RenderMode.Server },

  // Interactive editor: client-side only (CSR)
  { path: 'editor/**', renderMode: RenderMode.Client },
];

Em entrevistas, a capacidade de justificar a escolha do render mode por rota demonstra compreensão dos trade-offs de performance, SEO e interatividade. Páginas estáticas (landing, blog) se beneficiam do prerender. Páginas dinâmicas com dados de usuário usam SSR. Aplicações altamente interativas permanecem em CSR.

Detecção de mudanças sem Zone: arquitetura sem Zone.js

A detecção de mudanças sem Zone.js é a evolução arquitetural mais significativa do Angular 19. Essa pergunta tornou-se obrigatória em entrevistas sêniores.

Pergunta típica: "Como funciona a detecção de mudanças sem Zone.js?"

import { bootstrapApplication } from '@angular/platform-browser';
import {
  provideExperimentalZonelessChangeDetection
} from '@angular/core';
import { AppComponent } from './app.component';

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

Sem Zone.js, o Angular não faz mais patch nas APIs assíncronas do navegador (setTimeout, Promise, addEventListener). A detecção de mudanças é acionada exclusivamente via Signals. Benefícios mensuráveis:

• Redução do tamanho do bundle de 10-15 KB (zone.js removido)
• Stack traces limpos sem frames do Zone.js
• Detecção de mudanças direcionada: apenas componentes afetados por um Signal modificado são re-renderizados

Standalone por padrão: o fim dos NgModules

O Angular 19 torna os componentes standalone o comportamento padrão. A flag standalone: true não é mais necessária. Essa decisão simplifica a arquitetura e reduz boilerplate.

Pergunta típica: "Qual o impacto do standalone-by-default na arquitetura de uma aplicação Angular?"

@Component({
  selector: 'app-dashboard',
  imports: [CommonModule, RouterModule, UserCardComponent],
  template: `
    <nav>
      <a routerLink="/home">Home</a>
    </nav>
    @for (user of users(); track user.id) {
      <app-user-card [firstName]="user.firstName" [lastName]="user.lastName" />
    }
  `
})
export class DashboardComponent {
  users = signal<User[]>([]);
}

Cada componente declara explicitamente suas dependências via imports. Os NgModules permanecem disponíveis por compatibilidade, mas novas aplicações Angular 19+ não precisam mais deles. Em entrevistas, explicar uma migração incremental (componente por componente) em vez de uma abordagem big bang é valorizado.

Estratégias de resposta para entrevistas Angular 19

Os entrevistadores técnicos avaliam três dimensões sobre Angular 19:

• Compreensão arquitetural: explicar por que os Signals substituem progressivamente o Zone.js, não apenas como usá-los
• Trade-offs: saber quando usar computed() versus linkedSignal versus effect(), e quando manter o RxJS
• Migração: descrever uma estratégia de migração incremental de uma aplicação Angular clássica para Signals e modo zoneless

A chave: evitar recitar a documentação oficial do Angular. Cada resposta deve ser ilustrada com um caso de uso concreto extraído de um projeto real, um formulário complexo, uma página de e-commerce com SSR, um dashboard em tempo real.

Para os conceitos fundamentais do Angular antes da entrevista, confira o guia completo das 25 perguntas de entrevista Angular.

Conclusão

• Os Signals do Angular 19 substituem os padrões @Input() + ngOnChanges por um modelo reativo síncrono granular. signal(), computed() e input() cobrem 90% dos casos de uso
• linkedSignal resolve o estado derivado mutável sem recorrer ao antipadrão effect() + set()
• A hidratação incremental via @defer reduz o Time to Interactive sem sacrificar o SEO. Cada componente é hidratado conforme seu trigger
• O modo zoneless remove o Zone.js do bundle e direciona a detecção de mudanças apenas para componentes afetados por Signals
• O render mode por rota permite misturar SSG, SSR e CSR na mesma aplicação conforme a necessidade de cada página
• Componentes standalone-by-default eliminam a necessidade de NgModules em novas aplicações
• Em entrevistas, demonstrar os trade-offs (Signals vs RxJS, SSR vs CSR, zoneless vs Zone.js) importa mais que sintaxe