# Domande di colloquio Angular 19: Signals, SSR e concetti imprescindibili > Le domande di colloquio Angular 19 più frequenti: Signals, idratazione incrementale, change detection senza Zone.js e nuove API reattive con esempi di codice e risposte attese. - Published: 2026-03-28 - Updated: 2026-05-04 - Author: Anthony Fillion-Maillet - Tags: angular, interview, signals, ssr, angular-19 - Reading time: 9 min --- 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. > **Cosa valutano gli intervistatori nel 2026** > > Le domande su Angular 19 si concentrano su tre aree: reattività granulare con Signals, performance SSR tramite idratazione incrementale e capacità di progettare applicazioni senza Zone.js. Le risposte attese dimostrano comprensione architetturale, non solo conoscenza della sintassi. ## 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: ```typescript // signals-vs-observables.ts 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?"** ```typescript // user-card.component.ts import { Component, input, computed } from '@angular/core'; @Component({ selector: 'app-user-card', template: `

{{ fullName() }}

{{ role() }}
` }) export class UserCardComponent { // Signal inputs: strict typing, optional default value firstName = input.required(); lastName = input.required(); role = input('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?"** ```typescript // product-filter.component.ts 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. > **Trappola del colloquio: effect() con set()** > > Chiamare `signal.set()` dentro un `effect()` è un anti-pattern rilevato da Angular. Il framework emette un warning in modalità sviluppo. La soluzione corretta: usare `linkedSignal` o `computed()` a seconda che il valore derivato debba essere scrivibile. ## 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. ```typescript // user-profile.component.ts 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](https://blog.angular.dev/meet-angular-v19-7b29dfd05b84), è 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. ```typescript // product-page.component.ts import { Component } from '@angular/core'; @Component({ template: ` @defer (on viewport) { } @defer (on interaction) { } ` }) 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. ```typescript // app.routes.server.ts 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?"** ```typescript // main.ts 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 > **Angular 20.2: zoneless diventa stabile** > > Da Angular 20.2, la modalità zoneless è stabile con `provideZonelessChangeDetection()` (senza il prefisso Experimental). Menzionare questa evoluzione in colloquio dimostra una vigilanza attiva sull'ecosistema. ## 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?"** ```typescript // dashboard.component.ts @Component({ selector: 'app-dashboard', imports: [CommonModule, RouterModule, UserCardComponent], template: ` @for (user of users(); track user.id) { } ` }) export class DashboardComponent { users = signal([]); } ``` 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](https://angular.dev). 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](/blog/angular/top-25-angular-interview-questions). ## 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 --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/it/blog/angular/angular-19-interview-questions-signals-ssr-must-know