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

> Szczegolowy przewodnik po Resource API w Angular 20: resource(), rxResource() i httpResource() do reaktywnego pobierania danych. Walidacja Zod, sledzenie statusu ResourceStatus, migracja z HttpClient oraz pytania na rozmowy kwalifikacyjne Angular 2026.

- Published: 2026-05-30
- Updated: 2026-05-30
- Author: SharpSkill
- Tags: angular, angular-20, resource-api, httpresource, signals, typescript, tutorial
- Reading time: 10 min

---

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.

> **Co zmienilo sie w Angular 20**
>
> Resource API zmienia nazwe `request` na `params` oraz `loader` na `stream` (w przypadku `rxResource`). Wartosci statusu przyjmuja teraz postac literalow lancuchowych (`'idle'`, `'loading'`, `'resolved'`, `'error'`, `'reloading'`, `'local'`) zamiast numerycznych enumow. `httpResource` bazuje na `HttpClient`, obslugujac interceptory oraz walidacje Zod bez dodatkowej konfiguracji.

## 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.

```typescript
// user-profile.component.ts
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](/technologies/angular/interview-questions/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.

```typescript
// product-list.component.ts
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.

> **httpResource obsluguje wylacznie odczyt**
>
> httpResource sluzy wylacznie do operacji odczytu (GET). Metody POST, PUT ani DELETE nie sa obslugiwane. Operacje zapisu wymagaja dalszego uzywania `HttpClient` bezposrednio lub Server Actions frameworka. Wywolanie `.set()` lub `.update()` na zasobie modyfikuje jedynie lokalna wartosc w sygnale -- zadne zadanie do serwera nie jest wysylane.

## 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](https://zod.dev) 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.

```typescript
// order.component.ts
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.

```typescript
// search.component.ts
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.

```typescript
// status-demo.component.ts
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.

> **Ostrzezenie dotyczace value() w stanie bledu**
>
> Metoda `value()` rzuca wyjatek, jezeli zostanie wywolana gdy resource znajduje sie w stanie `'error'`. Bezpieczny dostep do wartosci zapewnia metoda `hasValue()` uzyta jako warunek ochronny w szablonie, badz `value.asReadonly()` zwracajaca `undefined` w razie braku danych. Taka decyzja projektowa wymusza jawna obsluge stanow bledow i zapobiega przypadkowemu renderowaniu niepoprawnych danych.

## 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](/blog/angular/angular-19-interview-questions-signals-ssr-must-know).

## 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.

```typescript
// 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.

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/pl/blog/angular/angular-20-resource-api-httpresource-tutorial