July 21, 2025

Reactive APIs in Angular Teil 1 – Resource API resource() und rxResource()

Click here for the english version of this blog post.

Reactive APIs in Angular 20: Kommuniziere asynchron mit Signals durch die Resource API

Mit Angular 19 wurde eine reactive API als neues Feature eingeführt, die Resource API. Zwar gilt die API, auch jetzt in v20, noch als experimentelles Feature, kann aber bereits von Dir verwendet werden. Wenn Du wissen willst, was die Resource API ist, welches Problem sie lösen kann, wofür man sie nutzen sollte und wofür nicht, dann bist Du hier genau richtig. Dieser Artikel ist Teil des Angular Guides, in dem wir bereits viele spannende Themen zu Angular erforschen.  Der Guide gibt dir einen Überblick über aktuelle Themen, angefangen mit: Was sind eigentlich Signals und welche Vorteile bringen Sie mit?

Wir führen unser Reise durch die signal-basierten Features von Angular mit einem Einblick in die neuen Funktionen der Resource API fort. Im diesem ersten Teil betrachten wir die Grundlagen von resource() und rxResource(). Im zweiten Teil experimetieren wir mit der neueren httpResource(), womit man HTTP-Requests erleichtert und diese direkt als Signal ausgeben kann.

Was ist die neue Resource API?

Bisher haben sich Signals in Angular nur auf den synchronen Datenfluss konzentriert. Zustände abspeichern, Inputs, Queries, etc. Mit dem neuen Angular Update sollen asynchrone Operationen in Signals integriert werden. Der erste Schritt in diese Richtung wird mit der Resource API getestet. Eine Resource ist eine asynchrone Dependency, die mit Signals integriert wird. Man kann sich eine Resource so vorstellen, dass sie aus drei Teilen besteht:

  1. Eine params Funktion, welche die Abhängigkeit der Resource von einem oder mehreren Signals definiert. Hier lädt die Resource automatisch neu wenn sich this.page() ändert
  2. Ein loader/stream der eine asynchrone Operation durchführt, wenn sich die Anfrage ändert, und einen neuen Wert zurückgibt. Zusammen mit der Params-Funktion werden hier also jedesmal neu die Produktdaten aufgerufen, wenn sich die Seitenzahl ändert.
  3. Die resultierende Instanz der Resource, die selber verschiedene Signals bereitstellt, enthält den Wert und den Status der Resource. Der Wert wird dabei asynchron mitgeteilt, also erst sobald dieser verfügbar ist. Der Status einer Resource kann loading, resolved, errored, … sein.

Das komplette Beispiel kannst du unten in unserem StackBlitz Projekt ausprobieren. Mehr zur Resource API kannst du auch in der offiziellen Angular Dokumentation finden.

resource() vs rxResource() vs httpResource()

Die Resource API bietet drei Methoden an. Die drei Methoden haben eine ähnliche Funktionsweise aber unterschiedliche Anwendungsfälle.

resource() ist die “Basic” Variante der drei Methoden und arbeitet mit Promises. Du solltest diese Methode benutzen, wenn du Javascript fetch bevorzugst um Daten abzurufen.

rxResource() ist die “Reactive” Variante. Sie benutzt Oberservables. Du solltest diese Methode benutzen, wenn du bereits mit RxJS arbeitest oder RxJS bevorzugst. Du kannst sie auch verwenden, wenn du das Ergebnis durch Oberservable Operators pipen willst. Da der HttpClient von Angular Observable-basiert ist, bietet sich hier die rxResource() an.

httpResource() ist die einfachste und flexibelste Variante. Mit einfacher Syntax kann man eine HTTP Request mit URL und optionalen Parameter stellen und sogar ein Request-Objekt definieren. Über httpResource() soll es auch im zweiten Teil dieses Artikels nochmal genauer gehen.

Angular Schulungen

Welches Problem löst die Resource API?

Bisher mussten asynchrone Daten (z.B. HTTP-Requests) in Angular über RxJS Observables verarbeitet werden – inklusive manuellem subscribe und unsubscribe. Für die UI-Aktualisierung war dabei zone.js verantwortlich, was bei komplexen Apps oft zu Performance-Problemen führte.

Mit Signals wurde die reaktive Zustandsverwaltung deutlich effizienter, aber es fehlte eine elegante Möglichkeit, asynchrone Operationen, wie API-Calls, direkt in Signals zu integrieren. Entwickler mussten Workarounds wie toSignals() oder manuelle Promises nutzen, was umständlich und fehleranfällig war.

Die Resource-API schließt die Lücke, indem sie asynchrone Daten direkt als Signals bereitstellt – ohne subscribe und zone.js:

Außerdem ermöglicht die Resource API auch abbrechbare Anfragen – besonders nützlich bei GET-Requests. Wenn ein Nutzer schnell zwischen Seiten wechselt, werden veraltete Requests automatisch abgebrochen.

Die Resource API ist nützlich wenn Du asynchrone Daten empfangen willst. Sie hilft dabei, die Daten direkt in ein Signal umzuwandeln, damit Du sofort damit arbeiten kannst ohne einen großen Workaround. Außerdem erlaubt Resource das Unterbrechen von Requests. Resource erlaubt ein abortSignal, womit man Requests schnell unterbrechen kann und stattdessen eine andere Request bearbeiten kann. Sollte der Nutzer also aus irgendwelchen Gründen mal mehrere Requests schnell hintereinander stellen, indem er beispielsweise schnell auf verschiedene Buttons drückt, dann unterbricht Resource diese Requests und leitet nur die Neuste weiter. Dies macht die Anwendung effizienter. Einer Sache muss man sich hier aber bewusst sein, dadurch, dass man Requests unterbrechen kann, könnten Daten verloren gehen, wenn Resource mit POST-Request Operationen benutzt wird.

Deshalb solltest Du Resource nur für GET-Requests benutzen, also um Daten in Signals zu laden. Du solltest Resource nicht für POST-Requests benutzen, um Daten zu senden.

Beispiel: resource()

Hier ist ein Teil aus unserem StackBlitz Beispiel. In diesem Beispiel wird die DummyJson Seite gefetched und daraus Daten geladen. Es wird ein Objekt an resource() übergeben. Das Objekt hat die params und loader Funktion, wie oben erklärt, und außerdem auch ein abortSignal.

Das abortSignal bricht hier die Request über einen AbortController ab, wenn eine neue Seite geladen werden soll, während eine andere am laden ist. Das kannst du selber ausprobieren, indem Du den Network-Tab in den Inspector-Tools im StackBlitz-Projekt öffnest und dann sehr schnell auf “Next” drückst. Hier siehst Du wie bei Requests der Status “(cancelled)” erscheint. Dafür ist das abortSignal verantwortlich. Durch das Unterbrechen der Anfragen werden weniger Netzwerk-Ressourcen verwendet, was bei größeren Websiten ziemlich nützlich sein kann.

Eine Resource besitz noch weitere Eigenschaften wie value, status, isLoading, error, etc. mehr Details zu einer Resource kannst Du hier nachschauen. Über products.value() wird in unserem Beispiel der Wert der geholten Json abgefragt.

Dadurch wird die Liste gebildet mit der die verschiedenen Werte der Produkte aus DummyJson angezeigt werden.

Hier ist der komplette Code zu dem Beispiel von resource(). Wie bereits erwähnt kannst Du diesen auch wieder im StackBlitz-Projekt bearbeiten und damit experimentieren. In der Dokumentation findest du noch mehr Details zum Umgang mit resource().

Beispiel: rxResource

Dieses rxResource() Beispiel ist sehr ähnlich zu dem Vorherigen. Statt resource()  wird nun aber rxResource() verwendet, was es erlaubt den HttpClient ziemlich einfach zu verwenden. Dafür wird der HttpClient zuerst injected.

Im loader, welcher seit Angular v20 für rxResource() stream heißt, wird nun eine Url aufgerufen und dabei ein Observable zurückgegeben.

rxResource() subscribed und unsubscribed auf dem Observable automatisch. Auch anders als bei resource(): Es wird kein abortSignal benötigt, da rxResource() auch das Abbrechen von GET-Requests automatisch übernimmt. Du kannst das auch wieder testen, indem Du bei dem rxResource() Beispiel im StackBlitz-Projekt wieder schnell auf “Next” drückst und im Network-Tab nachschaust was passiert. Auch ohne ein abortSignal wird hier für die GET-Requests der Status “(cancelled)” angezeigt.

Da wir RxJs verwenden, haben wir mit rxResource() außerdem auch Zugriff auf die pipe() Funktion, womit wir die erhaltenen Daten, wie bei RxJS gewohnt, transformieren können.

Hier ist der komplette Code zum rxResource() Teil des StackBlitz-Projekts. Und auch hier natürlich der Link zur Dokumentation.

Erfahrung ist der beste Lehrer: Hands-On für die Resource API

Bist Du bereit, die Theorie in die Praxis umzusetzen? In diesem interaktiven StackBlitz-Beispiel befindet sich die vorgestellte Beispielanwendung, die die Grundkonzepte von Resource aufgreift und die vorgestellten Beispiele und Funktionen beinhaltet.

Und jetzt?

Wie schon angekündigt, soll es in Teil 2 dann um die httpResource() gehen. Wir zeigen Dir wo die Unterschiede zu resource() und rxResource() liegen und wie Du httpResource() am besten nutzen kannst.

Terminübersicht der nächsten Angular Schulungen

theCodeCampus Autor Marc Dommröse

Marc Dommröse
Developer at thecodecampus </>

My name is Marc. I'm currently studying Computer Science at university, with one of my favorite topics being frontend development.


Leave a Reply

Add code to your comment in Markdown syntax.
Like this:
`inline example`

```
code block
example
```

Your email address will not be published.