Angular 19 sollicitatievragen: Signals, SSR en onmisbare concepten

Angular-sollicitatiegesprekken in 2026 gaan veel verder dan componenten en services. Angular 19, uitgebracht in november 2024, introduceerde fundamentele architecturale verschuivingen: stabiele Signals, SSR met incrementele hydration en zoneless change detection. Het beheersen van deze concepten onderscheidt mid-level kandidaten van senior kandidaten.

Angular 19 Signals: het nieuwe reactiviteitsmodel

Signals vormen de meest fundamentele verandering in Angular sinds de introductie van change detection. Een Signal is een synchrone reactieve waarde die zijn consumenten automatisch op de hoogte brengt wanneer hij verandert.

Typische vraag: "Wat is het verschil tussen een Signal en een RxJS Observable?"

Het verwachte antwoord onderscheidt beide modellen duidelijk:

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

Signals gebruiken een fijnmazige afhankelijkheidsgraaf. Anders dan RxJS, dat complexe asynchrone workflows afhandelt (retry, debounce, merge), optimaliseren Signals de synchrone UI-reactiviteit. Angular 19 raadt Signals aan voor componenttoestand en RxJS voor asynchrone streams (HTTP-verzoeken, WebSockets).

Signal Inputs en Queries: migreren vanaf @Input()

Angular 19 stabiliseert de signal-gebaseerde API's voor inputs, outputs en queries. Deze vraag komt consequent terug in sollicitatiegesprekken.

Typische vraag: "Hoe migreer je een klassieke @Input() naar een 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()}`);
}

Het belangrijkste voordeel: Signal Inputs maken het mogelijk om computed()-waarden direct te creëren, zonder lifecycle hooks. Geen ngOnChanges meer om op input-wijzigingen te reageren. Angular biedt het schematic signal-input-migration om de migratie te automatiseren.

linkedSignal: afhankelijke toestand synchroniseren

linkedSignal is een experimentele Angular 19 API die een schrijfbaar signal creëert dat aan een bron is gekoppeld. Dit concept verschijnt regelmatig in senior-sollicitatiegesprekken.

Typische vraag: "Hoe ga je om met muteerbare afgeleide toestand met 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'

Concrete use case: een filter-dropdown waarvan de selectie wordt gereset wanneer de bronlijst verandert. Zonder linkedSignal vereiste dit patroon een effect() met set(), een anti-pattern dat update-loops creëert.

Resource API: asynchrone data laden met Signals

Angular 19 introduceert de experimentele resource API voor het laden van asynchrone data. Deze API vervangt het klassieke service + subscribe-patroon in componenten.

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

Kennis tonen van resource versus rxResource (RxJS-versie) in een gesprek bewijst actieve technologische waakzaamheid. rxResource gebruikt Observables als loaders, nuttig voor teams met een bestaande RxJS-codebase.

SSR en incrementele hydration in Angular 19

Angular 19 tilt SSR naar een hoger niveau met incrementele hydration in developer preview. Deze functie, getest op Google Search-schaal, is een steeds vaker terugkerend gespreksonderwerp.

Typische vraag: "Hoe werkt de incrementele hydration van Angular 19?"

Klassieke hydration herbouwt de volledige componentboom client-side na het server-rendering. Incrementele hydration hydrateert alleen de noodzakelijke componenten, op het moment dat ze zichtbaar of interactief worden.

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

De @defer-directive bepaalt nauwkeurig wanneer de hydration plaatsvindt. Beschikbare triggers: on viewport (zichtbaar), on interaction (klik, focus), on idle (browser inactief), on timer(5s) (vertraging). De inhoud blijft zichtbaar als statische HTML voor de hydration, zonder flits.

Render mode per route: granulaire SSR per route

Angular 19 introduceert render mode op route-niveau, waardoor SSR, SSG en CSR binnen dezelfde applicatie kunnen samenleven.

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

In sollicitatiegesprekken toont het vermogen om de keuze van render mode per route te onderbouwen begrip van de trade-offs tussen prestaties, SEO en interactiviteit. Statische pagina's (landing, blog) profiteren van prerendering. Dynamische pagina's met gebruikersgegevens gebruiken SSR. Sterk interactieve applicaties blijven op CSR.

Zoneless change detection: architectuur zonder Zone.js

Zoneless change detection is de meest significante architectonische evolutie in Angular 19. Deze vraag is verplicht geworden in senior-sollicitatiegesprekken.

Typische vraag: "Hoe werkt change detection zonder Zone.js?"

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

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

Zonder Zone.js patcht Angular niet langer de asynchrone browser-API's (setTimeout, Promise, addEventListener). Change detection wordt uitsluitend door Signals geactiveerd. Meetbare voordelen:

• Bundle-grootte met 10-15 KB verminderd (zone.js verwijderd)
• Schone stack traces zonder Zone.js-frames
• Gerichte change detection: alleen componenten die door een gewijzigd Signal worden geraakt, renderen opnieuw

Standalone als standaard: het einde van NgModules

Angular 19 maakt standalone componenten het standaardgedrag. De vlag standalone: true is niet meer nodig. Deze beslissing vereenvoudigt de architectuur en vermindert boilerplate.

Typische vraag: "Welke impact heeft standalone-by-default op de architectuur van een Angular-applicatie?"

@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[]>([]);
}

Elk component declareert zijn afhankelijkheden expliciet via imports. NgModules blijven beschikbaar voor backwards compatibility, maar nieuwe Angular 19+-applicaties hebben ze niet meer nodig. In sollicitatiegesprekken wordt het uitleggen van een incrementele migratie (component voor component) in plaats van een big bang-aanpak gewaardeerd.

Antwoordstrategieën voor Angular 19 sollicitatiegesprekken

Technische interviewers evalueren drie dimensies over Angular 19:

• Architectonisch begrip: uitleggen waarom Signals Zone.js geleidelijk vervangen, niet alleen hoe ze te gebruiken
• Trade-offs: weten wanneer computed() versus linkedSignal versus effect() te gebruiken, en wanneer RxJS te behouden
• Migratie: een incrementele migratiestrategie beschrijven van een klassieke Angular-applicatie naar Signals en zoneless modus

De sleutel: vermijd het opdreunen van de officiële Angular-documentatie. Elk antwoord moet worden geïllustreerd met een concrete use case uit een echt project, een complex formulier, een e-commerce-pagina met SSR, een real-time dashboard.

Voor de fundamentele Angular-concepten voor het sollicitatiegesprek, zie de volledige gids met 25 Angular sollicitatievragen.

Conclusie

• Angular 19 Signals vervangen de patronen @Input() + ngOnChanges door een fijnmazig synchroon reactief model. signal(), computed() en input() dekken 90% van de use cases
• linkedSignal lost muteerbare afgeleide toestand op zonder terug te vallen op het anti-pattern effect() + set()
• Incrementele hydration via @defer verlaagt de Time to Interactive zonder SEO op te offeren. Elk component wordt gehydrateerd op basis van zijn trigger
• De zoneless modus verwijdert Zone.js uit de bundle en richt change detection uitsluitend op door Signals beïnvloede componenten
• Render mode per route maakt het mogelijk om SSG, SSR en CSR in dezelfde applicatie te combineren op basis van de behoeften van elke pagina
• Standalone-by-default componenten elimineren de noodzaak van NgModules in nieuwe applicaties
• In sollicitatiegesprekken telt het tonen van trade-offs (Signals vs RxJS, SSR vs CSR, zoneless vs Zone.js) zwaarder dan syntaxis