Les entretiens Angular en 2026 testent bien plus que les composants et les services. Angular 19, sorti en novembre 2024, a introduit des changements architecturaux majeurs : Signals stables, SSR avec hydratation incrémentale et détection de changement zoneless. Maîtriser ces concepts fait la différence entre un candidat junior et un candidat senior. Les questions sur Angular 19 ciblent trois axes : la réactivité fine avec les Signals, la performance SSR avec l'hydratation incrémentale, et la capacité à concevoir des applications sans Zone.js. Les réponses attendues démontrent une compréhension architecturale, pas seulement syntaxique. ## Signals Angular 19 : le nouveau modèle de réactivité Les Signals représentent le changement le plus fondamental d'Angular depuis l'introduction du change detection. Un Signal est une valeur réactive synchrone qui notifie automatiquement ses consommateurs lorsqu'elle change. **Question type : "Quelle différence entre un Signal et un Observable RxJS ?"** La réponse attendue distingue clairement les deux modèles : ```typescript // signals-vs-observables.ts import { signal, computed, effect } from '@angular/core'; // Signal : synchrone, valeur toujours disponible const count = signal(0); const doubled = computed(() => count() * 2); // Recalculé uniquement si count change // Effect : réaction aux changements de signals effect(() => { console.log(`Count: ${count()}, Doubled: ${doubled()}`); }); count.set(5); // Notification immédiate, synchrone ``` Les Signals utilisent un graphe de dépendances fin. Contrairement à RxJS qui gère des flux asynchrones complexes (retry, debounce, merge), les Signals optimisent la réactivité synchrone de l'UI. Angular 19 recommande les Signals pour l'état du composant et RxJS pour les flux asynchrones (requêtes HTTP, WebSockets). ## Signal Inputs et Queries : migration depuis @Input() Angular 19 stabilise les API signal-based pour les inputs, outputs et queries. Cette question revient systématiquement en entretien. **Question type : "Comment migrer un @Input() classique vers un Signal Input ?"** ```typescript // user-card.component.ts import { Component, input, computed } from '@angular/core'; @Component({ selector: 'app-user-card', template: `

` }) export class UserCardComponent { // Signal inputs : typage strict, valeur par défaut optionnelle firstName = input.required(); lastName = input.required(); role = input('developer'); // Valeur par défaut // Computed dérivé des inputs : recalculé automatiquement fullName = computed(() => `${this.firstName()} ${this.lastName()}`); } ``` L'avantage clé : les Signal Inputs permettent de créer des `computed()` dérivés directement, sans lifecycle hooks. Plus besoin de `ngOnChanges` pour réagir aux changements d'inputs. Angular fournit le schematic `signal-input-migration` pour automatiser la migration. ## linkedSignal : synchroniser des états dépendants `linkedSignal` est une API expérimentale d'Angular 19 qui crée un signal en écriture lié à une source. Ce concept est fréquemment testé en entretien senior. **Question type : "Comment gérer un état dérivé modifiable avec linkedSignal ?"** ```typescript // product-filter.component.ts import { signal, linkedSignal } from '@angular/core'; // Liste de catégories qui peut changer const categories = signal(['frontend', 'backend', 'devops']); // Sélection liée : se réinitialise quand les catégories changent const selectedCategory = linkedSignal({ source: categories, computation: (cats) => cats[0] // Reset au premier élément }); // Modification manuelle possible selectedCategory.set('backend'); // Si categories change, selectedCategory se réinitialise automatiquement categories.set(['mobile', 'data', 'cloud']); // selectedCategory() === 'mobile' ``` Cas d'usage concret : un dropdown de filtres dont la sélection se réinitialise quand la liste source change. Sans `linkedSignal`, ce pattern nécessitait un `effect()` avec `set()` — un anti-pattern qui crée des boucles de mise à jour. Appeler `signal.set()` à l'intérieur d'un `effect()` est un anti-pattern détecté par Angular. Le framework émet un avertissement en mode développement. La solution correcte : utiliser `linkedSignal` ou `computed()` selon que la valeur dérivée doit être modifiable ou non. ## Resource API : charger des données asynchrones avec les Signals Angular 19 introduit l'API `resource` (expérimentale) pour le chargement asynchrone. Cette API remplace le pattern classique service + subscribe dans les composants. ```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 : lie un signal source à un chargement async const userResource = resource({ request: () => ({ id: userId() }), // Recalculé si userId change loader: async ({ request }) => { const response = await fetch(`/api/users/${request.id}`); return response.json(); } }); // Accès dans le template // userResource.value() → les données (ou undefined) // userResource.isLoading() → boolean // userResource.error() → erreur éventuelle ``` En entretien, démontrer la connaissance de `resource` vs `rxResource` (version RxJS) montre une veille technologique active. `rxResource` utilise des Observables comme loader, utile pour les équipes avec une base RxJS existante. ## SSR et hydratation incrémentale dans Angular 19 Angular 19 fait passer le SSR à un niveau supérieur avec l'hydratation incrémentale en developer preview. Cette fonctionnalité, testée à l'échelle de [Google Search](https://blog.angular.dev/meet-angular-v19-7b29dfd05b84), est un sujet d'entretien de plus en plus fréquent. **Question type : "Comment fonctionne l'hydratation incrémentale d'Angular 19 ?"** L'hydratation classique re-crée l'arbre de composants entier côté client après le rendu serveur. L'hydratation incrémentale hydrate uniquement les composants nécessaires, au moment où ils deviennent visibles ou interactifs. ```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 directive `@defer` contrôle précisément le moment de l'hydratation. Les triggers disponibles : `on viewport` (visible), `on interaction` (clic, focus), `on idle` (navigateur inactif), `on timer(5s)` (délai). Le contenu reste visible en HTML statique avant hydratation — aucun flash de contenu. ## Route-level render mode : SSR granulaire par route Angular 19 introduit le render mode au niveau des routes, permettant de mixer SSR, SSG et CSR dans la même application. ```typescript // app.routes.server.ts import { RenderMode, ServerRoute } from '@angular/ssr'; export const serverRoutes: ServerRoute[] = [ // Pages marketing : pré-rendues au build (SSG) { path: '', renderMode: RenderMode.Prerender }, { path: 'pricing', renderMode: RenderMode.Prerender }, // Dashboard : rendu côté serveur à chaque requête (SSR) { path: 'dashboard/**', renderMode: RenderMode.Server }, // Éditeur interactif : rendu côté client uniquement (CSR) { path: 'editor/**', renderMode: RenderMode.Client }, ]; ``` En entretien, la capacité à justifier le choix du render mode par route démontre une compréhension des trade-offs performance/SEO/interactivité. Les pages statiques (landing, blog) bénéficient du prerender. Les pages dynamiques avec données utilisateur utilisent le SSR. Les applications fortement interactives restent en CSR. ## Détection de changement zoneless : architecture sans Zone.js La détection de changement sans Zone.js est l'évolution architecturale la plus significative d'Angular 19. Cette question est devenue incontournable en entretien senior. **Question type : "Comment fonctionne la détection de changement sans 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() ] }); ``` Sans Zone.js, Angular ne patche plus les API asynchrones du navigateur (setTimeout, Promise, addEventListener). La détection de changement se déclenche uniquement via les Signals. Les bénéfices mesurables : - Réduction du bundle de 10-15 KB (suppression de zone.js) - Stack traces propres sans frames Zone.js - Détection de changement ciblée : seuls les composants affectés par un Signal modifié sont re-rendus Depuis Angular 20.2, le mode zoneless est stable avec `provideZonelessChangeDetection()` (sans le préfixe Experimental). En entretien, mentionner cette progression montre une veille active sur l'écosystème Angular. ## Standalone par défaut : la fin des NgModules Angular 19 fait des composants standalone le défaut. Le flag `standalone: true` n'est plus nécessaire. Cette décision simplifie l'architecture et réduit le boilerplate. **Question type : "Quel impact a standalone par défaut sur l'architecture d'une application 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([]); } ``` Chaque composant déclare explicitement ses dépendances via `imports`. Les NgModules restent disponibles pour la rétrocompatibilité, mais les nouvelles applications Angular 19+ n'en ont plus besoin. En entretien, expliquer la migration progressive (composant par composant) plutôt qu'un big bang est valorisé. ## Stratégies de réponse en entretien Angular 19 Les recruteurs techniques évaluent trois dimensions sur Angular 19 : - **Compréhension architecturale** : expliquer pourquoi les Signals remplacent progressivement Zone.js, pas seulement comment les utiliser - **Trade-offs** : savoir quand utiliser `computed()` vs `linkedSignal` vs `effect()`, et quand garder RxJS - **Migration** : décrire une stratégie de migration incrémentale depuis une application Angular classique vers les Signals et le mode zoneless La clé : ne pas réciter la [documentation officielle Angular](https://angular.dev). Illustrer chaque réponse avec un cas d'usage concret tiré d'un projet réel — un formulaire complexe, une page e-commerce avec SSR, un dashboard temps réel. Pour approfondir les bases Angular avant l'entretien, consulter le [guide complet des 25 questions d'entretien Angular](/blog/angular/top-25-questions-entretien-angular). ## Conclusion - Les Signals Angular 19 remplacent les patterns `@Input()` + `ngOnChanges` par un modèle réactif fin et synchrone — `signal()`, `computed()`, `input()` couvrent 90% des cas - `linkedSignal` résout le problème des états dérivés modifiables sans recourir à l'anti-pattern `effect()` + `set()` - L'hydratation incrémentale via `@defer` réduit le Time to Interactive sans sacrifier le SEO — chaque composant s'hydrate selon son trigger - Le mode zoneless supprime Zone.js du bundle et cible la détection de changement aux seuls composants affectés par un Signal - Le render mode par route permet de mixer SSG, SSR et CSR dans la même application selon les besoins de chaque page - Les composants standalone par défaut éliminent le besoin de NgModules pour les nouvelles applications - En entretien, démontrer les trade-offs (Signals vs RxJS, SSR vs CSR, zoneless vs Zone.js) compte plus que la syntaxe

{{ fullName() }}