Would like more if signals can also take care of the asynchronous values. No point in converting from observable to signals or vice versa. This makes things more complex.
0:49 isn't calling a function in a template (as in count() and double()) something bad in newer Angular versions? (performance issues). I got told Angular calls these a lot of times because of how it works internally, for rendering purposes (and can be an issue with functions that do a lot of stuff). Maybe it's not really an issue?
Wow man honestly such a great and informative video. I‘m using Angular now for the past 2 years but I‘m not constantly evolving my skills and therefore I miss out on new topics like this. I‘m really considering taking your Angular course because the way you explain things is incredibly good, in my opinion at least. I hope that someday I‘ll become a professional Angular developer as you are, you‘re an inspiration for me and my career
@@JoshuaMorony Indeed the depth of your knowledge in Angular concepts is amazing. I have been working with Angular for the past 2 years too. But most time I wonder what I have to study next, I usually feel I'm lacking concepts in my angular knowledge. Please can you mentor me in Angular. Or have just 1 one on one session (Paid if necessary) to orient me on my study path to be among the best angular devs around
This helped me come around to the concept of signals. Initially, my reaction was that signals just looked like angular becoming more like but it’s really cool to see the integration between how they will work with RxJs, which I happen to love!
This looks very much like VueJS composition api. Syntax for computed is exactly the same. And the rest is quite easy to translate Angular: count = signal(0) Vue: const count = ref(0) Angular: this.count.set(5) Vue: count.value = 5
Great explanation. Seems like Signals are gonna be implemented in most all the JS frameworks, and for Angular seems simpler than RXJS(I love it!) to start working on a new project.. Great work Joshua!
I really enjoy the 'think about it' aspect of your videos. The context that shaped the solution as well as the alternative solutions/consequences really drives the ideas home. So many channels are either too "blue collar" 'how to use api x to solve problem y' or the completely opposite academic 'solutions' that sound great but can't be demonstrated in practice ("you'd need a large/complex system to see the benefits" is the usual hand-wave. I'm looking at you microsevices and OOP)
Great explanation. It's been a few years since I've used Angular (have been in the React world for a while now) but this gets me excited about building with Angular again.
Promises give a single value over time Observables give several values over time Signals give several values over time but do not require subscriptions. Signals feel like observables that dont need subscriptions while also feeling like promises in the way others handle the data. Very interesting! You've posed several videos about how to "never subscribe" and Signals will make many of those "forced to subscribe" situations way easier to handle.
This is great news for the Angular community, I really hope that this takes the Angular team to work heavily on how signals and rxjs integrate, and then to continue imporiving how rxjs integrates with Angular ecosystem
exciting! zonejs is also been hard in the angular libraries that rely on canvas tag , for example angular-three, the function request animation change also triggers zonejs, followed by running change detection on entire component tree, serious performance issue unless manually running that method outside of zonejs this is much needed for angular
VERY looking forward to this! Indeed signals are not going to replace observables entirely but I can finally see Angular starting to embrace a modern approach to event management without being excessively verbose! Very cool video as always BTW
Great explanation, Josh. I love RxJS but there are times I wish I could just use the value of an Observable in a component without subscribing. This looks beautiful.
Awesome, straight to the point. Can't wait for signals now 😉. Initially thought it was going to replace RxJs's BehaviourSubjects but now I feel quite confident that Angular is about to experience some kind of renaissance!
This reminds of of Signals and Slots in QT. I've built stuff in QT off and on since 2007. KDE is built on it. The Signals/slots model is kinda like pub/sub but smarter. JS is basically a hack at this point though, so I have been wondering if this is even possible without workers. Nice vid.
What's the difference in performance between the signals change detection strategy and the current OnPush change detection strategy when using only observables and not triggering change detection manually?
Conceptually, A signal enables auto-tracking on Signal Read (eg: calling the signal function to get the current signal value). Imagine Components/Directives, the Template etc... have a "Reactive Context" where they can track Signal read, we could possibly have per-view/per-component Change Detection, combined with Angular's effective incremental DOM algorithm, the perf boost would be awesome. The current Change Detection would still trigger change from the root ApplicationRef so in a sense, your whole component tree is subject to be checked. OnPush Component prevents its subtree to be checked further but we still have a lot of unncessary checks. Signals w/ a "potential new CD Strategy" would help with this.
Hey Josh, thank you as always for the great explanation. Just as a small suggestion/request, it would be awesome if you could link some of your sources of information so that people watching your videos can deepen their understanding about them. Keep up the good work and thanks again!
I don't use signals, but I am still very much looking forward to having them in angular. You guys have such a rich history w rxjs, it's gonna be very interesting to see the patterns you will create with it and signals. I think it could really revive rxjs in other signal-using frameworks too, or bring life into other async reactivity solutions. Cool stuff!
I love this, would be really exciting to see reactive inputs in Angular! The current way of passing the value of an input to a subject through a setter just feels so clunky.
@@MiuBrothersOfficial I would assume so eventually yes, I can't see any need for ngOnChanges - if we have an input that is a signal and we want to do some kind of side effect equivalent to using ngOnChanges we could just define an "effect" and any signals we use in that effect (including the input) will automatically trigger that effect whenever they change
I am astonished how quickly you transform from a convinced Rxjs coder to a Signal Evangelist. Signals will wishiwashy Angular as Standalone components already do!
This doesn't change the justification for RxJS at all for me - RxJS is required (or something else that covers the same use cases it does) if you want to code declaratively and handle async reactivity. The only difference is that I would have also used RxJS for all sync reactivity as well, but if there is a framework primitive that can handle sync reactivity more easily that also interops with RxJS then it doesn't make much sense to me to not adopt it.
Thank you Josh for sharing this ! Do you know which angular version is expected to bring this change? I'm currently on angular 12 and I don't want to upgrade until it's a major new release. This one seems like a major shift. Also, I agree with the 2 styles out there. I started Angular 2.0 in 2015 when it was just released. I learned it the way google guys talked about it, meaning the simple way. When I tried the push strategy way, it felt like a huge pain to achieve simple behaviors, particularly in small apps where there aren't that many components and not a lot changing overtime. Hopefully signals won't wash away the simplicity of the imperative style.
"Signals" are the implementation of the Command pattern. But making the RxJS optional or excluding it completely would be a revolutionary change for Angular making it lighter, faster and competitive framework. We already have zone-less Angular, now we need RjJS-less Angular.
Great video. Very informative. Do you think Signals would be a good replacement for NgRx for state management? Would Signals trigger change detection between different components? I have know angular since v2 and despite all of those years I have not effectively used NgRx yet.
It won't be a video course, but I am working on a course that will incorporate all the new Angular goodies and teach the typical reactive/declarative style I advocate for
I think my biggest hurdle to move from imperative programming to declarative was the fact that I had to trust all those weird bits and bobs like observables, subjects, transform functions etc to do their job. And I had to learn, by heart almost, what each of them do. Once it clicked I never looked back, but it took some time to understand things like why some value is not updating even though I am subscribed to the observable (turned out it was hot/cold observable issue). And I had no idea how I could even start debugging it, because of hidden abstraction layer.
Really like this Video. But there are even more benefits that result from using signals. The main benefit beeing syncronisation and memoisation. I think this will be the change that makes Angular rise again in popularity a lot.
They are yet to be implemented, and the current prototype still relies on Zone.js, but yes the idea is that signals will eliminate the need for Zone.js (but Zone.js will still be an option for code that does not use signals)
Just to make sure I understand, so "imperative" means using "synced" values (not observables) and counting on change detection to make your view reactive, but that's a problem because you can't use RxJS to create new state that is reactive on your "imperative" state, so you need to switch to a behavior subject? (which is the reactive declarative?)
I would say it's a bit different to that - you can still using synchronous values/mechanisms and be reactive/declarative. It's better to think of imperative and declarative as being the opposites - but something can be reactive and imperative (e.g. using an observable subscribe or other mechanism to "imperatively" reassign/update a value after it has already been declared), or it can be reactive and declarative (e.g. using an observable/signal to define what something is once in the declaration and how it reacts to changes, and never imperatively reassigning that value).
Mix and match RxJs with Signals: In Rxjs style you use a creation observable to enter Rxjs world and you stay in Rxjs world to compose with any other Observable you need. When you have done all your transformations in RxJs world (pipe) then you subscribe and come back into Javascript land. In between Signals are useless because not composable to be composable it needs to be an Observable!
At the begging I was ignoring this announcement since did not make much sense to me, but after seeing your video I wonder if this will integrate well with ngrx too, are we gonna parse all selectors into signals in the component? 🤔
Probably, it's hard to say now but I can't imagine this not becoming something that takes over completely. I know Brandon Roberts has already been toying around with integrating signals into NgRx.
In the intro you speak very explicitly about zone.js. But you don't mention it with the use Signals (as long if I didn't miss it). Will there be any change?
Yes, eventually. For now the prototype of signals still relies on Zone.js, but the Angular team is aiming to make Zone.js optional with a signal based approach at some point
Will a value that uses the "computed" function still act as a signal itself? Can you chain multiple "computed" values similarly to how we can chain multiple observables? I'm trying to find the line to draw where Observables should be used over Signals.
Yes, you can chain computed signals in the same way that you can with observables. I like to think of "the line" being async reactivity - if you don't need to explicitly handle async reactivity use signals, if you do use RxJS
Surely, NG team will not rewrite forms, httpclient and router into signals, or I just can't imagine how would this work. By the way, are signals pipeable in any way? Or should we declare a new variable for each 'step'?
As in pipeable with RxJS operators? In the current implementation no, you would have to convert to an observable first, pipe, and then convert back to a signal. Personally, I'm hoping for the addition of some kind of "pipeable signal" or just a "pipe" method that will handle this signal -> observable -> signal conversion for you and pass in the operators to pipe to the observable.
@@JoshuaMorony I literally just finished programming my own signals and then ended up watching your video (no kidding), what a timing. In my case it ends up being a parameterless function which when invoked returns the current value (imperatively), but which you can pipe and subscribe to directly (it literally has the pipe and subscribe method). I can even use them inside rxjs operators (like takeUntil) or use the async pipe in the templates thanks to the fact that rxjs provides a way of interop using a symbol.
If they are working on the signals I think they'll also consider 'computeds', their API is orders of magnitude better than NGRX's selectors since you don't need to tell it which other selectors it depends on, they are automatically detected when running, which also provides better ways of memoization as well as better strategies to how/when to recalculate them.
What about when we get to Signals and the Angular team dicedes to remove zone.js what will happen to old projects? that will make a big thing to migrate to Signals or Am I thinking wrong?
Zone.js is here to stay for a while, at least until all of Google's Angular applications move away from Zone.js. In the mean time, Signals enables optional Zons.js aka in new projects, zone.js is not needed for perf boost and lower mental overhead
I've been using Angular since version 2 and I never wanted to incorporate RxJS. I mostly use promises and it works fine, all async operations I work with are "wait for a single result", to me it never made sense to use observables and behavior subjects. The 2 async operations my programs use: HTTP Requests, Wait for modal window response. My angular applications don't use impure filters
This blog has an interesting breakdown of overall Angular jobs and where to find them (overall, it's pretty close to React): www.devjobsscanner.com/blog/the-most-demanded-frontend-frameworks-in-2022/
Possibly less Angular jobs in your area may also mean less Angular devs in your area to compete with. In the React world there are more jobs but you're also competing against WAY more React devs.
Definitely plenty of inspiration and collaboration going on with other frameworks for this - the public facing API will likely end up looking pretty similar to other frameworks, but still a lot of work required behind the scenes to get it all working with Angular
I'm glad to see Angular adopting new ways of doing things, first standalone components, now this, it will definitely make the lives easier for the new developer especially, although I think Angular is on a bad word so it isn't getting many new developers anyway...
@@RaVq91 what, I hate jsx and I'm pretty sure most angular dev do as well, can you explain why do you think this would be a "rescue" for angular. imo angular templates are far better than any other frameworks
@@nerminkarapandzic5176 Just first few things coming out of my head: hot module replacement - no need to reload the whole page and loose its state (values in inputs, etc), go to definition feature, find all references feature, rename of component will update names and imports in usages, typesafe components api even while writing its markup, easy way to create wrappers that exposes all the apis of wrapped component (not by rewriting all props by hand), full power of JS while writing views instead of html only.
Frankly speaking I don't understand the benefits. We can already have a synchronous reactive code using rxJs. The angular team can create a linter which will help to prefer using async pipe over the regular properties and also try to get rid of zone, when the reactive approach becomes default. Looks like they want to introduce the signal primitive to force developers write code in a reactive way. But do we really need one more feature in angular which actually looks and works like "rxjs lite"?
The problem I'd to use RXJS you have to understand it almost expertly or you'll shoot yourself in the foot very badly, and unfortunately RXJS and Reactive Thinking are not just something you read about and get instantly for most people, you have to study and eventually your brain clicks. So you have to do all that and still learn Angular. At least with this you can on a surface level or within a couple minutes of reading docs get it and use. Signals will also highlight situations where RXJS is the best solution when people try and fail without it.
@@TayambaMwanza Totally agree. The library itself is great, but the learning curve is VERY painful. That's why I think other frameworks will take over Angular, because they are easier to learn :(
@@Dimonina So if Angular became easier to learn it would put it in a better position right? Which is what I think the team is doing, already seeing more people talking about Angular in a positive light than usual even from across the Isle. Then there was that post where for some reason since November Angular job postings have increased Dramatically
Very interesting topic, thanks for bringing light on that. For me personally it`s look like a Vue 3 maybe because of the computed keyword ;) Definatelly It will be interesting to see how this will affect the whole Angular ecosystem :)
I'm not too familiar with Vue's implementation but these ideas across Vue/Solid/Knockout and now Angular are all quite similar in concept, and the APIs just about the same, just the underlying implementations are a bit different. It's certainly not a new or novel idea.
I'm not too familiar with Vue's implementation but these ideas across Vue/Solid/Knockout and now Angular are all quite similar in concept, and the APIs just about the same, just the underlying implementations are a bit different. It's certainly not a new or novel idea.
It's amazing that Angular got this only just now, when other frameworks have had such features since their inception (Vue JS, Svelte.etc.). And based on what you're showing here, their syntax is still vastly superior to Angular's.
Can you do a video on the applications of RxJs on Backend stuff, ive already started using it for websockets and anything stream related. As the Rxjs wizard in UA-cam you can give some ideas
RX has a huge problem when using it on server said it's persistence and distribution. An interesting example of RX approach to stream processing is Microsoft Trill.
Yea can't wait to debug code some other inept dev wrote by wrapping some http request in a signal thinking they'll skip learning rxjs. I see signals as maybe 10% being used for exactly those immediate reactivity cases.
Thank you, but I would rather use Svelte for my next project Angular is not ahead of the curve anymore. It's catching up the others Angular dev is saying
It does look similar, but the underlying ideas are quite a bit different. This is a good explainer on the difference: www.builder.io/blog/usesignal-is-the-future-of-web-frameworks
hmm... looking more like KnockoutJS each iteration. I really miss the observable, computedObservable and the often underappreciated change detection mechanism. You just had to patch in Promises, Typescript, and a decent router. In someways, it was before it's time.
Join my mailing list for more exclusive content and access to the archive of my private tips of the week: mobirony.ck.page/4a331b9076
It's amazing, looking forward to see RxJS + Signals combo on in your future videos 🙏
Thanks Joshua!
Me too, can't wait to play around more!
Would like more if signals can also take care of the asynchronous values. No point in converting from observable to signals or vice versa. This makes things more complex.
Or even better - signals without RxJS.
I enjoy Josh's way of simplifying concepts and sharing of tips & tricks in Angular. I highly recommend!
0:49 isn't calling a function in a template (as in count() and double()) something bad in newer Angular versions? (performance issues).
I got told Angular calls these a lot of times because of how it works internally, for rendering purposes (and can be an issue with functions that do a lot of stuff). Maybe it's not really an issue?
Wow man honestly such a great and informative video. I‘m using Angular now for the past 2 years but I‘m not constantly evolving my skills and therefore I miss out on new topics like this.
I‘m really considering taking your Angular course because the way you explain things is incredibly good, in my opinion at least.
I hope that someday I‘ll become a professional Angular developer as you are, you‘re an inspiration for me and my career
Thanks for the kind words!
@@JoshuaMorony Indeed the depth of your knowledge in Angular concepts is amazing. I have been working with Angular for the past 2 years too. But most time I wonder what I have to study next, I usually feel I'm lacking concepts in my angular knowledge. Please can you mentor me in Angular. Or have just 1 one on one session (Paid if necessary) to orient me on my study path to be among the best angular devs around
This helped me come around to the concept of signals. Initially, my reaction was that signals just looked like angular becoming more like but it’s really cool to see the integration between how they will work with RxJs, which I happen to love!
This looks very much like VueJS composition api.
Syntax for computed is exactly the same. And the rest is quite easy to translate
Angular:
count = signal(0)
Vue:
const count = ref(0)
Angular:
this.count.set(5)
Vue:
count.value = 5
I was thinking exactly the same. Would even go further to bring React Hooks into this as this looks like VueJS composition
Great explanation. Seems like Signals are gonna be implemented in most all the JS frameworks, and for Angular seems simpler than RXJS(I love it!) to start working on a new project.. Great work Joshua!
I really enjoy the 'think about it' aspect of your videos. The context that shaped the solution as well as the alternative solutions/consequences really drives the ideas home.
So many channels are either too "blue collar" 'how to use api x to solve problem y' or the completely opposite academic 'solutions' that sound great but can't be demonstrated in practice ("you'd need a large/complex system to see the benefits" is the usual hand-wave. I'm looking at you microsevices and OOP)
The best channel about angular I even know! Love you so much!
First time watching your content , and .... subscribed!
Great explanation. It's been a few years since I've used Angular (have been in the React world for a while now) but this gets me excited about building with Angular again.
Thank you Josh, for keeping us all on the cutting edge!
Loved how you related this to rxjs. Exactly what I wanted to see. Thank you
Promises give a single value over time
Observables give several values over time
Signals give several values over time but do not require subscriptions.
Signals feel like observables that dont need subscriptions while also feeling like promises in the way others handle the data. Very interesting!
You've posed several videos about how to "never subscribe" and Signals will make many of those "forced to subscribe" situations way easier to handle.
You missed the part that signals are not async
Signals are asynchronous.
Thanks for the updates as always Joshua!
Great Video. Was waiting for a video to explain signals easily :D
This suppose to be a pretty complex subject but your explanation is really good and make things much easier to understand. Thanks...
This is great news for the Angular community, I really hope that this takes the Angular team to work heavily on how signals and rxjs integrate, and then to continue imporiving how rxjs integrates with Angular ecosystem
Funny enough react doesn't want to implement right now
Great explanation! I love the "imperative force field" analogy
Imperative code trying to mess with your declarative code: ua-cam.com/video/xrg-RgF5F8o/v-deo.html
Love it ❤️
Best video for signals
exciting!
zonejs is also been hard in the angular libraries that rely on canvas tag , for example angular-three,
the function request animation change also triggers zonejs,
followed by running change detection on entire component tree,
serious performance issue unless manually running that method outside of zonejs
this is much needed for angular
Thank you! It's looks like react state change.. very good
I too think this is a GREAT move by the Angular team.
It will also make it easier to bring in new engineers and help Angulars image.
I CANT WAIT TO START USING THIS AND I LOVE RXJS!
VERY looking forward to this! Indeed signals are not going to replace observables entirely but I can finally see Angular starting to embrace a modern approach to event management without being excessively verbose! Very cool video as always BTW
That is just awesome. Waiting for this feature
That'd be wonderful. Thanks for the video.
Liked, left a comment and subscribed! 🍻
This video is awesome and very informative. thank you so much
Great explanation, Josh. I love RxJS but there are times I wish I could just use the value of an Observable in a component without subscribing. This looks beautiful.
Awesome, straight to the point. Can't wait for signals now 😉. Initially thought it was going to replace RxJs's BehaviourSubjects but now I feel quite confident that Angular is about to experience some kind of renaissance!
This reminds of of Signals and Slots in QT.
I've built stuff in QT off and on since 2007. KDE is built on it. The Signals/slots model is kinda like pub/sub but smarter. JS is basically a hack at this point though, so I have been wondering if this is even possible without workers. Nice vid.
Cant wait for this, absolutely Awesome!
What's the difference in performance between the signals change detection strategy and the current OnPush change detection strategy when using only observables and not triggering change detection manually?
Conceptually, A signal enables auto-tracking on Signal Read (eg: calling the signal function to get the current signal value). Imagine Components/Directives, the Template etc... have a "Reactive Context" where they can track Signal read, we could possibly have per-view/per-component Change Detection, combined with Angular's effective incremental DOM algorithm, the perf boost would be awesome.
The current Change Detection would still trigger change from the root ApplicationRef so in a sense, your whole component tree is subject to be checked. OnPush Component prevents its subtree to be checked further but we still have a lot of unncessary checks. Signals w/ a "potential new CD Strategy" would help with this.
Thanks for the update.
Nice, I would love to try out this feature when it is released.
Hey Josh, thank you as always for the great explanation. Just as a small suggestion/request, it would be awesome if you could link some of your sources of information so that people watching your videos can deepen their understanding about them.
Keep up the good work and thanks again!
There's a big discussion here if you want to check it out: github.com/angular/angular/discussions/49090
I don't use signals, but I am still very much looking forward to having them in angular. You guys have such a rich history w rxjs, it's gonna be very interesting to see the patterns you will create with it and signals. I think it could really revive rxjs in other signal-using frameworks too, or bring life into other async reactivity solutions. Cool stuff!
This is Gold!
Can't wait for signals
Wow this is a great news for the angular acosystem
I loved the perhaps unintended visual pun of acute angle(ular) pain.
I've been waiting patiently for someone to notice! lol
This is awesome! How would this effect Inputs and Outputs in Angular?
It remains to be seen exactly how this will play out, but the Angular team have publicly talked about using signals for inputs
I love this, would be really exciting to see reactive inputs in Angular! The current way of passing the value of an input to a subject through a setter just feels so clunky.
Incredible, does this mean there’s no need for ngOnChanges? I very often have to take the Input and do something with it, with a pipe, or ngOnChanges
@@MiuBrothersOfficial I would assume so eventually yes, I can't see any need for ngOnChanges - if we have an input that is a signal and we want to do some kind of side effect equivalent to using ngOnChanges we could just define an "effect" and any signals we use in that effect (including the input) will automatically trigger that effect whenever they change
I really enjoyed this. Thank you Josh
Signals along with RXJS sounds really good 😍
I am astonished how quickly you transform from a convinced Rxjs coder to a Signal Evangelist. Signals will wishiwashy Angular as Standalone components already do!
This doesn't change the justification for RxJS at all for me - RxJS is required (or something else that covers the same use cases it does) if you want to code declaratively and handle async reactivity. The only difference is that I would have also used RxJS for all sync reactivity as well, but if there is a framework primitive that can handle sync reactivity more easily that also interops with RxJS then it doesn't make much sense to me to not adopt it.
Amazing video! Thank you :)
Thank you Josh for sharing this !
Do you know which angular version is expected to bring this change? I'm currently on angular 12 and I don't want to upgrade until it's a major new release.
This one seems like a major shift.
Also, I agree with the 2 styles out there.
I started Angular 2.0 in 2015 when it was just released. I learned it the way google guys talked about it, meaning the simple way. When I tried the push strategy way, it felt like a huge pain to achieve simple behaviors, particularly in small apps where there aren't that many components and not a lot changing overtime.
Hopefully signals won't wash away the simplicity of the imperative style.
It looks like it will be in v16, there is already a preview out under 16.0.0-next.1 for the initial/prototype implementation (still lacking features)
"Signals" are the implementation of the Command pattern. But making the RxJS optional or excluding it completely would be a revolutionary change for Angular making it lighter, faster and competitive framework.
We already have zone-less Angular, now we need RjJS-less Angular.
Great video. Very informative. Do you think Signals would be a good replacement for NgRx for state management? Would Signals trigger change detection between different components? I have know angular since v2 and despite all of those years I have not effectively used NgRx yet.
Great video! thanks
Amazing video thanks for sharing
This should be amazing. Been out of angular work wise for about a year. Time to jump back ??
Heck yeah, I think it's time for everyone to jump back in!
With the release of Angular 16, there will be a need for a brand new Angular course, perhaps a three-hour-long video on UA-cam created by you.
It won't be a video course, but I am working on a course that will incorporate all the new Angular goodies and teach the typical reactive/declarative style I advocate for
@@JoshuaMorony , Can't wait to see 👍
Zoneless application is the right path!
Amazing video like always thank you Joshua !
AWESOME, THANKS!!
I think my biggest hurdle to move from imperative programming to declarative was the fact that I had to trust all those weird bits and bobs like observables, subjects, transform functions etc to do their job. And I had to learn, by heart almost, what each of them do. Once it clicked I never looked back, but it took some time to understand things like why some value is not updating even though I am subscribed to the observable (turned out it was hot/cold observable issue). And I had no idea how I could even start debugging it, because of hidden abstraction layer.
This is a great example, and exactly what I mean by "being dragged through the thorn bushes" to the other path
Really like this Video. But there are even more benefits that result from using signals. The main benefit beeing syncronisation and memoisation. I think this will be the change that makes Angular rise again in popularity a lot.
As I understand signals will not use the zone.js for tracking updates?
They are yet to be implemented, and the current prototype still relies on Zone.js, but yes the idea is that signals will eliminate the need for Zone.js (but Zone.js will still be an option for code that does not use signals)
I’m so ready for this
Just to make sure I understand, so "imperative" means using "synced" values (not observables) and counting on change detection to make your view reactive, but that's a problem because you can't use RxJS to create new state that is reactive on your "imperative" state, so you need to switch to a behavior subject? (which is the reactive declarative?)
I would say it's a bit different to that - you can still using synchronous values/mechanisms and be reactive/declarative. It's better to think of imperative and declarative as being the opposites - but something can be reactive and imperative (e.g. using an observable subscribe or other mechanism to "imperatively" reassign/update a value after it has already been declared), or it can be reactive and declarative (e.g. using an observable/signal to define what something is once in the declaration and how it reacts to changes, and never imperatively reassigning that value).
I never really loved rxjs so signal is maybe an altenative for some case
Mix and match RxJs with Signals: In Rxjs style you use a creation observable to enter Rxjs world and you stay in Rxjs world to compose with any other Observable you need. When you have done all your transformations in RxJs world (pipe) then you subscribe and come back into Javascript land. In between Signals are useless because not composable to be composable it needs to be an Observable!
At the begging I was ignoring this announcement since did not make much sense to me, but after seeing your video I wonder if this will integrate well with ngrx too, are we gonna parse all selectors into signals in the component? 🤔
Probably, it's hard to say now but I can't imagine this not becoming something that takes over completely. I know Brandon Roberts has already been toying around with integrating signals into NgRx.
In the intro you speak very explicitly about zone.js. But you don't mention it with the use Signals (as long if I didn't miss it). Will there be any change?
Yes, eventually. For now the prototype of signals still relies on Zone.js, but the Angular team is aiming to make Zone.js optional with a signal based approach at some point
Well explained👏
Hi Josh, what do you think about Mike Pearson's State Adapt?
I am aware of State Adapt but haven't had time to play with it properly yet - I love Mike's work though
Great video, thanks!
Will a value that uses the "computed" function still act as a signal itself? Can you chain multiple "computed" values similarly to how we can chain multiple observables? I'm trying to find the line to draw where Observables should be used over Signals.
Yes, you can chain computed signals in the same way that you can with observables. I like to think of "the line" being async reactivity - if you don't need to explicitly handle async reactivity use signals, if you do use RxJS
Nice video, thanks for the explanation
also using signals with my own ui building library, they are cool
Nice video, thanks a lot .
Surely, NG team will not rewrite forms, httpclient and router into signals, or I just can't imagine how would this work. By the way, are signals pipeable in any way? Or should we declare a new variable for each 'step'?
As in pipeable with RxJS operators? In the current implementation no, you would have to convert to an observable first, pipe, and then convert back to a signal. Personally, I'm hoping for the addition of some kind of "pipeable signal" or just a "pipe" method that will handle this signal -> observable -> signal conversion for you and pass in the operators to pipe to the observable.
@@JoshuaMorony I literally just finished programming my own signals and then ended up watching your video (no kidding), what a timing.
In my case it ends up being a parameterless function which when invoked returns the current value (imperatively), but which you can pipe and subscribe to directly (it literally has the pipe and subscribe method).
I can even use them inside rxjs operators (like takeUntil) or use the async pipe in the templates thanks to the fact that rxjs provides a way of interop using a symbol.
If they are working on the signals I think they'll also consider 'computeds', their API is orders of magnitude better than NGRX's selectors since you don't need to tell it which other selectors it depends on, they are automatically detected when running, which also provides better ways of memoization as well as better strategies to how/when to recalculate them.
What about when we get to Signals and the Angular team dicedes to remove zone.js what will happen to old projects? that will make a big thing to migrate to Signals or Am I thinking wrong?
Zone.js is here to stay for a while, at least until all of Google's Angular applications move away from Zone.js. In the mean time, Signals enables optional Zons.js aka in new projects, zone.js is not needed for perf boost and lower mental overhead
@@ChauTran Hey Chau, I saw you on an Angular Community Meetup a couple of months ago, it was nice talk!
@@Mychelonn Thanks!
I've been using Angular since version 2 and I never wanted to incorporate RxJS. I mostly use promises and it works fine, all async operations I work with are "wait for a single result", to me it never made sense to use observables and behavior subjects.
The 2 async operations my programs use: HTTP Requests, Wait for modal window response. My angular applications don't use impure filters
I love Angular and RxJS, I just wish there were more job opportunities for them!
This blog has an interesting breakdown of overall Angular jobs and where to find them (overall, it's pretty close to React): www.devjobsscanner.com/blog/the-most-demanded-frontend-frameworks-in-2022/
Possibly less Angular jobs in your area may also mean less Angular devs in your area to compete with. In the React world there are more jobs but you're also competing against WAY more React devs.
Elm lang had Signals once. They were removed and replace with Subscriptions and other features...
This will be year of Angular!
0:54 wtf? that's vue composition api :D
Definitely plenty of inspiration and collaboration going on with other frameworks for this - the public facing API will likely end up looking pretty similar to other frameworks, but still a lot of work required behind the scenes to get it all working with Angular
I'm glad to see Angular adopting new ways of doing things, first standalone components, now this, it will definitely make the lives easier for the new developer especially, although I think Angular is on a bad word so it isn't getting many new developers anyway...
JSX/TSX is the only rescue for angular. But they won't allow that because they don't want to :D
@@RaVq91 what, I hate jsx and I'm pretty sure most angular dev do as well, can you explain why do you think this would be a "rescue" for angular.
imo angular templates are far better than any other frameworks
@@nerminkarapandzic5176 Just first few things coming out of my head: hot module replacement - no need to reload the whole page and loose its state (values in inputs, etc), go to definition feature, find all references feature, rename of component will update names and imports in usages, typesafe components api even while writing its markup, easy way to create wrappers that exposes all the apis of wrapped component (not by rewriting all props by hand), full power of JS while writing views instead of html only.
Will @Input() be also supporting signals? Currently one of the most complicated things is reacting on input value changes
Yes we will likely have some sort of input signal
Frankly speaking I don't understand the benefits. We can already have a synchronous reactive code using rxJs. The angular team can create a linter which will help to prefer using async pipe over the regular properties and also try to get rid of zone, when the reactive approach becomes default. Looks like they want to introduce the signal primitive to force developers write code in a reactive way. But do we really need one more feature in angular which actually looks and works like "rxjs lite"?
The problem I'd to use RXJS you have to understand it almost expertly or you'll shoot yourself in the foot very badly, and unfortunately RXJS and Reactive Thinking are not just something you read about and get instantly for most people, you have to study and eventually your brain clicks.
So you have to do all that and still learn Angular. At least with this you can on a surface level or within a couple minutes of reading docs get it and use.
Signals will also highlight situations where RXJS is the best solution when people try and fail without it.
@@TayambaMwanza Totally agree. The library itself is great, but the learning curve is VERY painful. That's why I think other frameworks will take over Angular, because they are easier to learn :(
@@Dimonina So if Angular became easier to learn it would put it in a better position right? Which is what I think the team is doing, already seeing more people talking about Angular in a positive light than usual even from across the Isle. Then there was that post where for some reason since November Angular job postings have increased Dramatically
thanks for sharing
If you have this problem, isn't your client getting too thick? (With all security problems that come along with that?)
Very interesting topic, thanks for bringing light on that. For me personally it`s look like a Vue 3 maybe because of the computed keyword ;) Definatelly It will be interesting to see how this will affect the whole Angular ecosystem :)
Is this different than what Vue has been doing for a long time with computed properties and watchers?
I'm not too familiar with Vue's implementation but these ideas across Vue/Solid/Knockout and now Angular are all quite similar in concept, and the APIs just about the same, just the underlying implementations are a bit different. It's certainly not a new or novel idea.
Vue is already using reactive primitive and computed properties. Is it the same concept here or I misunderstood this?
I'm not too familiar with Vue's implementation but these ideas across Vue/Solid/Knockout and now Angular are all quite similar in concept, and the APIs just about the same, just the underlying implementations are a bit different. It's certainly not a new or novel idea.
@@JoshuaMorony Thanks for clarifying
It's amazing that Angular got this only just now, when other frameworks have had such features since their inception (Vue JS, Svelte.etc.). And based on what you're showing here, their syntax is still vastly superior to Angular's.
is there a more reactive way to react to input changes than ngonchanges ?
With signals? Yes when it is implemented we will have some form of input signal
Can you do a video on the applications of RxJs on Backend stuff, ive already started using it for websockets and anything stream related. As the Rxjs wizard in UA-cam you can give some ideas
RX has a huge problem when using it on server said it's persistence and distribution. An interesting example of RX approach to stream processing is Microsoft Trill.
Thanks ❤
Can't wait to see how Angular devs will make signals 10x more complicated than they need to be.
Will they change name to KnockGular or AngulOut?
Solidular
Que maravilhoso!!!
What amazing!!!
Yea can't wait to debug code some other inept dev wrote by wrapping some http request in a signal thinking they'll skip learning rxjs. I see signals as maybe 10% being used for exactly those immediate reactivity cases.
🔥🔥🔥🔥
Thank you, but I would rather use Svelte for my next project
Angular is not ahead of the curve anymore. It's catching up the others
Angular dev is saying
Svelte a good choice for personal stuff or freelancing, but not there yet for getting hired as an employee
I think signals are similar to React's useState
It does look similar, but the underlying ideas are quite a bit different. This is a good explainer on the difference: www.builder.io/blog/usesignal-is-the-future-of-web-frameworks
Angular is the only matured professional JavaScript framework. Some tyrant libraries start with R, S and V
hmm... looking more like KnockoutJS each iteration. I really miss the observable, computedObservable and the often underappreciated change detection mechanism. You just had to patch in Promises, Typescript, and a decent router. In someways, it was before it's time.
I never used Knockout but from what I have seen yes it does seem to have been a bit before its time