Pytania rekrutacyjne Angular 19: Signals, SSR i niezbędne koncepcje

Rekrutacje na stanowiska Angular w 2026 roku wykraczają daleko poza komponenty i serwisy. Angular 19, wydany w listopadzie 2024 roku, wprowadził fundamentalne zmiany architektoniczne: stabilne Signals, SSR z inkrementalnym hydration oraz zoneless change detection. Opanowanie tych koncepcji odróżnia kandydatów mid-level od seniorów.

Angular 19 Signals: nowy model reaktywności

Signals stanowią najważniejszą zmianę w Angular od czasu wprowadzenia change detection. Signal to synchroniczna wartość reaktywna, która automatycznie powiadamia swoich konsumentów o zmianie.

Typowe pytanie: "Jaka jest różnica między Signal a Observable z RxJS?"

Oczekiwana odpowiedź wyraźnie rozróżnia oba modele:

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 wykorzystują drobnoziarnisty graf zależności. W przeciwieństwie do RxJS, który obsługuje złożone asynchroniczne workflowy (retry, debounce, merge), Signals optymalizują synchroniczną reaktywność UI. Angular 19 zaleca Signals dla stanu komponentu i RxJS dla strumieni asynchronicznych (żądania HTTP, WebSockets).

Signal Inputs i Queries: migracja z @Input()

Angular 19 stabilizuje API oparte na signals dla inputów, outputów i queries. To pytanie pojawia się regularnie podczas rekrutacji.

Typowe pytanie: "Jak zmigrować klasyczne @Input() do 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()}`);
}

Kluczowa korzyść: Signal Inputs pozwalają tworzyć wartości computed() bezpośrednio, bez lifecycle hooks. Nie ma już potrzeby używania ngOnChanges do reagowania na zmiany inputów. Angular dostarcza schematic signal-input-migration automatyzujący migrację.

linkedSignal: synchronizacja stanu zależnego

linkedSignal to eksperymentalne API Angular 19 tworzące zapisywalny signal powiązany ze źródłem. Ta koncepcja często pojawia się w rekrutacjach na stanowiska senior.

Typowe pytanie: "Jak obsłużyć zmienny stan pochodny używając 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'

Konkretny przypadek użycia: dropdown filtra, którego wybór resetuje się, gdy zmienia się lista źródłowa. Bez linkedSignal ten wzorzec wymagał effect() z set(), anty-wzorca tworzącego pętle aktualizacji.

Resource API: ładowanie danych asynchronicznych z Signals

Angular 19 wprowadza eksperymentalne API resource do asynchronicznego ładowania danych. To API zastępuje klasyczny wzorzec serwis + subscribe w komponentach.

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

Wykazanie znajomości resource w porównaniu z rxResource (wersja RxJS) podczas rekrutacji świadczy o aktywnej obserwacji rozwoju technologii. rxResource wykorzystuje Observables jako loadery, co przydaje się zespołom z istniejącą bazą kodu RxJS.

SSR i inkrementalne hydration w Angular 19

Angular 19 wynosi SSR na nowy poziom dzięki inkrementalnemu hydration w developer preview. Ta funkcja, przetestowana w skali Google Search, staje się coraz częstszym tematem rekrutacji.

Typowe pytanie: "Jak działa inkrementalne hydration w Angular 19?"

Klasyczne hydration odtwarza całe drzewo komponentów po stronie klienta po renderowaniu serwerowym. Inkrementalne hydration nawadnia tylko niezbędne komponenty, w momencie, gdy stają się widoczne lub interaktywne.

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

Dyrektywa @defer precyzyjnie kontroluje moment hydration. Dostępne triggery: on viewport (widoczny), on interaction (kliknięcie, focus), on idle (przeglądarka bezczynna), on timer(5s) (opóźnienie). Treść pozostaje widoczna jako statyczny HTML przed hydration, bez migotania.

Render mode na poziomie route: granularny SSR per route

Angular 19 wprowadza render mode na poziomie route, umożliwiając współistnienie SSR, SSG i CSR w tej samej aplikacji.

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

Podczas rekrutacji umiejętność uzasadnienia wyboru render mode dla danego route świadczy o zrozumieniu trade-offów między wydajnością, SEO a interaktywnością. Strony statyczne (landing, blog) korzystają z prerenderingu. Strony dynamiczne z danymi użytkownika używają SSR. Aplikacje wysoce interaktywne pozostają na CSR.

Zoneless change detection: architektura bez Zone.js

Zoneless change detection to najważniejsza ewolucja architektoniczna w Angular 19. To pytanie stało się obowiązkowe w rekrutacjach na seniorów.

Typowe pytanie: "Jak działa change detection bez Zone.js?"

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

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

Bez Zone.js Angular nie patchuje już asynchronicznych API przeglądarki (setTimeout, Promise, addEventListener). Change detection jest wyzwalane wyłącznie przez Signals. Mierzalne korzyści:

• Zmniejszenie rozmiaru bundla o 10-15 KB (zone.js usunięte)
• Czyste stack trace bez ramek Zone.js
• Ukierunkowane change detection: tylko komponenty dotknięte zmienionym Signal renderują się ponownie

Standalone domyślnie: koniec NgModules

Angular 19 sprawia, że komponenty standalone są zachowaniem domyślnym. Flaga standalone: true nie jest już potrzebna. Ta decyzja upraszcza architekturę i redukuje boilerplate.

Typowe pytanie: "Jaki wpływ ma standalone-by-default na architekturę aplikacji 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[]>([]);
}

Każdy komponent jawnie deklaruje swoje zależności poprzez imports. NgModules pozostają dostępne dla wstecznej kompatybilności, jednak nowe aplikacje Angular 19+ ich nie potrzebują. Podczas rekrutacji ceniona jest umiejętność wyjaśnienia migracji inkrementalnej (komponent po komponencie) zamiast podejścia big bang.

Strategie odpowiedzi na rekrutacjach Angular 19

Rekruterzy techniczni oceniają trzy wymiary dotyczące Angular 19:

• Zrozumienie architektoniczne: wyjaśnienie, dlaczego Signals stopniowo zastępują Zone.js, a nie tylko jak ich używać
• Trade-offy: wiedza, kiedy używać computed() versus linkedSignal versus effect() i kiedy zachować RxJS
• Migracja: opisanie strategii migracji inkrementalnej z klasycznej aplikacji Angular do Signals i trybu zoneless

Klucz: unikać recytowania oficjalnej dokumentacji Angular. Każdą odpowiedź należy zilustrować konkretnym przypadkiem użycia z prawdziwego projektu, złożonym formularzem, stroną e-commerce z SSR, dashboardem czasu rzeczywistego.

Dla podstawowych koncepcji Angular przed rekrutacją, zobacz pełny przewodnik po 25 pytaniach rekrutacyjnych Angular.

Podsumowanie

• Signals z Angular 19 zastępują wzorce @Input() + ngOnChanges drobnoziarnistym synchronicznym modelem reaktywnym. signal(), computed() i input() pokrywają 90% przypadków użycia
• linkedSignal rozwiązuje zmienny stan pochodny bez uciekania się do anty-wzorca effect() + set()
• Inkrementalne hydration poprzez @defer redukuje Time to Interactive bez poświęcania SEO. Każdy komponent jest hydratowany zgodnie ze swoim triggerem
• Tryb zoneless usuwa Zone.js z bundla i kieruje change detection wyłącznie do komponentów dotkniętych przez Signal
• Render mode per route pozwala mieszać SSG, SSR i CSR w tej samej aplikacji w zależności od potrzeb każdej strony
• Komponenty standalone-by-default eliminują potrzebę NgModules w nowych aplikacjach
• W rekrutacjach pokazanie trade-offów (Signals vs RxJS, SSR vs CSR, zoneless vs Zone.js) liczy się bardziej niż składnia