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.
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.
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.
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
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)
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!!!
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.
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.
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.
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.
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.
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🎉
> 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?
@@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.
@@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.
@@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.
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!
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
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!
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.
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 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...
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?
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
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.
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.
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
The change detection problem in Angular is not so easily fixable with RxJS. The signal implementation, with its reactive graph, brings enormous benefits to Angular in terms of performance that could not be achieved with RxJS. Angular needed a reactive primitive for that could be custom built for the framework itself. RxJS is still, of course, the way to go to manage complex async behavior, but signals are the best way to manage and read state in Angular. They solve two different problems and the each solve their respective problems very well.
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...
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.
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.
Though to be fair. All "problems" listed in this video were never real problems. Both me and many fellow devs I know love how exquisite the tools from RxJS are, and how you can design a really fine-tuned pipes using RxJS . However I can definitely see how people might run into those issues, if they didn't have a good understanding of RxJS and their marble diagrams. To me RxJS is still much more advanced, comprehensive and has much more to offer. However I can also see why some developers might prefer a simpler solution to solve an easy task such as tracking or updating the reactive state.
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
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)
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.
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)
@@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
Thats exactly the video i needed to understand the purpose of these signals, thanks !
Год назад
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!
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.
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
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.
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.
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?
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.
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.
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: ruclips.net/video/HstDoVQeP9g/видео.html
For the multiple subscription problem, the solution to this is rather easy. It just requires some thinking (and yes, I know that Signals means you don't have to do this thinking) I would refactor that code into having three sections. Source Observables, State Observables, and Selector Observables. Count$ would be a source observable. I would make that observable private so you cannot access it from the template. The State observable would pipe together all of the source observables into a single object observable that represents the state of the current object. The state observable is public, and should only be subscribed to once at the top of the template making it available through the entire template. DoubleCount$ would be a Selector template, and it should pipe off of State$ not off of Count$. public DoubleCount$ = this.State$.pipe(map(state => state.Count * 2)). Then when you need to sub to DoubleCount$ you can do so throughout your template as needed. Maybe throwing a distinctUntilChanged operator in the pipe of DoubleCount$ if state contains enough fields that it becomes worth it. I have used this basic pattern multiple times throughout a rewrite of my old companies application. I trained my entire team on RxJS and how to think reactively. Every time they followed this basic reactive architecture the code we wrote was easy to reason about, easy to write, and easy to maintain. There were a few times when I was distracted with other work that a few of my team members would think of this reactive architecture isn't needed and would try and do it a different way. And every time it ended up spaghetti code. And I would eventually see it, reintroduce them to the reactive architecture and then rewrite their entire code in way fewer lines with way fewer bugs.
@@JMMedinaDev it's not about optimization it's about the fact that you will never just have the one piece of state in a component / page of any size and this architecture is designed to scale to manage state and complexity.
I agree with you in general about reactive/declarative architecture, and yes most problems I've mentioned in the video are solvable *if* you've taken some time to *really* learn RxJS, which is not easy. I think it would be very off putting if basic intro to Angular type stuff was filled with "* make sure not to do X because it will cause Y, to prevent that we can use operator Z, or do ABC" etc. Whilst I would love for everyone to just go down the reactive/declarative path, I think your comment highlight why that isn't going to happen. "There were a few times when I was distracted with other work that a few of my team members would think of this reactive architecture isn't needed and would try and do it a different way" - even with someone having explicitly trained them, you still have a team that is tending back toward imperative programming. This is what most people find more natural and what they want to do. So, I think it makes more sense to have a reactive primitive that works well in an imperative world, rather than trying to force people into a more declarative style that they don't want to use and is ultimately going to lead to more issues because the concepts are more complex.
@@anarchoyeasty3908 the way I see It , its way more simpler. If you have a tool , simpler and robust, to handle Sync reactivity, you should use it instead to try to workaround an async reactivity tool. For example, they probably doesnt stick to rxjs in reactive forms in next releases, AbstractControl probably ends up being a Signal , It makes so much sense.
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
excuse me but what's keeping you from using another pipe and tap on the original BehaviorSubject as opposed to what you said "you have to subscribe to the observable produced by the pipe? i'm not a RxJs expert so i'd appreciate your reply
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)
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.
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.
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
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.
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.
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.
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.
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.
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!
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.
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....
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.
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.
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...
5:05 Why is this even a problem? I'm sure that you are aware that the zip and withLatestFrom operators exist in RxJS which easily solve this problem, and that this is the expected behavior of combineLatest. Using signals as a "fix" just looks like overengineering.
withLatestFrom has the exact same problem as combineLatest(and zip does a completely different thing). It can be fixed with debounceTime, but not always/not completely, and you should not need to add such hacks every time you need a derived value. With signals - it just works. Of course, you may want it to behave like combineLatest in some cases, but usually you don't.
The average developer would have spent about 5 6 years learning the patterns of rxjs as well as its drawbacks and glitches. But now: time to throw that out the window and wait for some state management that uses signals instead of ngrx and refactor that. It's good. I make more money, I sound smart and trendy by using the latest trends, its all the dream of any developer 😂.
5:26 do you mean observables are "too much reactive" here? It seems that right after calling this.valueOne.next(2) the combineLatest executed. Am I correct?
I'm not sure I'd use the same phrasing but yes that is the situation (not necessarily always a problem) - even if we update two values immediately after each other, the stream will emit as soon as the first value is nexted and then again when the following value is nexted
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.
Kya Faaltu ka Framework hai... Jo applications already ban chuke hai usme bhi kya Signals add karne jaayenge?? Aur jitne bhi naye applications ban rahe hai usme bhala Angular kon use karega?
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.
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)
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 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)
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.
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
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
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.
Right on the nail
why not to use signal for services though? It looks like signals simplify a lot of what observables do, while achieving the same goals?
@@anantmishra6783You can.
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.
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.
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
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)
@@JoshuaMorony Where RxJs is preferable is exactly what I miss in your Clip.
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!!!
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.
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.
@@JoshuaMorony Thank you for clarification!
Great comprehension, no shit talk just real coding and explanation, I liked it much.
This video did a better job for me of explaining signals than the dedicated one! Thanks!
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.
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.
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.
TIL that ClearCase exists... But RxJS and Signals solve two fundamentally different problems so this is a false equivalency
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.
There will be! The "fromObservable" and "fromSignal" APIs already exist and will be included in an rxjs-interop package
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🎉
> 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?
@@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.
@@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.
@@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.
its a fireship ripoff
When I turn on subtitles, some code below got hidden beside it. Please keep the code up. Thanks. Nice video with great explanation
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!
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
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!
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.
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.
@@AlexAegisOfficial Yeah, the correct answer is to throw a debounceTime operator on there if you actually do want it to only emit once.
@@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...
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?
Alternative is using the async pipe. Manual subscription should be avoided as you have to manually unsubscribe as well which is more code
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
@4:02 Can you please explain, when exactly the derivedValue is computed?
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.
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.
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
The change detection problem in Angular is not so easily fixable with RxJS. The signal implementation, with its reactive graph, brings enormous benefits to Angular in terms of performance that could not be achieved with RxJS. Angular needed a reactive primitive for that could be custom built for the framework itself. RxJS is still, of course, the way to go to manage complex async behavior, but signals are the best way to manage and read state in Angular. They solve two different problems and the each solve their respective problems very well.
Excellent explanation. The simpler, the better. You don't have to be a specialist to write good apps.
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...
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.
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.
5:00 it's not a problem, it's its behavior
Though to be fair. All "problems" listed in this video were never real problems. Both me and many fellow devs I know love how exquisite the tools from RxJS are, and how you can design a really fine-tuned pipes using RxJS . However I can definitely see how people might run into those issues, if they didn't have a good understanding of RxJS and their marble diagrams. To me RxJS is still much more advanced, comprehensive and has much more to offer. However I can also see why some developers might prefer a simpler solution to solve an easy task such as tracking or updating the reactive state.
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
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)
Great info Joshua! Thank you for clarifying signals with real examples vs RxJS. It looks they are easier
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.
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
Could you avoid the double broadcast of combineLatest with a debounce operator (maybe if you anticipate sources updating "at the same time?"
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)
@@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
Very nice description with the practical code examples. Nice one! Thanks!
Thats exactly the video i needed to understand the purpose of these signals, thanks !
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!
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.
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
Very good and informative. I'm looking forward to getting stuck in to Angular 16
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.
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.
@@vnshngpnt
They both have different use cases, so it is not "weird" by any means.
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?
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.
Best explanation for signals I found on youtube 👏
I wonder how I can separate the changes in the effect, when which "signal" or "computed" has changed?
Thank you very much for this video! Things like that will make it a lot easier to explain why we should switch to signals.
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.
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: ruclips.net/video/HstDoVQeP9g/видео.html
on what basis did computed() wait for both values to be updated before computing. the changeValues() funciton to complete?
For the multiple subscription problem, the solution to this is rather easy. It just requires some thinking (and yes, I know that Signals means you don't have to do this thinking)
I would refactor that code into having three sections. Source Observables, State Observables, and Selector Observables. Count$ would be a source observable. I would make that observable private so you cannot access it from the template. The State observable would pipe together all of the source observables into a single object observable that represents the state of the current object. The state observable is public, and should only be subscribed to once at the top of the template making it available through the entire template. DoubleCount$ would be a Selector template, and it should pipe off of State$ not off of Count$. public DoubleCount$ = this.State$.pipe(map(state => state.Count * 2)). Then when you need to sub to DoubleCount$ you can do so throughout your template as needed. Maybe throwing a distinctUntilChanged operator in the pipe of DoubleCount$ if state contains enough fields that it becomes worth it.
I have used this basic pattern multiple times throughout a rewrite of my old companies application. I trained my entire team on RxJS and how to think reactively. Every time they followed this basic reactive architecture the code we wrote was easy to reason about, easy to write, and easy to maintain. There were a few times when I was distracted with other work that a few of my team members would think of this reactive architecture isn't needed and would try and do it a different way. And every time it ended up spaghetti code. And I would eventually see it, reintroduce them to the reactive architecture and then rewrite their entire code in way fewer lines with way fewer bugs.
Dont fall to the trap to optimize what shouldnt exist in first place.
@@JMMedinaDev it's not about optimization it's about the fact that you will never just have the one piece of state in a component / page of any size and this architecture is designed to scale to manage state and complexity.
I agree with you in general about reactive/declarative architecture, and yes most problems I've mentioned in the video are solvable *if* you've taken some time to *really* learn RxJS, which is not easy. I think it would be very off putting if basic intro to Angular type stuff was filled with "* make sure not to do X because it will cause Y, to prevent that we can use operator Z, or do ABC" etc.
Whilst I would love for everyone to just go down the reactive/declarative path, I think your comment highlight why that isn't going to happen. "There were a few times when I was distracted with other work that a few of my team members would think of this reactive architecture isn't needed and would try and do it a different way" - even with someone having explicitly trained them, you still have a team that is tending back toward imperative programming. This is what most people find more natural and what they want to do. So, I think it makes more sense to have a reactive primitive that works well in an imperative world, rather than trying to force people into a more declarative style that they don't want to use and is ultimately going to lead to more issues because the concepts are more complex.
@@anarchoyeasty3908 the way I see It , its way more simpler. If you have a tool , simpler and robust, to handle Sync reactivity, you should use it instead to try to workaround an async reactivity tool. For example, they probably doesnt stick to rxjs in reactive forms in next releases, AbstractControl probably ends up being a Signal , It makes so much sense.
What does the lifecycle on an edict look like when you can code a procedure directly in the class? All code in constructor?
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
excuse me but what's keeping you from using another pipe and tap on the original BehaviorSubject as opposed to what you said "you have to subscribe to the observable produced by the pipe? i'm not a RxJs expert so i'd appreciate your reply
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?
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)
4:02 I dont believe you when you say that no intermediate value is generate when using signals. Please explain how this works.
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.
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.
Thanks! and no I'm not familiar with that library
Is there a way to turn off zones in Angular 16 and use signals only?
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
Really eye opening. Thanks a bunch.
Excellent presentation Josh ! There is a real hype around these Signals and it can only lead to better DX 🙂
In a weird way this helped me understand rxjs better
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.
Very nice explanation. Thank you
Thank you for posting this!
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.
Great video I would like to see a video on how Signals is able to achieve glitch free computation.
Does angular have react query type of Solution?
Thanks, Joshua!
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.
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.
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.
Great explanation, thank you!
Thanks mate for an awesome video. I think rxjs is awesome and I really looking forward to signals as well.
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!
My understanding is signals is for synchronous work only so we’ll still have to be using rxjs at least for the asynchronous work
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.
@@JoshuaMorony Cristal clear answer, thank you!
Hi Josh, is v16 published somewhere?
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....
thanks. It was very clear!
Grate explanation!
This is very cool, reminds me of Svelte, but more robust
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.
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.
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...
Will explained! Thanks again for the quality of your content 🔥🔥
5:05 Why is this even a problem? I'm sure that you are aware that the zip and withLatestFrom operators exist in RxJS which easily solve this problem, and that this is the expected behavior of combineLatest. Using signals as a "fix" just looks like overengineering.
withLatestFrom has the exact same problem as combineLatest(and zip does a completely different thing). It can be fixed with debounceTime, but not always/not completely, and you should not need to add such hacks every time you need a derived value. With signals - it just works. Of course, you may want it to behave like combineLatest in some cases, but usually you don't.
The average developer would have spent about 5 6 years learning the patterns of rxjs as well as its drawbacks and glitches. But now: time to throw that out the window and wait for some state management that uses signals instead of ngrx and refactor that. It's good. I make more money, I sound smart and trendy by using the latest trends, its all the dream of any developer 😂.
Maybe its time for me to check Angular again after not using it since v8
You’ll be glad you did 😊
Practical video :) love it!
Brilliant Stuff!!
Great job!
Love your videos !
5:26 do you mean observables are "too much reactive" here? It seems that right after calling this.valueOne.next(2) the combineLatest executed. Am I correct?
I'm not sure I'd use the same phrasing but yes that is the situation (not necessarily always a problem) - even if we update two values immediately after each other, the stream will emit as soon as the first value is nexted and then again when the following value is nexted
Simple and effective super and well explained
Nice Explained
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.
Hello from vue and solidjs :D
Really good video :)
Kya Faaltu ka Framework hai...
Jo applications already ban chuke hai usme bhi kya Signals add karne jaayenge??
Aur jitne bhi naye applications ban rahe hai usme bhala Angular kon use karega?
Thanks!
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.
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)
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.
@@JoshuaMorony it wouldn't be "change detection" but yeah
@@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)
Surely it's as simple as signals make synchronous code more simple, where rxjs is needed for async operations
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.
I have been using ngrx, gonna be interesting
I haven't looked too closely yet but I know the NgRx team have been trying out some stuff with signals
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
It's a pretty handy utility, but I already see the overuse of signals and even more complex components.
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