Angular 20 Resource API i httpResource: Kompletny przewodnik z pytaniami rekrutacyjnymi

Angular 20 wprowadza Resource API oraz httpResource jako stabilne mechanizmy reaktywnego pobierania danych opartego na systemie sygnalow. Te prymitywy, ktore w Angular 19 funkcjonowaly w trybie Developer Preview, zastepuja rozbudowane wzorce subskrypcji HttpClient deklaratywnymi konstrukcjami automatycznie sledzacymi stany ladowania, bledu i gotowosci danych. Zmiana ta eliminuje koniecznosc recznego zarzadzania subskrypcjami, tworzenia Subject do niszczenia oraz implementacji hookow cyklu zycia wylacznie w celu pobierania danych z serwera.

Niniejszy artykul omawia trzy warianty Resource API z praktycznymi przykladami kodu, prezentuje walidacje runtime za pomoca Zod, analizuje system sledzenia statusu oraz przedstawia najczesciej zadawane pytania na rozmowach kwalifikacyjnych z Angular w 2026 roku.

Trzy warianty Resource w Angular 20

Resource API w Angular 20 dostarcza trzy odrebne prymitywy do pobierania danych, z ktorych kazdy odpowiada innemu scenariuszowi architektonicznemu. Zrozumienie roznic miedzy nimi stanowi fundament swiadomego wyboru narzedzia w projekcie.

resource() to wariant bazowy operujacy na Promise. Przyjmuje funkcje params, ktora definiuje reaktywne zaleznosci, oraz funkcje loader zwracajaca Promise. Kazda zmiana wartosci produkowanej przez params powoduje automatyczne ponowne wykonanie loadera, z jednoczesnym anulowaniem poprzedniego zadania za pomoca AbortSignal. Wariant ten sprawdza sie przy bezposrednich wywolaniach fetch() lub integracji z bibliotekami opartymi na Promise.

rxResource() stanowi odpowiednik dla ekosystemu RxJS. Funkcja stream (wczesniej loader) zwraca Observable zamiast Promise. Framework przejmuje zarzadzanie subskrypcja i anulowaniem, co eliminuje potrzebe stosowania takeUntil czy recznego tworzenia Subject do niszczenia subskrypcji. Ten wariant okazuje sie niezbedny, gdy logika pobierania danych wymaga operatorow takich jak debounceTime, switchMap czy retry.

httpResource() to abstrakcja najwyzszego poziomu zbudowana na HttpClient. Przyjmuje URL lub obiekt konfiguracyjny zadania jako funkcje reaktywna i automatycznie obsluguje serializacje, naglowki oraz integracje z interceptorami. W przeciwienstwie do resource() nie wymaga definiowania jawnej funkcji loader -- framework buduje wywolanie HTTP wewnetrznie. Stanowi rekomendowany wybor dla zdecydowanej wiekszosci standardowych operacji pobierania danych.

Budowanie profilu uzytkownika za pomoca resource()

Ponizszy przyklad prezentuje zastosowanie resource() do reaktywnego ladowania profilu uzytkownika. Sygnal userId pelni role reaktywnej zaleznosci -- kazda modyfikacja jego wartosci automatycznie wyzwala nowe pobranie danych.

import { Component, signal, resource } from '@angular/core';

interface User {
  id: number;
  name: string;
  email: string;
}

@Component({
  selector: 'app-user-profile',
  template: `
    @if (userResource.hasValue()) {
      <h2>{{ userResource.value().name }}</h2>
      <p>{{ userResource.value().email }}</p>
    } @else if (userResource.isLoading()) {
      <p>Loading profile...</p>
    } @else if (userResource.error()) {
      <p>Failed to load user</p>
    }
  `,
})
export class UserProfileComponent {
  userId = signal(1);

  // params produces the reactive dependency
  // loader receives it and returns a Promise
  userResource = resource<User, number>({
    params: () => this.userId(),
    loader: async ({ params: id, abortSignal }) => {
      const res = await fetch(`/api/users/${id}`, { signal: abortSignal });
      return res.json();
    },
  });

  loadUser(id: number) {
    this.userId.set(id); // triggers automatic refetch
  }
}

Istota tego wzorca tkwi w rozdzieleniu reaktywnych zaleznosci od logiki ladowania danych. Funkcja params wykonuje sie w kontekscie reaktywnym frameworka, co oznacza, ze kazdy sygnal odczytany wewnatrz niej podlega automatycznemu sledzeniu. W momencie zmiany userId Angular anuluje ewentualne trwajace zadanie poprzez abortSignal dostarczony do loadera i uruchamia nowe wywolanie. Komponent nie wymaga zadnego jawnego kodu czyszczacego -- framework obsluguje caly cykl zycia pobrania danych wewnetrznie.

Metoda hasValue() pelni role warunku ochronnego w szablonie, gwarantujac, ze dostep do value() nastepuje wylacznie wtedy, gdy dane sa faktycznie dostepne. Metoda isLoading() zwraca true zarowno w stanie 'loading', jak i 'reloading', co upraszcza implementacje wskaznikow ladowania bez koniecznosci rozrozniania miedzy pierwszym a kolejnym pobraniem.

Szczegolowe omowienie systemu sygnalow lezacego u podstaw Resource API znajduje sie w przewodniku po Angular Signals.

Reaktywne pobieranie danych z httpResource

httpResource idzie o krok dalej w upraszczaniu wzorca pobierania danych -- eliminuje koniecznosc pisania funkcji loader. Framework samodzielnie konstruuje zadanie HTTP, korzystajac z HttpClient i interceptorow skonfigurowanych w aplikacji.

import { Component, signal, computed } from '@angular/core';
import { httpResource } from '@angular/common/http';

interface Product {
  id: number;
  name: string;
  price: number;
  category: string;
}

@Component({
  selector: 'app-product-list',
  template: `
    @if (products.hasValue()) {
      @for (product of products.value(); track product.id) {
        <div class="product-card">
          <h3>{{ product.name }}</h3>
          <span>{{ product.price | currency }}</span>
        </div>
      }
    } @else if (products.isLoading()) {
      <p>Loading products...</p>
    }
  `,
})
export class ProductListComponent {
  category = signal('electronics');

  // httpResource re-fetches whenever category() changes
  products = httpResource<Product[]>(() => ({
    url: '/api/products',
    params: { category: this.category() },
  }));

  filterByCategory(cat: string) {
    this.category.set(cat); // pending request is cancelled, new one starts
  }
}

Po wywolaniu filterByCategory() sygnal category zostaje zaktualizowany. Poniewaz funkcja konfiguracyjna przekazana do httpResource odczytuje this.category(), framework wykrywa zmiane i automatycznie anuluje trwajace zadanie HTTP, rozpoczynajac nowe z aktualnymi parametrami. Mechanizm ten dziala analogicznie do switchMap w RxJS, lecz bez syntaktycznej zlozonosci laczenia operatorow.

Warto zwrocic uwage na forme konfiguracji -- httpResource akceptuje zarowno prosty string URL, jak i obiekt z wlasciwosciami url, params, headers czy method. W przypadku obiektu parametry zapytania sa automatycznie serializowane i dolaczane do URL, co eliminuje reczne budowanie stringow zapytan.

Walidacja schematu z Zod i httpResource

Czestym problemem przy pobieraniu danych po stronie frontendu jest rozbieznosc miedzy oczekiwana struktura danych a tym, co faktycznie zwraca serwer. Angular 20 rozwiazuje ten problem poprzez wbudowany mechanizm walidacji w httpResource, dostepny za pomoca opcji parse.

Integracja z Zod pozwala zdefiniowac oczekiwany schemat i automatycznie zweryfikowac kazda odpowiedz, zanim wartosc zostanie udostepniona w szablonie. W przypadku niepowodzenia walidacji zasob przechodzi w stan error z opisowym komunikatem, co skutecznie blokuje renderowanie uszkodzonych danych.

import { Component, signal } from '@angular/core';
import { httpResource } from '@angular/common/http';
import { z } from 'zod';

// Define the expected shape with Zod
const OrderSchema = z.object({
  id: z.number(),
  status: z.enum(['pending', 'shipped', 'delivered', 'cancelled']),
  total: z.number().positive(),
  items: z.array(z.object({
    productId: z.number(),
    quantity: z.number().int().positive(),
    unitPrice: z.number().positive(),
  })),
  createdAt: z.string().datetime(),
});

type Order = z.infer<typeof OrderSchema>;

@Component({
  selector: 'app-order',
  template: `
    @if (order.hasValue()) {
      <h2>Order #{{ order.value().id }}</h2>
      <p>Status: {{ order.value().status }}</p>
      <p>Total: {{ order.value().total | currency }}</p>
    } @else if (order.error()) {
      <p>Invalid order data received</p>
    }
  `,
})
export class OrderComponent {
  orderId = signal(42);

  // parse validates the response before exposing it as a signal
  order = httpResource<Order>(
    () => `/api/orders/${this.orderId()}`,
    { parse: OrderSchema.parse }
  );
}

Wzorzec ten nabiera szczegolnego znaczenia w srodowiskach korporacyjnych, gdzie API rozwijane sa przez oddzielne zespoly, a struktura odpowiedzi moze ewoluowac bez uprzedniego powiadomienia. Walidacja runtime z Zod dziala jak kontrakt bezpieczenstwa miedzy frontendem a backendem -- niekompatybilnosci staja sie widoczne natychmiast, a nie po tygodniach od wdrozenia.

Opcja parse nie jest ograniczona do Zod. Kazda funkcja przyjmujaca unknown i zwracajaca oczekiwany typ spelnia wymagania interfejsu. Mozna wiec uzywac rowniez bibliotek takich jak Valibot, ArkType czy nawet wlasnych funkcji walidujacych. Kluczowe jest to, ze walidacja wykonuje sie przed udostepnieniem danych przez sygnal value(), co gwarantuje bezpieczenstwo typow w runtime, a nie jedynie w fazie kompilacji.

rxResource ze stream i params w Angular 20

W scenariuszach wymagajacych operatorow RxJS -- przykladowo pole wyszukiwania z opoznieniem (debounce) -- rxResource udostepnia interfejs oparty na Observable. Funkcja stream (przemianowana z loader w Angular 20) otrzymuje reaktywne parametry i zwraca Observable zarzadzany wewnetrznie przez framework.

import { Component, signal } from '@angular/core';
import { rxResource } from '@angular/core/rxjs-interop';
import { HttpClient } from '@angular/common/http';
import { inject } from '@angular/core';
import { debounceTime, switchMap } from 'rxjs';

interface SearchResult {
  id: number;
  title: string;
  excerpt: string;
}

@Component({
  selector: 'app-search',
  template: `
    <input (input)="query.set($any($event.target).value)" placeholder="Search..." />
    @if (results.isLoading()) {
      <p>Searching...</p>
    }
    @if (results.hasValue()) {
      @for (item of results.value(); track item.id) {
        <div>{{ item.title }}</div>
      }
    }
  `,
})
export class SearchComponent {
  private http = inject(HttpClient);
  query = signal('');

  // params (was "request") provides the reactive input
  // stream (was "loader") returns an Observable
  results = rxResource<SearchResult[], string>({
    params: () => this.query(),
    stream: ({ params: q }) =>
      this.http.get<SearchResult[]>('/api/search', {
        params: { q },
      }),
  });
}

Kluczowa roznica miedzy rxResource a resource lezy w typie zwracanym przez funkcje ladujaca: Observable zamiast Promise. Angular wewnetrznie obsluguje subskrypcje, automatyczne anulowanie przy zmianie parametrow oraz synchronizacje z cyklem detekcji zmian. Dla zespolow utrzymujacych bazy kodu z intensywnym uzyciem RxJS i HttpClient, rxResource stanowi najbardziej naturalna sciezke migracji do nowego modelu.

Warto podkreslic, ze rxResource importowany jest z @angular/core/rxjs-interop, co odzwierciedla jego nature jako mostu miedzy swiatem sygnalow a ekosystemem RxJS. Funkcja stream jest wywoylywana ponownie przy kazdej zmianie wartosci params, a wewnetrzna subskrypcja do poprzedniego Observable jest automatycznie konczona -- dokladnie tak, jak dzialaby switchMap w lancuchu operatorow.

Sledzenie statusu: literaly lancuchowe zastepuja enumy

Kazda instancja resource eksponuje sygnal status() zwracajacy literal lancuchowy okreslajacy biezacy stan ladowania. Model ten zastepuje dotychczasowe podejscie oparte na numerycznych enumach, co poprawia czytelnosc kodu i wspolprace z konstrukcjami @switch w szablonach Angular.

| Status | Znaczenie | |---|---| | 'idle' | params zwrocilo undefined -- zadne zadanie nie zostalo zainicjowane | | 'loading' | Pierwsze zadanie w toku | | 'reloading' | Kolejne zadanie po wczesniejszym sukcesie | | 'resolved' | Dane dostepne w value() | | 'error' | Zadanie zakonczylo sie bledem -- error() zawiera obiekt bledu | | 'local' | Wartosc ustawiona lokalnie przez .set() lub .update() |

Rozroznienie miedzy 'loading' a 'reloading' otwiera mozliwosc implementacji zroznicowanych wzorcow UX: pelnoekranowy spinner przy pierwszym ladowaniu danych i dyskretny wskaznik (np. pasek postepu w naglowku) przy kolejnych aktualizacjach, z jednoczesnym zachowaniem wczesniej zaladowanych danych na ekranie.

import { Component, signal, resource } from '@angular/core';

@Component({
  selector: 'app-status-demo',
  template: `
    <p>Status: {{ data.status() }}</p>
    @switch (data.status()) {
      @case ('loading') { <spinner /> }
      @case ('reloading') { <subtle-spinner /> }
      @case ('resolved') { <data-table [rows]="data.value()" /> }
      @case ('error') { <error-banner [error]="data.error()" /> }
      @case ('idle') { <p>Select a filter to load data</p> }
    }
  `,
})
export class StatusDemoComponent {
  filter = signal<string | undefined>(undefined);

  data = resource({
    params: () => this.filter(),
    loader: async ({ params: f, abortSignal }) => {
      const res = await fetch(`/api/data?filter=${f}`, { signal: abortSignal });
      return res.json();
    },
  });
}

Stan 'idle' zasluguje na szczegolna uwage: gdy funkcja params zwraca undefined, resource nie inicjuje zadnego zadania. Wzorzec ten pozwala realizowac warunkowe ladowanie danych -- pobranie nastepuje dopiero wtedy, gdy uzytkownik wykona konkretna akcje, np. wybierze filtr lub kategorie. Stan 'local' z kolei pojawia sie po recznej modyfikacji wartosci zasobu metoda .set() lub .update(), sygnalizujac ze biezaca wartosc nie pochodzi z odpowiedzi serwera.

Pytania rekrutacyjne Angular 20: Resource API i httpResource

Ponizsze pytania obejmuja zagadnienia najczesciej poruszane podczas rozmow kwalifikacyjnych na stanowiska Angular w 2026 roku. Odpowiedzi dostarczaja wystarczajacej glebokosci, by wykazac praktyczne zrozumienie Resource API w kontekscie produkcyjnym.

P1: Czym roznia sie resource(), rxResource() i httpResource() w Angular 20?

resource() to prymityw bazowy przyjmujacy funkcje loader zwracajaca Promise. rxResource() to wariant RxJS, w ktorym funkcja stream zwraca Observable. httpResource() to abstrakcja wyzszego poziomu wykorzystujaca wewnetrznie HttpClient i wymagajaca jedynie konfiguracji URL oraz parametrow. Wszystkie trzy warianty automatycznie sledza reaktywne zaleznosci przez funkcje params, anuluja oczekujace zadania przy zmianie parametrow i eksponuja stan poprzez sygnaly: value(), status(), error() oraz isLoading(). Wybor zalezy od kontekstu: httpResource w wiekszosci przypadkow, resource dla API spoza HTTP, rxResource gdy logika wymaga operatorow RxJS.

P2: Jak Angular obsluguje automatyczne anulowanie zadan w Resource API?

Przy zmianie wartosci zwracanej przez params() framework automatycznie anuluje biezace zadanie. W resource() odbywa sie to za posrednictwem AbortSignal przekazywanego do funkcji loader, ktory sygnalizuje anulowanie fetch(). W rxResource() framework konczy subskrypcje biezacego Observable i tworzy nowa -- zachowanie analogiczne do switchMap. W httpResource() anulowanie jest zarzadzane wewnetrznie przez HttpClient. Mechanizm ten eliminuje race conditions, w ktorych wolniejsza odpowiedz moglaby nadpisac nowsza -- problem okreslany jako "stale response override".

P3: Co sie dzieje, gdy params() zwraca undefined?

Gdy params() zwraca undefined, resource przechodzi w stan 'idle' i nie wysyla zadnego zadania HTTP. Jest to wzorzec warunkowego ladowania: resource pozostaje nieaktywny do momentu spelnienia wymaganych warunkow. Przykladowo komponent szczegolowy moze zwracac undefined gdy zaden element nie jest wybrany i inicjowac ladowanie dopiero po selekcji przez uzytkownika. Stan 'idle' rozni sie od 'loading' -- zadne zadanie nie jest w toku ani nie jest planowane, dopoki params() nie zwroci zdefiniowanej wartosci.

P4: Jak zintegrowac walidacje Zod z httpResource?

Opcja parse w httpResource przyjmuje funkcje walidujaca wykonywana na odpowiedzi HTTP przed udostepnieniem wartosci przez sygnal value(). Przekazanie OrderSchema.parse jako wartosci parse powoduje walidacje kazdej odpowiedzi wzgledem zdefiniowanego schematu Zod. Jesli walidacja konczy sie niepowodzeniem, resource przechodzi w stan 'error', a error() zawiera obiekt ZodError ze szczegolami naruszen. Wzorzec ten wprowadza kontrakt runtime miedzy frontendem a backendem -- szczegolnie cenny, gdy API rozwijane sa przez niezalezne zespoly, a schemat moze ewoluowac bez wczesniejszego uzgodnienia.

P5: Jaka jest roznica miedzy stanem 'loading' a 'reloading' w ResourceStatus?

Stan 'loading' oznacza, ze pierwsze zadanie jest w toku i w resource nie ma zadnych wczesniejszych danych. Stan 'reloading' oznacza, ze nowe zadanie zostalo uruchomione po wczesniejszym sukcesie -- poprzednia wartosc pozostaje dostepna przez value() podczas trwania nowego zadania. Rozroznienie to umozliwia zroznicowane wzorce UX: skeleton loader lub pelnoekranowy spinner przy pierwszym ladowaniu oraz dyskretny wskaznik aktualizacji (np. pasek postepu, obracajaca sie ikona) przy ponownym ladowaniu, z zachowaniem wyswietlonych danych w celu unikniecia migotania pustej tresci.

P6: Czy httpResource obsluguje metody HTTP inne niz GET?

httpResource zostal zaprojektowany wylacznie do operacji odczytu i obsluguje jedynie metode GET. Dla operacji zapisu (POST, PUT, DELETE) nalezy nadal korzystac z HttpClient bezposrednio lub mechanizmow Server Actions frameworka. Metody .set() i .update() dostepne na instancji resource modyfikuja jedynie lokalna wartosc sygnalu -- zadne zadanie HTTP nie jest wysylane. To ograniczenie wynika z deklaratywnej natury resource: jest on projekcja stanu serwera, a nie dwukierunkowym kanalem komunikacji.

Wiecej pytan rekrutacyjnych dotyczacych sygnalow i SSR w Angular znajduje sie w artykule o pytaniach rekrutacyjnych z Angular 19.

Migracja z subskrypcji HttpClient na httpResource

Resource API fundamentalnie redukuje ilosc kodu wymaganego do pobierania danych w porownaniu z tradycyjnym wzorcem recznych subskrypcji HttpClient. Ponizsze zestawienie obrazuje skale redukcji kodu szablonowego i eliminacje jawnego zarzadzania cyklem zycia komponentu.

// BEFORE: manual subscription in ngOnInit
@Component({ /* ... */ })
export class BeforeComponent implements OnInit, OnDestroy {
  private http = inject(HttpClient);
  private destroy$ = new Subject<void>();
  users: User[] = [];
  loading = false;
  error: string | null = null;

  ngOnInit() {
    this.loading = true;
    this.http.get<User[]>('/api/users')
      .pipe(takeUntil(this.destroy$))
      .subscribe({
        next: (data) => { this.users = data; this.loading = false; },
        error: (err) => { this.error = err.message; this.loading = false; },
      });
  }

  ngOnDestroy() {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

// AFTER: httpResource handles lifecycle automatically
@Component({ /* ... */ })
export class AfterComponent {
  users = httpResource<User[]>(() => '/api/users');
  // No ngOnInit, no Subject, no manual unsubscribe
  // Template uses users.value(), users.isLoading(), users.error()
}

Komponent w wersji "przed" wymaga implementacji OnInit do zainicjowania zadania, Subject do anulowania, oddzielnych zmiennych stanu dla danych, stanu ladowania i bledu, a takze OnDestroy w celu zapobiegania wyciekom pamieci. Komponent w wersji "po" kondensuje cala te logike w jednej deklaratywnej linii. Framework wewnetrznie przejmuje inicjowanie zadania, sledzenie stanu, anulowanie oraz czyszczenie zasobow przy niszczeniu komponentu.

Wzorzec ten ma szczegolne znaczenie w duzych bazach kodu, gdzie setki komponentow stosuja schemat ngOnInit + subscribe + takeUntil. Migracje mozna przeprowadzac stopniowo, komponent po komponencie, bez wplywu na pozostala czesc aplikacji. Kazdy zmigrowany komponent od razu korzysta z automatycznego sledzenia statusu, anulowania zadan i synchronizacji z systemem sygnalow, co redukuje powierzchnie potencjalnych bledow -- w szczegolnosci wyciekow pamieci wynikajacych z brakujacego takeUntil lub niekompletnego ngOnDestroy.

Podsumowanie

Resource API w Angular 20 stanowi punkt zwrotny w sposobie zarzadzania pobieraniem danych w aplikacjach Angular. Kluczowe wnioski:

• resource() to bazowy prymityw do asynchronicznego pobierania danych z Promise, z automatycznym anulowaniem przez AbortSignal i reaktywnym sledzeniem zaleznosci przez funkcje params
• httpResource() oferuje abstrakcje wyzszego poziomu nad HttpClient, eliminujaca kod szablonowy dla operacji GET i natywnie integrujaca sie z interceptorami, naglowkami oraz parametrami zapytan
• rxResource() zachowuje kompatybilnosc z RxJS dla scenariuszy wymagajacych operatorow takich jak debounceTime czy retry, operujac na Observable zamiast Promise i importowany z @angular/core/rxjs-interop
• Walidacja Zod przez opcje parse wprowadza kontrakty runtime miedzy frontendem a backendem, zapobiegajac renderowaniu wadliwych danych i wykrywajac niezgodnosci schematow natychmiast po ich wystapeniu
• System ResourceStatus z literalami lancuchowymi ('idle', 'loading', 'reloading', 'resolved', 'error', 'local') umozliwia zroznicowane wzorce UX dla pierwszego ladowania i kolejnych aktualizacji, przy czym stan 'idle' pozwala na warunkowe inicjowanie zadan
• Migracja z wzorca ngOnInit + subscribe + takeUntil moze przebiegac stopniowo, komponent po komponencie, znaczaco redukujac kod szablonowy i eliminujac potencjalne zrodla wyciekow pamieci

Dla zespolow przygotowujacych sie do technicznych rozmow kwalifikacyjnych z Angular, biegla znajomosc Resource API i zwiazanych z nia wzorcow stanowi obecnie wymaganie podstawowe. Umiejetnosc omowienia roznic miedzy trzema wariantami, wyjasnienia mechanizmu automatycznego anulowania zadan, opisania integracji z walidacja schematu oraz przedstawienia roznic miedzy stanami 'loading' a 'reloading' swiadczy o dojrzalym rozumieniu reaktywnej architektury Angular 20.