Hi. Everything you have to know, about the brand new resource() function, in Angular 19, you can find, in this video. In this tutorial we will build from scratch a little Angular app, where you will be able, to load data from the server.
You will be able to reload it, or change it afterwards by adding a new user to the list, or clear the list up. Besides that we will Implement a user search feature, where I will demonstrate how you can handle concurrency requests, and cancel the pending request when the new one arrives. And of course, while the data is being loaded, user will see a progress bar making the user experience much better.
And this everything we will achieve only by using the resource function and we will not write any single line of RxJS code. Sometimes you might feel that things are working like magic, but no worries, I will be diving into the source code and demystify things that might not be obvious for you. If it is a first time on my channel and you like deep dives into Angular my name is Dmytro Mezhenskyi and on my channel you can find a lot of advanced and unique Angular tutorials, that you can check out later, but now let's try to learn more about this new reactive primitive called resource().
First of all, let's try to figure out why this resource() function exist. Right after signals were introduced in Angular, a few things became very clear immediately. Signals are reactive primitives that will be used by the Angular core making their dependency on RxJS optional.
Another thing that we realized about Angular signals quite quickly, is that they're very good for synchronous reactivity, but when it comes to asynchronous code they perform not so well, and RxJS much better in those cases. And this was actually a problem in making RxJS fully optional, because we cannot simply avoid the asynchronous code, but at the same time, we don't have any signal based alternative that would nicely work with asynchronous code and could handle the most popular use cases. So that we could include RxJS only when its power is justified.
And this new reactive primitive resource(), supposed to fill this gap. So let's have a look how it looks in practice. Before we get started, I just wanted to mention that everything you will see in this video is related to Angular 19, so make sure that you updated your project to this exact version and once you have done it, you will be able to import the brand new function called resource() from the 'angular/core'.
Please also keep in mind that, in Angular 19 the resource() function, is in developer preview mode, which means, that it is not ready for production. It might change in the future, and it was exposed just to let you play with it, and provide feedback to Angular core Team. All right, so let's go and create our first resource() and I'm going to name it 'users' resource() and the resource() function itself requires a certain configuration object.
And there you can see a bunch of properties that you can configure, there is only one required, called loader, so let's implement it first. And the loader is a function that's supposed to asynchronously load the data into this 'users' resource(). And this function should return a promise, or if to be more precise it has to be something PromiseLike.
So it means that, it should not be necessary a promise, but it should be something that has an API, similar to what promise has. I will be using a normal promise that will be returned by the calling the fetch() function. Fetch() function it is the, part of the web platform API, and it allows me to perform http calls to a certain server endpoint.
And then the data, the endpoint returns, I can resolve by calling the json() method, and then the data will be available for further usage. Alternatively you can also use the 'async/await' syntax, it is absolutely okay. Just choose whatever style you like more.
I personally prefer this 'async/await' syntax, because I find it more cleaner. But whatever syntax you choose, if you look up into Chrome Dev Tools inside the network tab, you will see that the call to the users's endpoint has been executed. Which proves that the loader() function of the user resource() has been invoked.
But how can we read the data returned by the resource() loader? For that we have to take a closer look at what resource() function returns. And it returns a special data structure called ResourceRef.
And you can think of it, as a representation of the current state of a certain source, and also besides the reading the state, it provides you with a certain API, that allows you to manipulate this state and a little bit later I will show you how to do that, but so far let's try to read the current value from the user's resource(). And I'm going to do that inside the component template, there I have a dedicated list and here I'm going to use the 'For Loop' and iterate through the 'users' source values, right. So there will be the user that server returns, and I'm going to track them by using userID which is not highlighted by the way, because we don't have strict typing so far, for our source, so let's use this chance to improve it, and actually the type of resource() function is a generic that has two values.
The first value this is what resource loader returns. And in my case it is array of users, and the second parameter it is the request type. We will come to request feature a little bit later, so far let's define it as a unknown type.
All right so now typings for our 'users resource' are much stricter. And we can get back to the component template and now you can see that the available users properties are shown up, and if we make any mistake, and try to access the property that doesn't exist, we will get the compilation error. Which is actually cool.
And now inside the 'for' block I can already define a new <li> element and there let's display maybe username. Here we go. And also the no data <li> element let's show, when the users value is empty.
And there is nothing to show. And now if I save my change, and reload the application, you can see the list of users, I get from the server is rendered right on the page. But what if something goes wrong and we encounter an error during the loader() function call?
How we can handle the error use case inside the resource()? And actually it is pretty easy to do, because the ResourceRef provides a dedicated property called 'error' that contains an error, if it happens inside the loader() function, or it is undefined if everything went well. So to notify user about the error, we can go to the component template, and somewhere here, I can create dedicated block that will be visible if our users's resource() contains the error.
And there inside I'm going to display what exactly went wrong. And to test this scenario we can scroll a little bit down, and let's try maybe remove entirely the endpoint URL from the fetch() function. And in such a way, we can explicitly trigger the error.
So you can see that the error message appeared right there, exactly as I expected. And by the way, since the usage of the fetch() function in Angular becomes kind of usual thing, you have to keep in mind one important pitfall, when it comes to error catching. For example let's try to simulate the use case, when we call the endpoint that doesn't exist.
So if we look up into the console, you can see that the request failed with the status code 404, but we don't see the corresponding error message. The thing is that when the server responses with the status code like 404 or 500 the fetch function doesn't consider it as an error. So the promise returned by the fetch() function, will not be rejected.
And this is the reason why we don't see the error message there. To change this behavior you can explicitly check if the server response is not okay, in this case you simply throw an error with the corresponding message. So now if I reload the application you can see that the error message has appeared, because server responded with the status 404.
So let's very quickly revert this change, and use the real API URL, and let's move forward. And the next thing I would like to discuss with you, are resource statuses. The ResourceRef has a corresponding signal() called status, and let's try to subscribe to the changes of this signal() by using the effect() function.
And simply console. log() the values of it. So if you save this change, and open the Chrome Dev tools and go to the console tab, you can see resource statuses console.
loged and they are represented by some magical numbers. Each of these numbers represent a certain resource state like loading, reloading, resolved etc. And we can easily decode those numbers, by using a dedicated enum, called ResourceStatuses.
That you can again import from the 'angular/core' package. This enum provides all the possible resource statuses, so you can use it in your code in order to react to certain ResourceStatus change and reflect this, on the UI. For example you might create a computed property, where you just track the changes inside the resource status, and check if it is in loading state, or not.
However you should not do this for exactly loading status, because resourceRef out of the box comes with the property isLoading(), that handles exactly this use case for you, and if you have a look at the source code, and exact implementation of it, you can see that this is still the same computed(), that checks if the status is 'in loading' or 'reloading' state. So I don't need this computed() I created, and I can use isLoading() property, so I can go to component template and show some spinner or progress bar in my template and for that, I will be using the Angular Material progress-bar component, that I have to import and somewhere, somewhere here, I can create a dedicated 'if' block, where I will display the progress-bar component in case the source, the user source, is in the loading status. All right, now let's try to save our change and test if everything works.
So I'm going to reload my page, and you probably you could see the progress-bar appeared, but it happened so fast, so that's why let's open their Dev tools and try to simulate the very slow 3G network, and yeah, you could see that the progress bar was visible for a second, and then when the data was resolved, it disappeared so everything works as we expect. And now let's talk how we can manipulate the state of the resource() and what API do we have for that. First of all, we can reload our resource(), meaning that we can retrigger the loader() function and grab the latest data from the server.
It is pretty easy to do that, because the ResourceRef has a dedicated reload() method that you can call anytime, for example I have here a dedicated button reload, so I can add the click event listener to this button, and when user clicks it we can reload the resource. So now if I save my change, and try to click the reload button, you can see that my resource was reloaded, and you could see the dedicated progress-bar here at the top. We can also change the value of the resource locally at any time, and we have two options to do that.
We can set a new value based on the previous value of the resource, or we can set the new value directly. So let's have a look at them one by one. For example let's imagine that in addition to already fetched users from the server, I want to add a new one in the beginning of this list.
So in this case I would need to add another click event handler to the add user button, and the handler of it will be addUser() method. Here you can already see prepared dummy user that I'm going to add to this list, and we can add this user by using the update() method that works the same way as with normal WritableSignal(), there you have a callback, where you take as argument the previous value of the signal, or resource. And from there you return the new state, the new value for this signal, and in my case I have to also check if the previous value is not undefined, because it could be undefined, right.
And if it is the case then we return just simply array with this new user, and this is pretty much it. So we can try to click the add user button, and we see that the new user has been added in the beginning of the user list. And as I said before, we can also set the new value for the resource directly, and for that we are going to use a dedicated set() method, that again works absolutely the same as for any WriteableSignal, so when we call the clear button, let's say that we set value to the empty array, and in such a way we clear the list completely.
And now if I try to click the clear button, you can see that all users has been removed from the list. And this is cool and I personally find this pretty impressive what we learned so far, even though we didn't cover everything yet, so let's continue continue and let's have a look what other API the resource function provides. And how it can help us to implement feature like user search, so that when user types anything into the search field, we should request server with the right searching criteria, and get back users, name of which ones starts with the search string.
For that, we would need to create another signal() inside our user-search component, and the value of it will be an empty string by default. Also we have to bind this signal() with the corresponding search-input and for that let's go to the component template, find this input and there I'm going to attach the input event listener, and once user enters a new value, we will take it from the event. target and set as a new value, for the corresponding query signal().
You can see currently an issue with typings and I'm going to fix it the way you should never use in your production code, and I'm going to cast it to any, inside template, just to avoid creating a separate method, only for target type casting. I hope you will forgive me my laziness. Anyway now the question is how we can wire up this new query signal() with our users's resource.
Because if you try to use the query signal() directly inside the loader() function it will not work. And the loader() function will not be re-triggered every time when query signal() changes. And to solve this issue resource has another property called 'request'.
Where we define a function that returns a signal() or group of signals() changes of which one will call the re-execution of the loader() functions, and their new values will be provided to the loader() function as an argument. So you can destructure the loader config, and take the property request from there, that contains the value the request function returns. And then you can use it anywhere inside your loader() function.
And if we save this change, and try to type any string into the user search, you can see that every time the search query changes, we re-execute the HTTP call, with a proper name like parameter, and get the proper values from backend. If your loader() function depends on values from multiple signals(), then you can return from the request() function, not a single signal(), but you can return an object of signals(). So in my case it could be an object that has property 'query' and the value of it is a query signal().
And then I could access this query, by using again the request object, and they're just using the query key. Again, you can see some typings issues this is because earlier in this video we defined the request type as an unknown, but now we know what the type is, and this is the object with a key 'query' and the value type of string. So we can define it here, and the error has disappeared.
All right now let's talk about concurrency request. For example what will happen if I fire a new HTTP call, while the previous one is pending? And as you can see by default, all those requests will be executed, which might remind you the behavior of the RxJS operator called mergeMap().
This however might not be the behavior you expect. And you would like to cancel the pending request when the new one arrives, and in this case you have to utilize a thing, called abortSignal(). That you can destructure from the loader() function argument, and use it in order to abort asynchronous operations like the fetch() function call.
You simply have to provide an additional config for it, and there for the parameter signal() you provide the AbortSignal. And after that, when you save this change, and try to perform multiple HTTP calls in a row, you can see that the pending request has been cancelled, and completely executed only the latest request. Which is actually very similar to the behavior of the switchMap() RxJS operator.
I'm pretty sure that for many of you, this everything looks like magic, and it brings a lot of confusion, like 'What this AbortSignal is? How it prevents the fetch call etc? '.
So let me take another couple of minutes, to demystify all this things for you. The first thing you have to understand, is that the AbortSignal as well as the signal() property in the fetch() function config. They have nothing to do with Angular signals().
This is completely different concept. The AbortSignal allows you to abort execution of asynchronous operations in JavaScript. And it is a part of AbortController class, that is built-in into JavaScript, so you can instantiate your own instance, of the AbortController, and the AbortSignal from this class instance, you can provide instead of the AbortSignal I received in the reload() function.
And whenever I call the abort() method of my custom AbortController, it will notify the fetch() function to cancel these asynchronous operations. We could even wrap this abort() method call in some setTimeout() and call it after, I don't know 500 milliseconds, and define the reason that, the request takes too much time, a bit silly example, yeah. But it demonstrates the idea how it works.
So now if the request takes more than 500 milliseconds, then we will see an error, because after 500 milliseconds, the abort() method involved, and it triggers the AbortSignal, that eventually cancels the HTTP request. So as you can see there is no magic here at all. And under the hood of the resource() function happens pretty much the same thing, and we can make sure it by diving into the source code of the resource() function.
All right, so this is the source code of the resource() function and what it does, it returns a new instance of the WritableResourceImplementation class, which is right here, and you can see it has a private property called pendingController, that's supposed to be an instance of the AbortController. And here's a method called loadEffect() and this is the method that actually involves our loader() function, right. And somewhere here, there is new instance of the AbortController is created, and from there, they structured the signal() property.
Renamed to the AbortSignal and it is provided as an argument for the loader() function. This is exactly this function and this is exactly that AbortSignal and then, at some point, the abort() method of the AbortController is called which fires the AbortSignal. We can, by the way, have a look when it actually happens.
So let's try to find where the abort() is called, so it is inside, okay, this is the private method that actually calls the abort() method, and we can have a look at which places it was called. So the first place this is on local value, and this method is executed when we locally update the value of the resource. For example when we call set() method or update(), so in this case the AbortSignal will be fired, then it happens when the writable resource is destroyed.
Which is pretty obvious. And then it happens also you can see, in the beginning of the calling loadEffect() method, and exactly this causes this switchMap() effect when we use the AbortSignal with our fetch() function. You might be also curious 'why do we get an error when we abort the request by using our custom AbortController and why doesn't happen when we use the AbortController that we destructure from the loader() function?
'. And this is because under the hood the function is called inside a try/catch block, and when the error goes to the catch block. Here happens the check if the operation caused by abortion, then happens simple return, and we simply do not reach this step, when the error status is setup, and by the way, this is something you could Implement in your custom abortion logic.
If you need it of course. But I must also say that I'm not sure that this will be the recommended way to implement the custom abortions logic. It is just too early state to say something certain, maybe in the future we will see a dedicated API, I don't know, I did it just to demonstrate what is hidden behind the AbortSignal, so it doesn't look like a magic for you.
And if you don't mind I will just revert things back, a little bit. So far this was everything I would like to mention about the resource() function, and please remember that this is still an experimental feature. And I think it's just the beginning of the new entire massive Angular chapter, and later we will see more features and more patterns built on top of this reactive primitive.
But maybe you have different opinion, so let's discuss it in the comment section below, or you can join our cozy Discord community of more than 1,000 Angular developers, around the world. And we are looking forward meeting exactly you, as well. If you like the way how I explain stuff by diving deep into the Angular source code, and if you would like to support the release of new such videos, right here, you can see all available options how you could do that, and whatever option you choose I am so grateful for that, and I appreciate your support a lot.
