Auteur: Danny Holstein

Een aantal maanden geleden, namelijk op 19 november 2024, was de major release van Angular 19. In de tussentijd zijn er twee minor releases geweest voor versie 19.1 en 19.2. In dit nieuwe blogbericht worden de nieuwe experimentele Resource en HttpResource API’s nader behandeld.

Sinds Angular 5 wordt er gebruik gemaakt van de HttpClient en dit is een gebruiksvriendelijke API rondom het zogenaamde XMLHttpRequest object dat onderdeel is van alle moderne browsers. De HttpClient is nauw verbonden met Observables die asynchrone verzoeken naar een Webserver afhandelen. De term asynchroon wil zeggen dat de applicatie blijft doorwerken terwijl de browser wacht op de respons van de Webserver. De HttpClient is geschikt om in productiemodus te gebruiken en voldoet aan de meeste gebruikerszaken.

De vraag rijst op: Waarom zijn er in Angular twee nieuwe API’s nodig voor HTTP-requests terwijl er al een uitstekende API hiervoor is? Een mogelijk antwoord op deze vraag is dat voor het gebruik van Observables het pakket RxJS (Reactive Extensions for JavaScript) nodig is. Niet alleen de HttpClient, maar ook veel andere onderdelen van het Angular framework zijn nauw met RxJS verbonden. Een nadeel is dat de leercurve van het Angular framework en RxJS redelijk steil is. Om nieuwe ontwikkelaars of ontwikkelaars die met andere JavaScript-frameworks werken tegemoet te komen, zijn de twee nieuwe  experimentele API’s geïntroduceerd.

Een ander nadeel van de reguliere HttpClient en het gebruik van Observables kan de hoeveelheid code zijn. Dit geldt voor zowel de services die gebruik maken van de HttpClient als in de componenten waar vaak gebruikt gemaakt wordt van de subscribe() methode en zijn callbacks. De subscribe() methode is nodig, want Observables zijn niet alleen asynchroon maar ook ‘lazy’ wat wil zeggen dat Observables niets doen totdat de subscribe() methode hierop wordt aangeroepen.

Op Internet zijn er veel voorbeelden te vinden van de reguliere HttpClient en hoe dit samenwerkt met Observables. Zelf heb ik geëxperimenteerd met de nieuwe Resource en HttpResource API’s. De bevindingen hiervan zijn in het schema hieronder te vinden waar de verschillen en overeenkomsten worden getoond.

Het Angular development team heeft in versie 19 een nieuwe experimentele Resource API geïntroduceerd. Dit is ontworpen om asynchrone operaties af te handelen. De Resource API heeft ingebouwde mechanismen om race-conditions te voorkomen en dit laatste wil zeggen dat twee processen niet tegelijkertijd toegang hebben tot dezelfde resource. De Resource API houdt de loading-state bij, handelt fouten af en kan opgehaalde waardes automatisch updaten wanneer dat nodig is.

De ruggengraat van de Resource API is de resource() functie waarmee op een asynchrone manier een HTTP-request kan worden gemaakt naar een Webserver. De Resource API bevindt zich in het pakket @angular/core en maakt gebruikt van JavaScript Promises en Angular Signals. Een Promise kan net zoals een Observable omgaan met asynchrone data, maar een Promise heeft alleen twee callback-methoden, namelijk: resolve en reject. Een Observable heeft daarentegen meer callback-methoden (een Observer-object met next, error en complete), kan data transformeren met operatoren en kan nog voor completering geannuleerd worden. Dit laatste is met Promises niet mogelijk.

Wanneer het doorgegeven argument aan de resource functie undefined is dan zal er geen data geladen worden. In de voorbeeldcode hieronder is dat het geval wanneer er niet aan de voorwaarden is voldaan van het if-statement. Tijdens het experimenteren is er veel gebruik gemaakt van generics om de hoeveelheid herhalende code te verminderen. Voor de resource() functie is de request parameter optioneel, maar is de loader parameter verplicht. De request parameter accepteert een Signal (zoals: WritableSignal en InputSignal, maar ook ComputedSignal is toegestaan) als waarde.

De code hierboven toont verder in de loader het gebruik van de JavaScript keywords async en await. Binnen de loader wordt de asynchrone operatie uitgevoerd. De JavaScript fetch() functie geeft een Promise terug. De Resource API biedt ook een kant-en-klare abortSignal, waarmee een vorig HTTP-request geannuleerd kan worden. Dit komt onder andere van pas bij auto-complete functies, waarbij het niet de bedoeling is dat de Webserver wordt overladen met HTTP-requests. Sinds Angular 19.2 kan er ook een standaardwaarde worden gedefinieerd voor de resource met de defaultValue parameter.

De resource() functie heeft ook andere Signals waarmee toegang verkregen kan worden tot de teruggegeven data, de status of een fout. Ook biedt de resource() functie toegang tot hulp-methoden zoals hasValue(), reload() en destroy(), respectievelijk om na te gaan of de resource een geldige waarde heeft, de resource opnieuw te laden of de resource te vernietigen. Zie de voorbeeldcode hieronder waar opnieuw gebruik is gemaakt van generics.

Op dit moment kan de Resource API de HttpClient niet vervangen want de Resource API is niet alleen experimenteel, maar ook alleen geschikt voor GET-requests. Als experiment heb ik toch gebruik gemaakt van POST, UPDATE en DELETE requests – waarbij er extra code moet worden toegevoegd aan de loader parameter en een extra object meegegeven moet worden aan de JavaScript fetch() functie.

Naast de Resource API is er ook de rxResource API die gebaseerd is op RxJS. Beide API’s hebben dezelfde methoden en Signals. Het verschil is dat rxResource een Observable teruggeeft in plaats van een Promise. Maar het doel van de Resource API is juist om het gebruik van RxJS te vermijden, dus: waarom zou je de rxResource API gebruiken als RxJS niet gebruikt wordt in een project? Mogelijk wil het Angular development team een mogelijkheid bieden aan ontwikkelaars om de code declaratief en reactief te schrijven, dat met de rxResource API mogelijk is.

In Angular 19.2 is een tweede experimentele API toegevoegd om HTTP-requests te maken. Deze HttpResource API maakt gebruik van de HttpClient en Signals uit het Angular framework. Deze API introduceert een meer declaratieve en reactieve benadering om HTTP-requests te beheren. Een httpResource zal reageren op veranderingen van een Signal en de data automatisch updaten – dit laatste in tegenstelling tot het gebruik van de HttpClient in combinatie met Observables waarbij iedere keer handmatig de methoden aangeroepen moeten worden (zoals: get(), post(), put(), delete(), etc.).

Het voordeel en doel van de HttpResource API is dat code wordt versimpeld, state-mangement beter bijgehouden kan worden en er niet meer code nodig is om de data te verversen. Hoewel deze feature nog steeds experimenteel is, belooft het een grote verbetering te zijn wat betreft het maken en afhandelen van asynchrone operaties in Angular applicaties. Onder de motorkap gebruikt de httpResource() functie nog steeds de HttpClient en de gebruikelijke interceptors, test-utilities, etc.

De HttpResource API is gebouwd bovenop de Resource API en heeft dezelfde Signals en methoden. Het verschil is dat er een HttpResourceRef wordt teruggegeven in plaats van een ResourceRef (zie voorbeeldcode uit vorige paragraaf). Een ander verschil is dat de HttpResource API een aantal extra Signals heeft die specifiek zijn aan deze API, zoals de Signals: statusCode, headers en progress. De Signal statusCode bevat de code van de response (zoals 200 voor OK, 404 voor niet gevonden, 500 voor interne serverfout, etc.). Met headers Signal kunnen de HttpHeaders worden opgevraagd van de respons en met de progress Signal kan de voortgang van een download proces worden opgevraagd.

In tegenstelling tot de Resource API zijn met de HttpResource API wel alle HTTP-requests mogelijk. Net zoals bij de Resource API kan er binnen de httpResource() functie gebruik gemaakt worden van undefined om het laden over te slaan. Voor POST en PUT requests kan er een body worden verzonden met het verzoek. Ook kan er een standaardwaarde worden gedefinieerd voor de httpResource met de defaultValue parameter. Tijdens het experimenteren met deze nieuwe HttpResource API is er opnieuw gebruik gemaakt van generics om de hoeveelheid code te verminderen. Het viel mij op dat er nog minder code nodig is voor asynchrone HTTP-requests.

Het is wel belangrijk om te benadrukken dat de HttpResource API experimenteel is en nog niet geschikt is om in productie-modus te gebruiken. Bovendien is binnen deze API nog veel RFC – dat wil zeggen: ready-for-comment voor andere ontwikkelaars. In volgende versies van Angular zal deze API naar alle waarschijnlijkheid verder evolueren.

Het is waarschijnlijk dat het gebruik van RxJS in de toekomst optioneel zal zijn, net zoals dat nu bij het gebruik Zone.js het geval is. Het vervangen van RxJS kan echter wel moeilijk worden, want RxJS is een veelzijdige library die veel gebruikerszaken kan oplossen. Anderzijds kan RxJS complex zijn voor beginners en te veel van het goede zijn bij eenvoudige gebruikerszaken. Het gebruik van Signals kan in zulke gevallen makkelijker zijn.

De twee nieuwe en experimentele resource en HttpResource API’s zijn hier een eerste aanzet toe. Het doel van het Angular development team is om de hoeveelheid RxJS code verminderen dat binnen Angular wordt gebruikt. Of in ieder geval is het doel om zaken simpeler te maken zonder het gebruik van (complexere) RxJS code.

In plaats van het gebruik van de HttpClient met Observables (uit RxJS) kan er in de toekomst gebruik gemaakt worden van:

1) Promises en Signals door de Resource API te gebruiken.

Of:

2) De HttpClient en Signals door de HttpResource API te gebruiken.

Naar mijn mening wordt met de Resource API een stap teruggezet in de tijd, want Angular maakte in de eerste plaats geen tot weinig gebruik van Promises maar juist veel gebruik van Observables. De HttpResource API sluit beter aan op de codeerpraktijken die binnen Angular al gangbaar waren en heeft mijn voorkeur.