Thank you so much for your amazing videos and for explaining everything so clearly. You're making such a big difference in the Angular community thank you again ❤
I don't understand the renaming part, loader: ({ request: productId }) => To me that looks like you are destructuring a property request of type productId. Can someone explain how this ends up with a parameter named productId?
Thats a great addition. Now we just need some way to debounce signals, i don't want to spam the server with requests while the user is typing in the search field. Currently i'm using an rxjs observable with debounce and toSignal for this, but would be great if there was a signal only solution
One of the team's goals is to make RxJS optional, so I would guess the opposite: that they work toward making resource/fetch more full featured so we wouldn't need HttpClient.
Interesting (and high quality as always). I couldn't quite work out how I might use this for infinite scroll. Also interesting that they seem to be first classing fetch? I only really use HttpClient for interceptors so that would be nice if it went.
In some cases, yes. Especially those cases where combineLatest was used to handle multiple query parameters. In other cases, there may still be use for combineLatest, such as when handling events from multiple sources (keypress and mouse move for example).
We'd still use HTTPClient (or fetch), so that would be the same. We just wouldn't need to return the result as a signal, so it wouldn't need to be wrapped in a resource.
Great video as always. With signals and rxResource API and zoneless, can we conclude that RxJs is no longer needed and also component lifecycle hooks are no longer needed? Thanks for your feedback.
Thanks, teacher Deborah! This is the video I was waiting this week. Now that we have Resource Api, Angular (TanStack) query and SignalStore, what do you think will be the recommended way to easily manage server state (loading, error, success)? Do you think Resource api for server state and SignalStore for local state is a good combination? What do you think could be the best architecture for enterprise applications in modern Angular? Share your GDE thoughts with padawans. 🤩
Thank you for watching! I think resource/rxResource are still too new to make architectural recommendations. It will take some time for people to try it out. But I agree that resource/rxResource + SignalStore seem like a good combination.
Thanks! Do you have a code snippet of your combineLatest so I have a clear idea of your objective? I used to use combineLatest to do something with a retained observable when another observable changes. If these are all signals instead, the linkedSignal() can often do the same job. It depends on your specific scenario.
@@deborah_kurata I meant that if I can use Resource or RxResource to handle multiple http request. It seems that it can only handle one request with loader function in Resource or RxResource. To handle multiple request, it seems that we still can not avoid to use combineLatest. I asked Grok AI. It gave me the answer. `import { inject, Injectable } from '@angular/core'; import { resource } from '@angular/core'; import { HttpClient } from '@angular/common/http'; @Injectable({ providedIn: 'root' }) export class MultiResourceService { private http = inject(HttpClient); combinedResource = resource({ loader: async () => { const [users, products] = await Promise.all([ this.http.get('url1').toPromise(), this.http.get('url2').toPromise() ]); return { users, products }; } }); }` or another way `private http = inject(HttpClient); usersResource = rxResource({ loader: () => this.http.get('url1') }); productsResource = rxResource({ loader: () => this.http.get('url2') }); combinedResource = combineLatest([this.usersResource.result$, this.productsResource.result$]).pipe( map(([users, products]) => ({ users, products })) ); combinedResource.subscribe(result => { console.log(result.users, result.products); });`
Hi, Deborah! Love your educational content. We've refactored our old Angular 8 codebase to fully reactive Angular 18 thanks to your videos on signals and home-made signal store. I have a concern about writing the resource locally. It's purely vibes, I don't have data to support it, but doesn't writing to resource locally go against reactivity or declarativity?
A v8 -> v18 Wow! That was a big move. Congrats! When you say "writing to resource locally", are you referring to directly updating the signal returned from the server? Since these features are so new, I haven't tried them yet in a "full featured" application, but I envision that they would be incorporated into the service, so the component would not update it directly. Also, many of us are still waiting for the "signal forms" features to see how that affects the flow.
@@deborah_kurata Yes, that's exactly what I meant. Keeping it in the service didn't cross my mind, it sounds better now. Thanks! I know it's not a proper forms API, but as long as the inputs are somewhat simple, we can use native template binding with on input with [(value)] bound to a signal, and it's pretty reactive. At my work, the UI team for now made the input library compatible with Reactive Forms, template-driven forms and the new model signal binding without FormsModule at all. It looks rather messy, so can't wait for the proper signal forms.
Thank you for watching! Error handling is definitely a topic I want to drill into a bit more. The resource has an error property, but it only seems to be set when the connection is dropped during the async request. For other errors (like 404), the resource error property isn't set because the server responds (even though that response is an error condition). I have on my list to do a video specifically about error handling with resource and rxResource. Thanks again!
Hi there, thanks for the video, clear explanation, straight to the point example, lovely! I heard you mention that resource() is only for GET requests. Any tips on how to deal with POST/PUT/PATCH/DELETE? Asking because loading indicators and error handling are often desired for the entire spectrum of HTTP verbs.
Thank you for the kind words about the video! resource/rxResource don't do much to help with HTTP errors, so you still need to handle those for any HTTP verb. (An HTTP request that returns an error code does NOT set the resource error property.) Regarding the loading indicators, what's being loaded for a POST/PUT/PATCH/DELETE? How are you doing that now?
@@deborah_kurata Hah, yeah they're following fetch() with regards to error status codes. For POST/PUT/PATCH/DELETE, I'm now manually setting variables like this.isAddingProduct = true; before I fire off the request. But that gets tedious, especially because formally those booleans states should ideally be unit tested. Would be great if this were to get standardized a bit more.
Thank you for watching! Personally, I'm a big fan of Observables and still really like having the Observable pipeline available for things such as debouncing, filtering, etc. (Though my simple example here didn't cover any of those more advanced scenarios.) At least for now, I plan to use rxResource. But there many developers that prefer a Promise-based approach and now they have the option.
Great video and really good explaination as always :) But i have some concerns about this feature: Do we need both rxResource and Resource? Maybe Angular team can make it to accept Observable or Promise as the api call? How about debouncing calls and caching in services? If this is called instantly, then http call will be made right after injecting service which might not be desired in every situation. Btw, it is very similar to tanstack query :)
Thank you! Yes, I think they need two separate functions. One of the goals that the Angular team has is to make RxJS optional, so you only need to include it in your project if you use it. If they change resource() to optionally take an Observable, they need to include RxJS. By making it two separate functions (one imported from rxjs-interop), RxJS becomes optional. Regarding "called instantly" ... the loader can be a multiline function with an if statement. For example, one of mine looks like this: private vehicleFilmsResource = rxResource({ request: () => this.selectedVehicle(), loader: ({ request: vehicle }) => { if (vehicle) { return forkJoin(vehicle.films.map(link => this.http.get(link))) } return of([] as Film[]) } }); So it won't issue the request until the user selects a vehicle.
No, I do not. I had suggested "parameters" and "request" instead of "request" and "loader". Maybe it will still change before it moves from experimental to stable? I realized when re-watching the video that I used "request" throughout to mean the HTTP request. Seems that could be easily confused then with the property name. Other than the naming, what do you think of the feature?
Its sad that angular is slowly facing java's fate... The newer versions are so much better and have so many new features but people just dont want to migrate from the older versions
Your experience seems to differ a lot from mine. We're using Angular for our frontends and migrated to signals and standalone components for almost all of them. On the backend we're running on the JVM using Kotlin, which in many parts is an improvement to Java, even modern Java versions, from my point of view. However, aside from my work I'm active in the Java open source community and noticed a lot of projects that took a leap to newer Java versions. For a very long time Java 8 was the baseline frameworks and libraries targeted, but in the last 2 years more and more projects adjusted their baseline to Java 17 or even 21 and in turn started to modernize their codebases.
@JentaroYusong that's interesting I see newer products using newer versions of Java but older enterprise products still use Java 8 and migration isn't something people consider, one of my colleagues did a migration of our React product from 16 to 18 he had to work day night for weeks, stop any new updates to the repo, Rebasing PRs... I guess migration is more of a difficult task. But it's good to hear that people migrated to standalone components and signals so quickly
@@BenBeckers people upgrade taking advantage of the fact that angular is backward compatibility. However, many don't want to use new features. I've seen lately an app that was upgraded from 16 to 18. Yet, I didn't see a single standalone components or @if, @for.
What would we do without you Deborah ☀️
You're an absolute UA-cam gem 💎
Appreciate your work! 🙏
Wow, thank you! 😊
Thank you once again for teaching us the new features in Angular. I constantly pray for your well-being.
I appreciate that! Thank you so much! 😊
How did I miss this? I don't remember to have received a notification.
Great course from the best angular teacher.
Glad you found it! Thanks!
It is alway a pleasure to see your videos Deborah!
Thank you so much! 😊
Cool!!!
I think Angular team is taking the things forward so passionately!
Thanks Deborah, for a clear overview video.
Yep! Thank you for watching!
Thanks for your videos Deborah, you are a great teacher
Thank you! 😊
I need you by my side as my personal chatGpt. All your content is great. Thank you
"How can I help you today?" LOL!
Thank you so much for the kind words! 😊
Thank you so much for your amazing videos and for explaining everything so clearly.
You're making such a big difference in the Angular community
thank you again ❤
That is very kind of you to say. Thank you! 😊
I don't understand the renaming part, loader: ({ request: productId }) =>
To me that looks like you are destructuring a property request of type productId. Can someone explain how this ends up with a parameter named productId?
Thank you for the useful and interesting information.
Thanks for watching!
This is looking amazing. I'll wait until developer preview for this one.
Yep! It definitely looks useful! 😊
Thats a great addition. Now we just need some way to debounce signals, i don't want to spam the server with requests while the user is typing in the search field. Currently i'm using an rxjs observable with debounce and toSignal for this, but would be great if there was a signal only solution
I wonder if Angular will allow HttpClient to return a Promise instead of Observable. That would remove the next need of rxResource for a lot of apps.
One of the team's goals is to make RxJS optional, so I would guess the opposite: that they work toward making resource/fetch more full featured so we wouldn't need HttpClient.
Awesome video thanks for coming again with such a video🎉🎉
Thank you so much for this video. It's awesome !))
You forgot about respect/uvazhayu
That is kind of you to say. Thank you!
@fidgetmania Respect by default :)
Interesting (and high quality as always). I couldn't quite work out how I might use this for infinite scroll. Also interesting that they seem to be first classing fetch? I only really use HttpClient for interceptors so that would be nice if it went.
7:24 this sounds like combineLatest. So would this be the best practice to replace combineLatest with this approach?
In some cases, yes. Especially those cases where combineLatest was used to handle multiple query parameters. In other cases, there may still be use for combineLatest, such as when handling events from multiple sources (keypress and mouse move for example).
Super clear! Thanks!
Thank you! 😊
What do we use for post and put... feels like if we stick to one like rxjs it's consistent vs doing gets one way and posts and puts another way
We'd still use HTTPClient (or fetch), so that would be the same. We just wouldn't need to return the result as a signal, so it wouldn't need to be wrapped in a resource.
Great video as always. With signals and rxResource API and zoneless, can we conclude that RxJs is no longer needed and also component lifecycle hooks are no longer needed? Thanks for your feedback.
Thanks, teacher Deborah! This is the video I was waiting this week. Now that we have Resource Api, Angular (TanStack) query and SignalStore, what do you think will be the recommended way to easily manage server state (loading, error, success)? Do you think Resource api for server state and SignalStore for local state is a good combination? What do you think could be the best architecture for enterprise applications in modern Angular? Share your GDE thoughts with padawans. 🤩
Thank you for watching!
I think resource/rxResource are still too new to make architectural recommendations. It will take some time for people to try it out.
But I agree that resource/rxResource + SignalStore seem like a good combination.
Another great video again. Would you please advise me can I use resource() or rxResource() to replace combineLatest in rxjs?
Thanks!
Do you have a code snippet of your combineLatest so I have a clear idea of your objective?
I used to use combineLatest to do something with a retained observable when another observable changes. If these are all signals instead, the linkedSignal() can often do the same job. It depends on your specific scenario.
@@deborah_kurata I meant that if I can use Resource or RxResource to handle multiple http request. It seems that it can only handle one request with loader function in Resource or RxResource. To handle multiple request, it seems that we still can not avoid to use combineLatest. I asked Grok AI. It gave me the answer.
`import { inject, Injectable } from '@angular/core';
import { resource } from '@angular/core';
import { HttpClient } from '@angular/common/http';
@Injectable({ providedIn: 'root' })
export class MultiResourceService {
private http = inject(HttpClient);
combinedResource = resource({
loader: async () => {
const [users, products] = await Promise.all([
this.http.get('url1').toPromise(),
this.http.get('url2').toPromise()
]);
return { users, products };
}
});
}` or another way
`private http = inject(HttpClient);
usersResource = rxResource({
loader: () => this.http.get('url1')
});
productsResource = rxResource({
loader: () => this.http.get('url2')
});
combinedResource = combineLatest([this.usersResource.result$, this.productsResource.result$]).pipe(
map(([users, products]) => ({ users, products }))
);
combinedResource.subscribe(result => {
console.log(result.users, result.products);
});`
Hi, Deborah! Love your educational content. We've refactored our old Angular 8 codebase to fully reactive Angular 18 thanks to your videos on signals and home-made signal store. I have a concern about writing the resource locally. It's purely vibes, I don't have data to support it, but doesn't writing to resource locally go against reactivity or declarativity?
A v8 -> v18 Wow! That was a big move. Congrats!
When you say "writing to resource locally", are you referring to directly updating the signal returned from the server?
Since these features are so new, I haven't tried them yet in a "full featured" application, but I envision that they would be incorporated into the service, so the component would not update it directly. Also, many of us are still waiting for the "signal forms" features to see how that affects the flow.
@@deborah_kurata Yes, that's exactly what I meant. Keeping it in the service didn't cross my mind, it sounds better now. Thanks!
I know it's not a proper forms API, but as long as the inputs are somewhat simple, we can use native template binding with on input with [(value)] bound to a signal, and it's pretty reactive. At my work, the UI team for now made the input library compatible with Reactive Forms, template-driven forms and the new model signal binding without FormsModule at all. It looks rather messy, so can't wait for the proper signal forms.
Thanks for sharing, what about errors handling?
Thank you for watching!
Error handling is definitely a topic I want to drill into a bit more. The resource has an error property, but it only seems to be set when the connection is dropped during the async request. For other errors (like 404), the resource error property isn't set because the server responds (even though that response is an error condition).
I have on my list to do a video specifically about error handling with resource and rxResource.
Thanks again!
Great new feature!!
Yes it is! 😊
❤❤❤
Hi there, thanks for the video, clear explanation, straight to the point example, lovely!
I heard you mention that resource() is only for GET requests. Any tips on how to deal with POST/PUT/PATCH/DELETE? Asking because loading indicators and error handling are often desired for the entire spectrum of HTTP verbs.
Thank you for the kind words about the video!
resource/rxResource don't do much to help with HTTP errors, so you still need to handle those for any HTTP verb. (An HTTP request that returns an error code does NOT set the resource error property.)
Regarding the loading indicators, what's being loaded for a POST/PUT/PATCH/DELETE? How are you doing that now?
@@deborah_kurata Hah, yeah they're following fetch() with regards to error status codes.
For POST/PUT/PATCH/DELETE, I'm now manually setting variables like this.isAddingProduct = true; before I fire off the request. But that gets tedious, especially because formally those booleans states should ideally be unit tested. Would be great if this were to get standardized a bit more.
Interesting if i use resource how interceptor will be process my requests))
Thanks Deborah for the video.
As I understand, using 'resource()' with 'fetch' will be more reasonable for this update?
Thank you for watching!
Personally, I'm a big fan of Observables and still really like having the Observable pipeline available for things such as debouncing, filtering, etc. (Though my simple example here didn't cover any of those more advanced scenarios.) At least for now, I plan to use rxResource.
But there many developers that prefer a Promise-based approach and now they have the option.
Thank you
it looks really interesting feature, thanks. i'd like to watch a video about how to work with websocket in angular? if you can i really appreciate it
Thank you for watching. I'll add that to my list. Thanks for the suggestion!
Teacher 💛
😊
Pretty sweet!
Great video and really good explaination as always :)
But i have some concerns about this feature:
Do we need both rxResource and Resource? Maybe Angular team can make it to accept Observable or Promise as the api call?
How about debouncing calls and caching in services? If this is called instantly, then http call will be made right after injecting service which might not be desired in every situation.
Btw, it is very similar to tanstack query :)
Thank you!
Yes, I think they need two separate functions. One of the goals that the Angular team has is to make RxJS optional, so you only need to include it in your project if you use it. If they change resource() to optionally take an Observable, they need to include RxJS. By making it two separate functions (one imported from rxjs-interop), RxJS becomes optional.
Regarding "called instantly" ... the loader can be a multiline function with an if statement. For example, one of mine looks like this:
private vehicleFilmsResource = rxResource({
request: () => this.selectedVehicle(),
loader: ({ request: vehicle }) => {
if (vehicle) {
return forkJoin(vehicle.films.map(link =>
this.http.get(link)))
}
return of([] as Film[])
}
});
So it won't issue the request until the user selects a vehicle.
👏🏻👏🏻👏🏻
🙏🏼🙏🏼🙏🏼
Do you think “request” is a good name for dependencies?
No, I do not. I had suggested "parameters" and "request" instead of "request" and "loader". Maybe it will still change before it moves from experimental to stable?
I realized when re-watching the video that I used "request" throughout to mean the HTTP request. Seems that could be easily confused then with the property name.
Other than the naming, what do you think of the feature?
Its sad that angular is slowly facing java's fate... The newer versions are so much better and have so many new features but people just dont want to migrate from the older versions
Your experience seems to differ a lot from mine. We're using Angular for our frontends and migrated to signals and standalone components for almost all of them.
On the backend we're running on the JVM using Kotlin, which in many parts is an improvement to Java, even modern Java versions, from my point of view.
However, aside from my work I'm active in the Java open source community and noticed a lot of projects that took a leap to newer Java versions. For a very long time Java 8 was the baseline frameworks and libraries targeted, but in the last 2 years more and more projects adjusted their baseline to Java 17 or even 21 and in turn started to modernize their codebases.
@JentaroYusong that's interesting I see newer products using newer versions of Java but older enterprise products still use Java 8 and migration isn't something people consider, one of my colleagues did a migration of our React product from 16 to 18 he had to work day night for weeks, stop any new updates to the repo, Rebasing PRs... I guess migration is more of a difficult task. But it's good to hear that people migrated to standalone components and signals so quickly
I’m migrating from 1.7 to 17. Standalone components made this feasible.
The angular surveys says otherwise, and shows that most projects are on the 3 latest versions.
@@BenBeckers people upgrade taking advantage of the fact that angular is backward compatibility. However, many don't want to use new features. I've seen lately an app that was upgraded from 16 to 18. Yet, I didn't see a single standalone components or @if, @for.