If you are curious about how to build Angular applications today with Signals and minimal RxJs, using a new approach check out my Modern Angular With Signals Course, currently in pre-launch mode - angular-university.io/course/angular-signals-course 😊The first 40 minutes are already available 👍
Poiters are also a barrier for new c++ commers, I don't see they remove them just because people have to study them. Rxjs has many use cases. Such a beautiful tool.
The use cases for Rxjs are few and far between in practical terms. I used to do C++ in the beginning of my career, it's the kind of technology that is not well suited for business software. I spent tons of time debugginh core dumps due to some edge case double pointer delete call. Definitively not worth the complexity, companies have moved later to Java and with good reason, it avoided all those problems.
Thanks man , i watched all the modern pattern you provided using async await .. , Do you advice to start using the pattern now or better stick with rxjs pattern and wait till there is more content and support for the modern pattern ?
How do you think httpclient will be updated? Moving to promise based seems like a step backwards. Do you think there will be any support to integrate signals with async/await?
That's a very good question, it will be discussed via RFC. I suspect it will return Observable | Promise and you can choose which one via a DI setting. This would allow for seamless migration of old apps, but new ones can use Promises. This approach is already used in certain places of the framework, like guards and resolvers. 😊
Yes, we can combine them, there is great interoperability.😊 👍 I think Signals should take us 98% to what we need to do or even more, and RxJs can help with the rest.
I'm very curious to see what everyone says, both the RxJs crowd and the non RxJs crowd. I just want to say that independently of my opinion, everyone is more than welcome to chime in on the comments. 😉
I tried installing and running Angular 17 and from nom install it throws errors and then when I force typescript update it's throwing errors on routing!! 16 was the last version you could install, create new project and run with it!! It seems the newer the thing the harder it becomes
Hey Sir, Signals are amazing but I have a question about using them with reactive forms. Considering the built in reactivity of reactive forms using RxJS & observables, how would integrating signals impact their functionality? Thanks for sharing your knowledge with us! 🙏🏼
You're welcome Hugo 😊Right now the forms, router, etC. modules are being reviewed to integrate signals. So for now, you can use toSignal, toObservable, until the new Forms API is available. In practice today, RxJs is part of the API of Angular in certain parts, so I ocasionally still use it mostly because of that. But just because we have to use it still at certain places, it does not mean that you have to write your whole application using it, right? 😉
What's funny is the magical "dirty checking" was THE killer feature of angular.js. No need to fire some kind of `emitter` for every single change to be propagated. Now it's the villain.
Yrs I think that it's still one of it's best features. 😂 But I get that in certain edge cases it apparently breaks down and it becomes hard to debug. So I'm all for signals, it's close enough to using plain member variables, I really like signals a lot. 👍
@@AngularUniversity I get it. I'm very comfortable with RxJs and 'reified' async primitives so signals just feels like training wheels. That said, it was a lot of grinding and i'm the 'goto' guy whenever it goes south. The reality is signals don't scale up, but RxJs doesn't scale down. Most apps are below the crossover point.
@@adambickford8720 Yes but that's a good thing right, you shouldn't have to have a PHD in reactive programming to build a user interface.👍😊 Signals scale up just fine, that for me is just a complete myth, that is used to justify RxJs "fear of not scaling". I think an application that uses heavily RxJs will potentially scale worse, because the high complexity of the code base can be become crippling to the team over the years.👍
@@AngularUniversity Its only good when it's good :) When i say signals don't 'scale up' i mean they are a subset of RxJs. Solving a simpler problem (sync vs async) will indeed yield a simpler solution and signals are probably right-sized for most cases. Now instead of botching simple stuff w/RxJs we'll botch complex stuff with misusing signals. Given the hard cases are rare, it doesn't seem unreasonable for the typical app.
@@adambickford8720 Yes I mostly agree, I still think signals will be enough for the vast majority of cases. It's indeed better to error on the side of less complexity to start, and add it later only if really needed.
I'm very happy to hear that, Angular can be used in different ways and the Angular team themselves recommends the community to explore other patterns and best practices. 😊
They are so much easier to understand, aren't they? 😉 And the other 20%, what are the most common use cases that you find? In my code bases, I hardly use it anymore lately. I build my services layers with Promises and async/await, and works like a charm, my team loves it. 👍
@AngularUniversity I can probably get rxjs down to 10% with more tinkering. Ngx-translate, for example, relies on observables but is still easy to manage. I too have refactored my httpclient services to use promises.
Yes I agree. But I would add to that, that in my estimation Signals are the right fit for 98% of the cases, and RxJs for the other 2%. 😉 I would also add that there is a tendency to add Rxjs without need and then try to justify it's usage, for example by adding cancellation on places that don't need it. This kind of stuff happens a lot. 👍
Why all this obstinacy against the usage of rxjs for people that know what are doing, and know when and how to use it? It's such a powerful tool and I definitely see a more that a 2% usage. For example, an autocomplete with debounce time and cancelation is really easy to implement with rxjs and my customers ask for it in every project.. I got tired of this strong opinions in your channel, bye bye
@@codeSurvivor This is the problem. Just because it's a good solution for making a search box, it does not mean that you have to automatically use it everywhere blindly, without thinking about the accidental complexity that you are creating for you and your teammates. It's about using the right tool for the job. 👍
The Angular team is making RxJs optional. It's possible to build application in Angular today with minimal RxJs. I'm currently creating a course showing how to do it here - angular-university.io/course/angular-signals-course
If you are curious about how to build Angular applications today with Signals and minimal RxJs, using a new approach check out my Modern Angular With Signals Course, currently in pre-launch mode - angular-university.io/course/angular-signals-course 😊The first 40 minutes are already available 👍
Poiters are also a barrier for new c++ commers, I don't see they remove them just because people have to study them. Rxjs has many use cases. Such a beautiful tool.
The use cases for Rxjs are few and far between in practical terms. I used to do C++ in the beginning of my career, it's the kind of technology that is not well suited for business software. I spent tons of time debugginh core dumps due to some edge case double pointer delete call. Definitively not worth the complexity, companies have moved later to Java and with good reason, it avoided all those problems.
Thanks man , i watched all the modern pattern you provided using async await .. , Do you advice to start using the pattern now or better stick with rxjs pattern and wait till there is more content and support for the modern pattern ?
Thank you for the super chat, I've been using async await for over a year now it works awesome 😉
Legend👌
How do you think httpclient will be updated? Moving to promise based seems like a step backwards. Do you think there will be any support to integrate signals with async/await?
That's a very good question, it will be discussed via RFC. I suspect it will return Observable | Promise and you can choose which one via a DI setting. This would allow for seamless migration of old apps, but new ones can use Promises. This approach is already used in certain places of the framework, like guards and resolvers. 😊
I'm also gradually shifting to async/await and signals after watched some of your video.
I'm happy to hear that 😊, and how do you find it so far?
I still use rxjs with signals
Yes, we can combine them, there is great interoperability.😊 👍 I think Signals should take us 98% to what we need to do or even more, and RxJs can help with the rest.
@@AngularUniversity so dam true
I'm very curious to see what everyone says, both the RxJs crowd and the non RxJs crowd. I just want to say that independently of my opinion, everyone is more than welcome to chime in on the comments. 😉
I'm hoping for "rxjs lite", so even if u use basic rxjs, like switchmap, or filter, it will be built into angular
I recommend learning async/await then I bet you will love it it's super simple. It almost reads like plan synchronous code, but it's asynchronous. 👍
I tried installing and running Angular 17 and from nom install it throws errors and then when I force typescript update it's throwing errors on routing!! 16 was the last version you could install, create new project and run with it!! It seems the newer the thing the harder it becomes
Weird, something seems to have gone wrong, in principle it should be as easy as ever, with such a fine-tuned CLI and standalone components. 😊👍
Hey Sir,
Signals are amazing but I have a question about using them with reactive forms. Considering the built in reactivity of reactive forms using RxJS & observables, how would integrating signals impact their functionality?
Thanks for sharing your knowledge with us! 🙏🏼
You're welcome Hugo 😊Right now the forms, router, etC. modules are being reviewed to integrate signals. So for now, you can use toSignal, toObservable, until the new Forms API is available. In practice today, RxJs is part of the API of Angular in certain parts, so I ocasionally still use it mostly because of that. But just because we have to use it still at certain places, it does not mean that you have to write your whole application using it, right? 😉
Hi Sir ,Is there any other approach to call api Parallel apart from forkjoin?
Yes sure, you can use a library like tRPC, or do it manually using either Promise.all or Promise.allSettled 👍
@@AngularUniversityThank you
Thank you for this explanation. I dont have much experience with RxJs and Signals but all these makes sense.
You're welcome, I'm glad it helped 👍😉
Thank you Vasco.
I love RxJs and his power.
The new way to write code seems to be great to. So the interoperability will be great.🎉❤
Yes, I think it's the start of a great new era for Angular 😉
When I started with angular I enjoyed it now with added complexity and they way other developers invision design orchestration it's a nightmare
It doesn't have to be that way, it's possible with Signals to write applications that are reactive and still easy to reason about. 👍😊
What's funny is the magical "dirty checking" was THE killer feature of angular.js. No need to fire some kind of `emitter` for every single change to be propagated.
Now it's the villain.
Yrs I think that it's still one of it's best features. 😂 But I get that in certain edge cases it apparently breaks down and it becomes hard to debug. So I'm all for signals, it's close enough to using plain member variables, I really like signals a lot. 👍
@@AngularUniversity I get it. I'm very comfortable with RxJs and 'reified' async primitives so signals just feels like training wheels. That said, it was a lot of grinding and i'm the 'goto' guy whenever it goes south.
The reality is signals don't scale up, but RxJs doesn't scale down. Most apps are below the crossover point.
@@adambickford8720 Yes but that's a good thing right, you shouldn't have to have a PHD in reactive programming to build a user interface.👍😊 Signals scale up just fine, that for me is just a complete myth, that is used to justify RxJs "fear of not scaling". I think an application that uses heavily RxJs will potentially scale worse, because the high complexity of the code base can be become crippling to the team over the years.👍
@@AngularUniversity Its only good when it's good :)
When i say signals don't 'scale up' i mean they are a subset of RxJs. Solving a simpler problem (sync vs async) will indeed yield a simpler solution and signals are probably right-sized for most cases.
Now instead of botching simple stuff w/RxJs we'll botch complex stuff with misusing signals. Given the hard cases are rare, it doesn't seem unreasonable for the typical app.
@@adambickford8720 Yes I mostly agree, I still think signals will be enough for the vast majority of cases. It's indeed better to error on the side of less complexity to start, and add it later only if really needed.
This channel give me different pov than josh's channel that teaching about declarative.
I'm very happy to hear that, Angular can be used in different ways and the Angular team themselves recommends the community to explore other patterns and best practices. 😊
I’d say 80% of my needs are satisfied with signals. And my apps feel much better architected for it.
They are so much easier to understand, aren't they? 😉 And the other 20%, what are the most common use cases that you find? In my code bases, I hardly use it anymore lately. I build my services layers with Promises and async/await, and works like a charm, my team loves it. 👍
@AngularUniversity I can probably get rxjs down to 10% with more tinkering. Ngx-translate, for example, relies on observables but is still easy to manage. I too have refactored my httpclient services to use promises.
Always trying to use right tool for the job. There are use cases where RxJS is best. And some where you shouldn't be using it. End of story
Yes I agree. But I would add to that, that in my estimation Signals are the right fit for 98% of the cases, and RxJs for the other 2%. 😉 I would also add that there is a tendency to add Rxjs without need and then try to justify it's usage, for example by adding cancellation on places that don't need it. This kind of stuff happens a lot. 👍
Why all this obstinacy against the usage of rxjs for people that know what are doing, and know when and how to use it? It's such a powerful tool and I definitely see a more that a 2% usage. For example, an autocomplete with debounce time and cancelation is really easy to implement with rxjs and my customers ask for it in every project.. I got tired of this strong opinions in your channel, bye bye
@@codeSurvivor This is the problem. Just because it's a good solution for making a search box, it does not mean that you have to automatically use it everywhere blindly, without thinking about the accidental complexity that you are creating for you and your teammates. It's about using the right tool for the job. 👍
NgRx is the most unnecessary part of Angular. It should be replaced by RxJs in fact.
The Angular team is making RxJs optional. It's possible to build application in Angular today with minimal RxJs. I'm currently creating a course showing how to do it here - angular-university.io/course/angular-signals-course
rxjs is just way too over engineering
I agree, it's a great fit for certain cases, but other than that it's like hunting kittens with a tank. 😊
@@AngularUniversity totally agree
No.