RxJs Becoming Optional In Angular: Why and What's Next? 

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. 👍

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.

@@AngularUniversity so dam true

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. 👍

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

I'm happy to hear that 😊, and how do you find it so far?

Yes, I think it's the start of a great new era for Angular 😉

Thank you for the super chat, I've been using async await for over a year now it works awesome 😉

Legend👌

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.

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? 😉

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. 😊👍

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. 👍😊

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. 😊

You're welcome, I'm glad it helped 👍😉

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 sure, you can use a library like tRPC, or do it manually using either Promise.all or Promise.allSettled 👍

​@@AngularUniversityThank you

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 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.