Domande di colloquio Angular 19: Signals, SSR e concetti imprescindibili

I colloqui Angular nel 2026 vanno ben oltre componenti e service. Angular 19, rilasciato a novembre 2024, ha introdotto cambiamenti architetturali fondamentali: Signals stabili, SSR con idratazione incrementale e change detection senza Zone.js. Padroneggiare questi concetti separa i candidati mid-level dai senior.

Angular 19 Signals: il nuovo modello di reattività

I Signals rappresentano il cambiamento più profondo in Angular dall'introduzione della change detection. Un Signal è un valore reattivo sincrono che notifica automaticamente i suoi consumatori quando cambia.

Domanda tipica: "Qual è la differenza tra un Signal e un Observable RxJS?"

La risposta attesa distingue chiaramente i due modelli:

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

I Signals usano un grafo di dipendenze granulare. A differenza di RxJS, che gestisce flussi asincroni complessi (retry, debounce, merge), i Signals ottimizzano la reattività sincrona dell'UI. Angular 19 raccomanda i Signals per lo stato dei componenti e RxJS per gli stream asincroni (richieste HTTP, WebSocket).

Signal Inputs e Queries: migrare da @Input()

Angular 19 stabilizza le API basate sui signal per input, output e query. Questa domanda compare costantemente nei colloqui.

Domanda tipica: "Come migrare un @Input() classico verso un 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()}`);
}

Il vantaggio chiave: i Signal Inputs permettono di creare valori computed() direttamente, senza lifecycle hook. Non serve più ngOnChanges per reagire ai cambiamenti degli input. Angular fornisce lo schematic signal-input-migration per automatizzare la migrazione.

linkedSignal: sincronizzare stato dipendente

linkedSignal è un'API sperimentale di Angular 19 che crea un signal scrivibile collegato a una sorgente. Questo concetto compare frequentemente nei colloqui di livello senior.

Domanda tipica: "Come gestire uno stato derivato mutabile con 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 d'uso concreto: un dropdown di filtro la cui selezione si resetta quando cambia la lista sorgente. Senza linkedSignal, questo pattern richiedeva un effect() con set(), un anti-pattern che genera loop di aggiornamento.

Resource API: caricare dati asincroni con i Signals

Angular 19 introduce l'API sperimentale resource per il caricamento di dati asincroni. Questa API sostituisce il pattern classico service + subscribe nei componenti.

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

Dimostrare in un colloquio la conoscenza di resource rispetto a rxResource (versione RxJS) prova una vigilanza tecnologica attiva. rxResource usa Observable come loader, utile per team con codebase RxJS esistente.

SSR e idratazione incrementale in Angular 19

Angular 19 porta l'SSR al livello successivo con l'idratazione incrementale in developer preview. Questa funzionalità, testata su scala Google Search, è un argomento sempre più frequente nei colloqui.

Domanda tipica: "Come funziona l'idratazione incrementale di Angular 19?"

L'idratazione classica ricostruisce l'intero albero dei componenti lato client dopo il rendering server. L'idratazione incrementale idrata solo i componenti necessari, nel momento in cui diventano visibili o interattivi.

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';
}

La direttiva @defer controlla con precisione il momento dell'idratazione. Trigger disponibili: on viewport (visibile), on interaction (clic, focus), on idle (browser inattivo), on timer(5s) (ritardo). Il contenuto resta visibile come HTML statico prima dell'idratazione, senza flash.

Render mode per route: SSR granulare per route

Angular 19 introduce il render mode a livello di route, permettendo la coesistenza di SSR, SSG e CSR all'interno della stessa applicazione.

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 },
];

Nei colloqui, la capacità di giustificare la scelta del render mode per route dimostra comprensione dei trade-off tra performance, SEO e interattività. Le pagine statiche (landing, blog) beneficiano del prerender. Le pagine dinamiche con dati utente usano SSR. Le applicazioni altamente interattive restano su CSR.

Change detection senza Zone: architettura senza Zone.js

La change detection senza Zone.js è l'evoluzione architetturale più significativa di Angular 19. Questa domanda è diventata obbligatoria nei colloqui senior.

Domanda tipica: "Come funziona la change detection senza Zone.js?"

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

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

Senza Zone.js, Angular non patcha più le API asincrone del browser (setTimeout, Promise, addEventListener). La change detection viene attivata esclusivamente tramite Signals. Benefici misurabili:

• Riduzione della dimensione del bundle di 10-15 KB (zone.js rimosso)
• Stack trace puliti senza frame Zone.js
• Change detection mirata: solo i componenti interessati da un Signal modificato vengono re-renderizzati

Standalone di default: la fine degli NgModules

Angular 19 rende i componenti standalone il comportamento di default. Il flag standalone: true non è più necessario. Questa decisione semplifica l'architettura e riduce il boilerplate.

Domanda tipica: "Che impatto ha standalone-by-default sull'architettura di un'applicazione 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[]>([]);
}

Ogni componente dichiara esplicitamente le proprie dipendenze tramite imports. Gli NgModules restano disponibili per retrocompatibilità, ma le nuove applicazioni Angular 19+ non ne hanno più bisogno. Nei colloqui è apprezzato spiegare una migrazione incrementale (componente per componente) anziché un approccio big bang.

Strategie di risposta per i colloqui Angular 19

Gli intervistatori tecnici valutano tre dimensioni su Angular 19:

• Comprensione architetturale: spiegare perché i Signals sostituiscono progressivamente Zone.js, non solo come usarli
• Trade-off: sapere quando usare computed() rispetto a linkedSignal rispetto a effect(), e quando mantenere RxJS
• Migrazione: descrivere una strategia di migrazione incrementale da un'applicazione Angular classica verso Signals e modalità zoneless

La chiave: evitare di recitare la documentazione ufficiale Angular. Ogni risposta va illustrata con un caso d'uso concreto tratto da un progetto reale, un form complesso, una pagina e-commerce con SSR, una dashboard real-time.

Per i concetti fondamentali di Angular prima del colloquio, consultare la guida completa alle 25 domande di colloquio Angular.

Conclusione

• I Signals di Angular 19 sostituiscono i pattern @Input() + ngOnChanges con un modello reattivo sincrono granulare. signal(), computed() e input() coprono il 90% dei casi d'uso
• linkedSignal risolve lo stato derivato mutabile senza ricorrere all'anti-pattern effect() + set()
• L'idratazione incrementale tramite @defer riduce il Time to Interactive senza sacrificare la SEO. Ogni componente viene idratato secondo il proprio trigger
• La modalità zoneless rimuove Zone.js dal bundle e mira la change detection solo ai componenti toccati dai Signal
• Il render mode per route permette di mescolare SSG, SSR e CSR nella stessa applicazione in base alle esigenze di ciascuna pagina
• I componenti standalone-by-default eliminano la necessità degli NgModules nelle nuove applicazioni
• Nei colloqui, dimostrare i trade-off (Signals vs RxJS, SSR vs CSR, zoneless vs Zone.js) conta più della sintassi