This one makes sense. For a truly "All in one" framework like Angular, it is weird that it heavily relied on a totally 3rd party library rxjs for the most basic api requests
I think it's great if use cases are decoupled and independent - you can use rxJS without Angular or with Angular. This increases resources put into the development, and the use cases tested. It also might improve the popularity, as you can check out rxJS without replacing your frontend framework, and makes the skillset of knowing rxJS more valuable, as it can be used with Angular apps, but also with any other apps, too. resource() etc. might be handy if you just want to make an app in Angular and don't need rxJS. But knowlege of resource() etc. won't help you much outside Angular. And it might increase the learning curve for non-Angular developers, who might already know rxJS.
For me the most important is standalone components as default. I hate having that line in every single entity. I am running v19.next10, v11 should come out today.
That looks great. Are there any news on the interplay of signals and reactive Forms though? As long as people have to use valueChanges which is an Observable, rxjs will still stick around
it's really funny that I created a "StatusAndValue" class in my apps that basically does the same as the "resource" primitive. just make the HTTP request's state (fetching, error, finished) reactive too
@@tolstoievski4926 Because Angular has had the HttpClient as a pattern to make http requests since ever (I mean, idk about AngularJS at least, but since then)
Besides, HttpClient has some features on top of fetch, like adding context to interceptors, but this api is in developer preview, so they might change some things before actually releasing it to the public
It would probably be fun to do a video on but I don't think it would be of interest to most people who watch the channel, in any case I'm not doing anything super out of the ordinary. There's some examples in the motion canvas repo I think which are great as references for your own animations.
Signals have drawbacks, we still would need RxJS for event like streams, because signals, because of their structure can pass butches of data which will not happen if you use RxJS Signals great for state, RxJS still best for event handling
Running V19-Next11 here - it's simply amazing. My favorite is I don't have to use "allowSignalWrites" in effects any longer. phewwwwww it was an eye sore
@@AK-vx4dy its hard to write tests, it can be buggy if you don't know what you're doing, lot of edge-case gotchas with null-streams, race conditions, effects compounding when you don't want them, etc.
I liked the idea of having an all-in-one primitive to manage basic state use cases, but i did not like the fetch API use. Mainly because to achieve request cancelation we have always to pass this abortSignal, which limits the separation of the requests in a requests service. The rxResource is so much cleaner to make that. Furthermore, how can we use interceptors in a fetch-based request? Will it be handled the same way as HttpClient? If we want to make RXJS optional i don't think that using the fetch API is the correct way to do that. Maybe we should have a signal-based HttpClient which handles the request cancelation and interceptors
This api guarantees angular is moving away from rxjs, even the helpers like toSignal, toObservable are imported from interop package which means a compat layer not from core
surely that's next on the docket, right? if angular is planning to make rxjs optional, then they *must* make their http client service also work with signals.
I haven't actually used it yet (this is just from a read of the PR, I think it's going to be available in @next this week), so take with a grain of salt. I don't know if its eager or not, but it seems reasonable that it would/could be triggered lazily on signal read (I think there is an RFC coming as well, so there's definitely room for changes). And my understanding is that the resource does refresh whenever any of the dependent signals change (there is also an imperative refresh() method that can be called on the resource)
@@mfpears you want a lazy toSignal right? I don't really know what the Angular teams thinking around it is at the moment but there was some discussion here: github.com/angular/angular/issues/55337 around the toLazySignal implementation in ngxtension: ngxtension.netlify.app/utilities/signals/to-lazy-signal/
Nah 😅. I like where signals are going but this doesn’t feel better. Add to the fact that the current state of signals will always be reliant on change detection, this is going to take a little bit more time to grow on me.
@@hengkeatyam3700 a pain to get rxjs "right" and onboarding new people to it is a pain. it bleeds everywhere and you need to use it then everywhere. Singals just look way cleaner and they are way easier to understand then rxjs and rxjs/stores
I have a weekly newsletter if you'd like to join: mobirony.ck.page/4a331b9076
This one makes sense. For a truly "All in one" framework like Angular, it is weird that it heavily relied on a totally 3rd party library rxjs for the most basic api requests
We can't just let go of rxjs after using it for years in http 😅
@@SamiullahKhan We're not letting it go, it's just another level up in Angular learning tree.
I think it's great if use cases are decoupled and independent - you can use rxJS without Angular or with Angular. This increases resources put into the development, and the use cases tested. It also might improve the popularity, as you can check out rxJS without replacing your frontend framework, and makes the skillset of knowing rxJS more valuable, as it can be used with Angular apps, but also with any other apps, too.
resource() etc. might be handy if you just want to make an app in Angular and don't need rxJS. But knowlege of resource() etc. won't help you much outside Angular. And it might increase the learning curve for non-Angular developers, who might already know rxJS.
@@aheendwhz1 rxjs is already very popular in the infra layer of frontend libraries. Its download number has surpassed React and Angular combined...
This is pretty cool! Excited to see what the final version of v19 will bring
For me the most important is standalone components as default. I hate having that line in every single entity. I am running v19.next10, v11 should come out today.
Annn it's out... amazing.. resource api is now in
That looks great.
Are there any news on the interplay of signals and reactive Forms though? As long as people have to use valueChanges which is an Observable, rxjs will still stick around
Nothing announced yet but at this point it is almost guaranteed that we will see something on the forms/signals front at some point
All a good description.
This feature looks similar to Tanstack Query. Nevertheless, a great addition to Angular!
it's really funny that I created a "StatusAndValue" class in my apps that basically does the same as the "resource" primitive. just make the HTTP request's state (fetching, error, finished) reactive too
It looks pretty nice, but at the same it feels kinda cursed to use "fetch" in Angular
Why ?
@@tolstoievski4926 Because Angular has had the HttpClient as a pattern to make http requests since ever (I mean, idk about AngularJS at least, but since then)
Besides, HttpClient has some features on top of fetch, like adding context to interceptors, but this api is in developer preview, so they might change some things before actually releasing it to the public
@@alexsandroagustini714 yep, but I think the angular team will make this resource pass through interceptors as well
@@RodrigoSalesSilva Yeah, if that' the case then it'll be alright
is the fetchapi intercepted with the Http_Intercepter like the normal httpClient is?
idk but if you watched till the end you'd see you can use the httpClient inside of the ressource() instead of fetch() at 2:46
I'd love a motion canvas video on how to do those circles and code...
It would probably be fun to do a video on but I don't think it would be of interest to most people who watch the channel, in any case I'm not doing anything super out of the ordinary. There's some examples in the motion canvas repo I think which are great as references for your own animations.
do you think the key name 'request' makes sense for dependencies?
Signals have drawbacks, we still would need RxJS for event like streams, because signals, because of their structure can pass butches of data which will not happen if you use RxJS
Signals great for state, RxJS still best for event handling
Running V19-Next11 here - it's simply amazing. My favorite is I don't have to use "allowSignalWrites" in effects any longer. phewwwwww it was an eye sore
Resource API is now available in V19-Next 11
This is a game changer
Why everybody wanting to remove rxjs, it is beautiful
Because none of them understands it… imo it’s hard to get into it but it’s worth it..
Beautiful and terrible at the same time.
@@Floubadour Why terrible?
@@AK-vx4dy its hard to write tests, it can be buggy if you don't know what you're doing, lot of edge-case gotchas with null-streams, race conditions, effects compounding when you don't want them, etc.
rxjs is like an ice bath. A bit masochistic but pretty amazing long term. But everyone you try to convince about it is annoyed and disgusted.
So this is react-query for Angular?
we need debounce time for signal
I liked the idea of having an all-in-one primitive to manage basic state use cases, but i did not like the fetch API use. Mainly because to achieve request cancelation we have always to pass this abortSignal, which limits the separation of the requests in a requests service. The rxResource is so much cleaner to make that.
Furthermore, how can we use interceptors in a fetch-based request? Will it be handled the same way as HttpClient?
If we want to make RXJS optional i don't think that using the fetch API is the correct way to do that. Maybe we should have a signal-based HttpClient which handles the request cancelation and interceptors
I have feeling that it is like back to the Past ,using Fetch and Promise ?>
This api guarantees angular is moving away from rxjs, even the helpers like toSignal, toObservable are imported from interop package which means a compat layer not from core
The whole Angular without RxJS is confusing to me when the HttpClient service is based on Observables.
surely that's next on the docket, right?
if angular is planning to make rxjs optional, then they *must* make their http client service also work with signals.
If it fetches eagerly and doesn't refresh automatically, it's not declarative, because those behaviors will have to be created imperatively.
I haven't actually used it yet (this is just from a read of the PR, I think it's going to be available in @next this week), so take with a grain of salt. I don't know if its eager or not, but it seems reasonable that it would/could be triggered lazily on signal read (I think there is an RFC coming as well, so there's definitely room for changes). And my understanding is that the resource does refresh whenever any of the dependent signals change (there is also an imperative refresh() method that can be called on the resource)
@@JoshuaMorony that would be good news
Then we could create a new version of toSignal around this, right?
@@mfpears you want a lazy toSignal right? I don't really know what the Angular teams thinking around it is at the moment but there was some discussion here: github.com/angular/angular/issues/55337 around the toLazySignal implementation in ngxtension: ngxtension.netlify.app/utilities/signals/to-lazy-signal/
with this i think i can remove rxjs. yeah this will change a lot my code but better than sorry XD
Nah 😅. I like where signals are going but this doesn’t feel better.
Add to the fact that the current state of signals will always be reliant on change detection, this is going to take a little bit more time to grow on me.
i can't wait to get rid of rxjs and this will help a lot! can't wait to update to angular 19!
why?
@@hengkeatyam3700 a pain to get rxjs "right" and onboarding new people to it is a pain. it bleeds everywhere and you need to use it then everywhere. Singals just look way cleaner and they are way easier to understand then rxjs and rxjs/stores
jigggo