Join my mailing list for more exclusive content and access to the archive of my private tips of the week: mobirony.ck.page/4a331b9076

Signal will be amazing in a component / presentation level and Observable will be amazing in a services / data transformation level. I think angular did a realy good job to combine the power of both.

@tropicarls

Жыл бұрын

Right on the nail

Was very hesitant to use signals, and also a very avid user of rxjs, but you've outlined many obvious problems with rxjs that signals solve very easily. thank you!!!

Thank you for always making quality videos which explain difficult subject in an easy to understand way. Can't wait to use signals in our product at work!

Very good and detailed explanation (with diagram, and example). Your videos answer my question what is different between this new Signals and the old traditional way RxJS. Hope to see more videos like this from you

This video did a better job for me of explaining signals than the dedicated one! Thanks!

Great info Joshua! Thank you for clarifying signals with real examples vs RxJS. It looks they are easier

Very nice description with the practical code examples. Nice one! Thanks!

Excellent presentation Josh ! There is a real hype around these Signals and it can only lead to better DX 🙂

thanks for outlining the gotchas, especially with observables, subscriptions, pipes, side effects, etc. Took me sometime to wrap my head around these "subjects" [pun], while also getting bitten along the way by those hidden traps. I'm sold here to signals, that as you've shown here: the simplicity, elegance while still being powerful.

This is the type of video/explenation that will be really helpful to get people hooked ❤ What I think is not made as clear: Signals are REALLY useful even for very experienced rxjs devs. For example: Things like the solid dev tools for signals that can visualize the current (changeing) reactive graph in a way that is easy to understand, are simply not possible with rxjs. The non existance of the diamond problem and the synchronous mental model is so beneficial in many more ways than probably can be easily explained. Signals have to be experienced to really be able to appreciate them🎉

@valcron-1000

Жыл бұрын

> Things like the solid dev tools for signals that can visualize the current (changeing) reactive graph in a way that is easy to understand, are simply not possible with rxjs Why are these tools not possible? Is there any technical limitation?

@timonkrebs6978

Жыл бұрын

@@valcron-1000 yes there are technical limitations. At first they seem quite nit picky but via detours they have big impacts. The most important is probably that in rxjs there is no concept of the current state of the reactive graph. That is why you can not get the value without subscribing. That is also why there are hot and cold observables and also why it is not possible to have devtools for rxjs that can visualize the reactive graph in a helpful/understandable way. Operators like debounceTime/delay/throttleTime etc. Make this quite clear. There is no concept of current state inside of these operators.

@CesarDemi81

Жыл бұрын

@@timonkrebs6978 But is that actually necessary? Why would I want to keep track of what is inside operators like those? Why would I want to keep track of the state of a request that has already been made and gone? If I want to keep a state for all of that, I'd create a state with NGXS (or the horrid NGRX, if you like) and track my *component* state there, but that's a very specific scenario to keep state... you don't always need it.

@timonkrebs6978

Жыл бұрын

@@CesarDemi81 the reasons why you would like that are exactly the things mentioned before. Debugability with devtools is a huge advantage. But also memoisation and the much easier mental model that come with it and a lot more like the possibility to serialize the reactive graph open up things that would be impossible with rxjs. You are right some of that would also be possible with ngxs/ngrx but these solutions come with a LOT of additional unneccesary overhead for most problems that signals do not have.

@user-zl5gi8sv7u

Жыл бұрын

its a fireship ripoff

Thank you very much for this video! Things like that will make it a lot easier to explain why we should switch to signals.

Will explained! Thanks again for the quality of your content 🔥🔥

Very good and informative. I'm looking forward to getting stuck in to Angular 16

As someone who is a huge fan of rxjs and tries to help jr devs at work write more reactive code, I love signals. It so simple to use and for people to understand after spending some time with it. I can't expect someone that's been working on Angular for a months to be as comfortable with rxjs as me whose been using it since Angular 2 first came out. Signals makes it so much easier to not fall back to the non reactive coding patterns that alot of jr devs usually do.

Thats exactly the video i needed to understand the purpose of these signals, thanks !

Best explanation for signals I found on youtube 👏

Great comparison. By imho introducing completely new approach like signal just because rxjs has some edge cases or complexities doesn't sound right. Sure rxjs is more difficult than signals but Angular is difficult enough in comparison to React so trying to simplify 1 thing won't help and it is better to have rxjs like good but difficult approach.

@JoshuaMorony

Жыл бұрын

This does seem to be part of a broader effort to modernise and simplify the basic experience of Angular though - push RxJS into the background (make it optional), add signals, move to standalone components by default to remove necessity to learn about NgModules - given all that, I think the default/beginner experience of Angular is becoming quite simple.

@MonsterlessonsAcademy

Жыл бұрын

@@JoshuaMorony Thank you for clarification!

Always love watching your Angular content, especially when you cover new exciting topics! Personally I can't wait for the official release of signals, and I think they'll work hand in hand with rxjs. On a semi-related note, I was wondering if you've ever heard of or used the 'rxjs-observed-decorator' library, and if so I was wondering what your thoughts were on it.

@JoshuaMorony

Жыл бұрын

Thanks! and no I'm not familiar with that library

Regardless of what's better I think RxJs helped me see a different way to write code, and this is not just specific to angular or javascript, I also work with Java where I was able to directly use my knowledge gained from using RxJs to work with reactive java. I believe other languages have similar concepts so it's definitely worth knowing and even though I believe I will mostly be using signals in the future I am not sorry that I had the opportunity to work with RxJs

@JoshuaMorony

Жыл бұрын

I think if you already know and like RxJS then there will still be plenty of room to use it in Angular projects where it is preferable to any alternative (just likely there will be less need to use it than before)

@janoschii

Жыл бұрын

@@JoshuaMorony Where RxJs is preferable is exactly what I miss in your Clip.

Nice explanation! When I saw signal in the release notes I wasn't able to see the simplicity perspective that it's bring to table. Will be a way easier to introduce async programming with signal!

Thanks mate for an awesome video. I think rxjs is awesome and I really looking forward to signals as well.

Great comprehension, no shit talk just real coding and explanation, I liked it much.

Very nice explanation. Thank you

Really eye opening. Thanks a bunch.

Thank you for posting this!

Great explanation, thank you!

Hey, thanks for the great videos. I like your presentation of the material. May I ask what color scheme or theme you use in this video? Can you share?

Interesting! A big difference I'm seeing is signals are synchronous while observables are asynchronous when you want to access a value, which has big implications. I guess I'll have to try signals in my next application. I would be tempted to use it in my current one, but that's going to be a big refactoring that I can't afford to do.

Nice explanation, thanks!

This does a great job I think of "selling" Signals. This reinforces my belief that signals are essentially RxJS with training wheels. A lot of the "gotcha" stuff that folks who have learned RxJS over the last few years have figured out are simplified. If there was a way to convert between them easily (e.g. from(signal) or switchSignal(signal)... or signal.from(observable))... well that would be REALLY interesting.

@JoshuaMorony

Жыл бұрын

There will be! The "fromObservable" and "fromSignal" APIs already exist and will be included in an rxjs-interop package

Thanks, Joshua!

@4:02 Can you please explain, when exactly the derivedValue is computed?

Hi Josh, is v16 published somewhere?

Practical video :) love it!

Great job!

Excellent explanation. The simpler, the better. You don't have to be a specialist to write good apps.

Love your videos !

Thank you for your video, as always (even though I'm not writing Angular apps but React) I love seeing updates from you thanks to the quality of your work! I'm also a big fan of RxJS with React, and I must say for things related to asynchronous data structures RxJS is a wonderful piece of technology to unify all. You did not show much examples regarding asynchronous data with signals, is it because it is not really made for working with those in the first place? What would be a typical example of signals that come from a remote data source with a filter for instance? Would RxJS be better in those specific cases? Thank you for your answer and keep up the good work!

@CodingAbroad

Жыл бұрын

My understanding is signals is for synchronous work only so we’ll still have to be using rxjs at least for the asynchronous work

@JoshuaMorony

Жыл бұрын

Yes this was intentionally focusing on just the "reactive primitive" aspect and signals are indeed a synchronous mechanism. You could still do async stuff e.g. with async/await but this is going to be a more imperative style. I think we should keep an open mind for where patterns could go with signals, but generally yes I think I will rely a lot on RxJS for async.

@MrKarameyl

Жыл бұрын

@@JoshuaMorony Cristal clear answer, thank you!

What is the alternative to the manual subscription in 3:10? is there a video or link, that would explain how to avoid these subscriptions? and why exactly should they be avoided?

@CodingAbroad

9 ай бұрын

Alternative is using the async pipe. Manual subscription should be avoided as you have to manually unsubscribe as well which is more code

All "problems" (I would say side-effects) you mentioned are actually very EZ fixable in RxJS, so I it's not so cut and dry. However one has to have some experience to see those side-effects immediatelly during writing the code. Only real difference I can see is in writing less code out-of-the-box, which can be erased by writing one single cutom pipe and apply it anywhere you want. Then the practical difference is going to be mySignal vs my$.pipe(signalLike())... Still, it's great to have that extra option as it makes Angular more approachable and predictable to newcomers

on what basis did computed() wait for both values to be updated before computing. the changeValues() funciton to complete?

I wonder how I can separate the changes in the effect, when which "signal" or "computed" has changed?

Simple and effective super and well explained

Nice Explained

Some really good points - thank you. One of your criticisms of rxjs is the transient values caused by the combineLatest diamond problem (which can be solved by debounceTime btw), but signals actually cause the same thing with the initial value required by toSignal(). Also, we have the new component input signals, but what if I want to debounceTime() or throttle()? I would have to convert to observable and back to signal...

There is also the case for signals being less costly as they will not necessarily update once the dependent value changes, but only when pulled.

What does the lifecycle on an edict look like when you can code a procedure directly in the class? All code in constructor?

@JoshuaMorony

Жыл бұрын

The APIs aren't really settled on this stuff yet, keep an eye out for the RFC - it might be that effects are generally added to the constructor or if that isn't what the community wants we might land on something else

Really good video :)

Interesting, is there will be any distinguishing feature for signal variables? Like, due to observables you should use $ at the end of the variables. Because now it's clearly understendle what are observables and what are not just by looking at the variable.

@JoshuaMorony

Жыл бұрын

This discussion has come up and there's some support for using $ for signals, some for some alternative syntax, and some for no special syntax. I was originally in favour of just keeping the observable notation since it is something people are already used to using, and agreeing on some other syntax would be hard, but now I'm leaning more toward just having no special syntax. I guess we'll see where the community lands! I don't think it is something the Angular team will specify.

Could you share how signals avoid the diamond problem? I found a comment under an article on Angular's signals that said that even Solid.js signals do not avoid this problem. Are Angular's signals somehow different? From the piece of code I still see two separate updates first of one value then of another which look like the derived value should first react to the first value update and then the second. But maybe I don't know something about the inner working of these signals.

@JoshuaMorony

3 ай бұрын

Yes Angular's signals implementation is different to Solid - on the surface the behaviour we would see is that if two separate signal updates occur in the same "tick" then the re-computation of a signal that depends on those would just occur once with the latest values. As for the actual inner workings I think it was this stream with Alex/Pawel/Ryan that gets into the weeds of how it actually all works: kzread.info/dash/bejne/eqeoptGPgci2aco.html

For the last mentioned problem where there is an individual subscription for each async pipe in the template, there is a solution by placing a shareReplay(1) operator downstream from the source (eg. at the end of the pipe). This makes the observable act as a ReplaySubject(1) except it cannot be next-ed. In other words, this operator works as a cache, that stores and emits the last value for each new subscriber. If the source is an HTTP call for example and one needs to get a new fresh value emitted, it can be achieved by chaining it behind another source that acts as a refresh trigger. With this approach, you cannot pull new values downstream from the source other than the initial value, so it needs to be triggered from upstream.

@JoshuaMorony

Жыл бұрын

The problem isn't that these problems are not solvable with RxJS - RxJS is a more powerful toolset so is generally going to be capable of more (and I tend to lean toward favouring RxJS). The problem is that these are non-obvious concepts if you are someone who is "just learning Angular", and if you don't understand the concept of hot/cold observables, shareReplay etc. you can run into trouble. So as a default learning experience for Angular, I think signals make a lot of sense.

This is very cool, reminds me of Svelte, but more robust

Thanks!

Friendship ended with RxJS, now signals is my best friend. just joking, but I like the concept of signals. Thanks for your video, Joshua, I'll learn about signals soon.

What I'm missing here is the fact that these two serve to a different purpose. All these "issues" can be solved with operators, and with Signals new issues will pop-up, just as with computed properties in EmberJS. I see them more like RxJS being data provider and Signals used to deliver this data. Anyway good video

Does angular have react query type of Solution?

Great video I would like to see a video on how Signals is able to achieve glitch free computation.

Is there a way to turn off zones in Angular 16 and use signals only?

@JoshuaMorony

Жыл бұрын

Not sure if the zoneless option will come in 16 or later (signals will just be developer preview at that point), you can probably expect to find some more info in the upcoming RFC

I have been going through several videos on your channel. And I have to say, the content is excellent! I have been using Angular for some time but I am relatively new to RxJs and Nx things. And it's hard to wrap my head around it. Do you have videos that explain these things in a very simple manner step by step? Or courses? The end goal would be creating enterprise applications where performance/speed is very good. Thank you so much! I will be going through more of your content!

Something that you did not mention(unless I missed it): an effect(() => {...}) created inside a component gets destroyed automatically when the component gets destroyed, unlike RxJS where you need to unsubscribe/takeUntil.

Could you avoid the double broadcast of combineLatest with a debounce operator (maybe if you anticipate sources updating "at the same time?"

@JoshuaMorony

7 ай бұрын

I think depending on the situation that might be a way of handling it - most of these problems are generally solvable in some way with RxJS, the main problem is that they are not obvious (as in it often won't be obvious to people that there is a problem in the first place - things like multiple subscriptions can easily escape notice but cause issues)

@jakehockey10

7 ай бұрын

​@@JoshuaMoronythanks for the response. Love your videos and really appreciate how much you're content aligns with what I ponder the most when developing with Angular

We used to use ClearCase, and everytime I suggest git, people will say, ClearCase has all the same features and lot more, just check the docs and learn it properly. Kind of same with RxJs. Simplicity is under appreciated.

I see the reason why a more capable primitive is needed, I just don't like all the other stuff piled on top of signal that rxjs already provides. The angular team should've work together with RxJS to fit their needs instead of yet another thing people need to learn. RxJS is low level, don't expect it to do the complex stuff and behavior you need from a signal out of the box from rxjs. but I fully believe a full featured signal can be created from RxJS building blocks. The one thing RxJS needs to change for this to happen is letting the content of a pipe be accessible synchronously, just like BehaviorSubject. It's not guarantee-able that a pipe has a value at the time of it's creation, but maybe another pipe function with a limited feature set could guarantee that. All I see is extra code shipped that serves the same purpose as something else already shipped.

@vnshngpnt

Жыл бұрын

I agree, it definitely seems like needless API surface increase. Either go full blown RxJS with correct implementations or switch to other primitives. Having both seems weird.

@diadetediotedio6918

Ай бұрын

@@vnshngpnt They both have different use cases, so it is not "weird" by any means.

from my perspective, Signals just adds yet another chunk of learning curve and complexity to what is arguably already the most complex, most difficult framework out there. If Signals could actually replace RxJS, that would be one thing, but they can't - as you said, they only cover a subset of what you can do with Observables. So you still need to learn RxJS if you want to build anything bigger than a todo list. What they should have done instead is either (A) solve the ergonomic problems with RxJS, or (B) go all-in on Signals as a total replacement for everything you can do with RxJS. Just throwing Signals into the mix only puts off the learning you will eventually need to do anyway to build something substantial with Angular. This doesn't feel like a serious feature - it looks more like a marketing ploy to ride on the success of newer frameworks that go all-in on Signals. This might temp people to onboard Angular, but will likely still lead to the same amount of bafflement and overwhelm when, inevitably, they will need to reach for RxJS for something and we're right back where we were before: still the most difficult framework there is.

5:00 it's not a problem, it's its behavior

The only thing I couldn't understand is why did you compare `computed` with `combineLatest`? I think it's not the equivalent of `computed` in rxjs world. If you'd like to update the base value after both observable's emission maybe you could use `zip` or something. What do you think?

Thank god. I was just beginning to learn RxJS and it was so difficult i quit for a bit. Now I"m going to learn Signals instead

In a weird way this helped me understand rxjs better

Actually combineLatest example may be incorrect: derivedValue going to emit 20 after valueOne.next(2), but it’s going to happen before valueTwo.next(20), so there not going to be “transitional value” in this case

@Uterr

5 ай бұрын

I mean you right about value going to emitted twice, but you are incorrect about having “transitional value”, you going have 20 to be emitted before .next(20)

Hello from vue and solidjs :D

I noticed most people struggle with observables when they try to learn Angular and is often the reason people switch to other frameworks like vue or react.

Actually - i like angular got signals a lot.. Good points - especially about rxjs and how it hinders angular adoption... it's always a pain to check all the rxjs code of beginners for all this stuff... signals will make development easier for so many...

NICE and brief explanation, thanks

RxJS and the concept of observables I think is the main reason new developers try to stay away from Angular. It is more of a new concept for most of us and you really need to learn it. Facing that big learning curve will surely intimidate devs who are new to Angular and will think Angular is full of shit and unnecessary complexities. I agree that it is a good thing to introduce Signals with Angular as it is way much simpler and straightforward. I use RxJS in all of my Angular projects for years now and I dont even utilize those complex operators in most of those projects(except for a few features and requirements). I find signals to be enough for my needs.

I have been using ngrx, gonna be interesting

@JoshuaMorony

Жыл бұрын

I haven't looked too closely yet but I know the NgRx team have been trying out some stuff with signals

4:50 you could use "zip" operator instead of "combineLatest" to avoid that problem. "zip" will wait for every stream to emit a new value before triggering

@timonkrebs6978

Жыл бұрын

Zip leads to other problems that signals simply do not have. If not all observables emit the same amounts of values this leads to nasty bugs. Signals solve all these problems without efforts of the devs!

@anarchoyeasty3908

Жыл бұрын

I'd also solve this by throwing a debounceTime pipe operator before that map with a small value, say 10ms. That way if valueOne emits then valueTwo emits it will wait until 10ms has passed between emitting, and use the latest value emitted.

@AlexAegisOfficial

Жыл бұрын

No that's not the problem he describes. We do want it to be working like combineLatest, emit whenever any of the streams change, but when both emits at the same time, emit only once.

@anarchoyeasty3908

Жыл бұрын

@@AlexAegisOfficial Yeah, the correct answer is to throw a debounceTime operator on there if you actually do want it to only emit once.

@timonkrebs6978

Жыл бұрын

@@anarchoyeasty3908 with debounceTime you will get into other problems. For example if the observables emit more than every 10 ms it will never emit... There simply is no equivalent way to solve the diamond problem like signals. All the solutions with rxjs are less capable than signals for this problem. There are valid usecases for zip and debounceTime but the diamond problem can not completely be solved with rxjs. At least not perfectly. You can get quite close with rxjs but the closer you get the more only rxjs experts will understand what and even worse why it was done...

This would be great for smaller and non-complext applications, while in enterprise RxJS will dominate, that's clear for all. The tools and control which you are provided with are just non-comparable to signals, besides that - I believe that they are great start for beginners.

@JoshuaMorony

Жыл бұрын

I think signals will be great for all applications, even those that use RxJS - imo it is preferable to use signals where there is no need for RxJS (simpler API + eventual change detection benefits), and then convert to RxJS wherever it provides a practical benefit. Likely predominantly RxJS applications will stick around for a long time in enterprise but mostly because they are large existing codebases that have a cost to migrate, I think we will see everything slowly move to signals though with RxJS where needed.

Fair enough

While I agree that signals are easier alternative, I want to mention that your example during the side effects can be simply fixed by using shareReplay(1) method, that way your log will only trigger once

Not being able to get the latest value emitted by an observable is probably my greatest annoyance with RxJS. Sure, it's not something you should ever need in a purely reactive codebase, but a lot of the time you are not coding fully reactive, and in those cases it sucks to not have this basic feature.

4:02 I dont believe you when you say that no intermediate value is generate when using signals. Please explain how this works.

Ok, I see signals are "glitchfree" but for our applications its okay to have those "glitches". The users can't see them and we love rxjs so we will stay with it. Once you got used to rxjs and it's power it immediately speeds up productivity and keeps the code very clean. Also I do not want to have a mix between signals und rxjs because it makes the code more complex 🤔

4:45 That is not a 'gotcha'. That's an extremely useful feature. It works exactly as it's supposed to. I hate when people call it a glitch or a bug... Of course, in _many_ cases that is a hindrance, and it needs to be solved with a debounceTime or something similar. But it's solvable. And sometimes it's exactly what you need. If signals can't work like that, that's a big negative. (Although we can just use RxJs and signals both I guess)

It's a pretty handy utility, but I already see the overuse of signals and even more complex components.

The upside is that signals are easier for the common cases and a "steep" learning curve is a no-go in web dev. Look at the effort it's taken for a type safe language to get traction because "it's harder". But even if it's a worse technical solution it helps w/the perception issue and DX matters. The downside is it gives even more of a reason to not understand the reified reactive paradigm since you only need to understand it for 'corner cases'. Devs will abuse signals, because that's what they know, and it won't be pretty. You'll be lucky if you have 1 guy that genuinely groks this stuff and they'll be hating life. Eventually some 'signal management' lib will be all the rage, until it isn't.

@JoshuaMorony

Жыл бұрын

It will certainly be interesting to see how it plays out - I don't think there is ever going to be any way to go about it that doesn't have significant drawbacks one way or the other. I think it is likely that a lot (most?) devs just won't use RxJS, even for the corner cases where it would be very beneficial. Will that code built with signals still be better than what is being built today (i.e. for those who aren't using RxJS in a reactive/declarative manner)? probably? I think the libraries will quickly offer signal implementations though.

Maybe its time for me to check Angular again after not using it since v8

@CodingAbroad

Жыл бұрын

You’ll be glad you did 😊

Signals seem to be pretty much what knockoutjs did many years ago. Feels kinda weird cause that's what I used before angular, til 2018, 2019 xO Still I can see its benefits.

Surely it's as simple as signals make synchronous code more simple, where rxjs is needed for async operations

@JoshuaMorony

Жыл бұрын

There is a reasonably popular position that rather than introducing signals into the framework, the "reactive primitive" should have just been BehaviorSubjects. This is a route that the Angular team could have gone down, but the specific point of this video is to outline why I think introducing signals was a good idea, even though it is this whole "new" thing.

Rxjs is a kind of tech either you really love or hate wholeheartedly. Personally, I have missed this Observable madness and hope one day I will come back to Angular land

I think with async operations there's no beating RXJS. Events, requests, timeouts are unpredictable and disorderly by design and RXJS makes managing this sort of code much better, if anything for the sheer amount of tools RXJS gives you for it. But I always felt that if you need some value that you can "subscribe" to in multiple places in the application, a subject seems over the top. But I don't know if there's any overhead for using a subject, it just seems that signals are simpler.

Worked with RxJS in the past, then stores in svelte and now finally signals have arrived. Functional programming is generally a good idea but was never a fan of RxJS overcomplicated and unintuitive concept. Big fan of clean code principles like KISS. And that's what svelte and angular signal does.

Cannot wait for signals. Awesome. Bye bye zoneJS

And there are not memory leaks with signals.

Even though you raised a lot of good points, you still didn't even mention the very point of signals - making an Immedient surgical change in the UI without the need of change detection. (At least that was my understanding of it)

@JoshuaMorony

Жыл бұрын

My other signals video covers more of the "why" of signals in general, this one is just specifically about the choice to use signals as the mechanism instead of subjects - I'm not sure how it would have played out, but the Angular team could have gone for a zoneless style change detection with subjects as the reactive primitive instead of signals.

@ShaharHarshuv

Жыл бұрын

@@JoshuaMorony it wouldn't be "change detection" but yeah

@JoshuaMorony

Жыл бұрын

​@@ShaharHarshuv it's still change detection, but it's not "dirty checking" as a form of change detection (i.e. where Angular dirty checks the entire component tree to detect changes), instead signals are the form of change detection (which as you pointed out is more "surgical" and specific to just the view that has actually changed)

I wish RxJS would just not use the plain Observable as an abstraction for everything. Other FRP approaches embrace the difference between signals (reactive state), flows (discrete streams without state) and tasks (producers of just a single value). Yes, we now have this holy trinity in the shape of Signals, Observables and Promises, but these three things all come with their own rules and syntax and require conversions to be used together.

I've learned a lot (everything) about RxJs watching your videos... Now that I understand 30% about it, Signals appears in the picture 😥

While all these are good points... The real question some developers like me have is NOT 'why can't the developers use behavioursubject instead of signals'. it's "Why doesn't ANGULAR team create their own version of signals with behaviour subjects and mitigate the gotchas of rxjs, and give us a clean signals like feature which we can use without worrying about using new rxjs operators, subscription or unsubscription etc. They found something better than rxjs and instead of doing a bit of extra work to add those benefits with the existing tools they have, they simply decided to add it to angular and leave the learning part to the developers... One of the issues already with Angular is that it's too hard to learn, this adds to it deterring new adopters even more....

IO ♥ Rxjs

Fun times ahead with more friction with state management justifiable with signals and side effects. Hopefully, this brings the community together and avoids class files with 40 mutated values in them, right? Nobody still? Ok cool.