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.
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
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
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.
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.
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.
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.
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.
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.
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
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
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
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?
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
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.
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!
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
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
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)
"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.
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
The reality is jr devs will make a race condition mess with signals that work great on their desktops and the senior devs will have to fix it in production.
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.
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'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.
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
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.
Wtf is computed(); that inherently, from the get-go, is so much less intuitive than piping stream changes through operators. It sounds like a poorly named (and more unintuitive) subscription.
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!
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.
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.
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).
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
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 TH-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.
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.
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)
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
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
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.
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.
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.
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.
Joshua if you call something "declarative" it is not become declarative automatically just because you say that, ok? It is so funny that you showing rxjs example and say it is declarative xD LOL Please google some things before spread your thoughts. Now, here is the hint for you - check what is promises with async/await (and learn what is declarative) and maybe you will open whole new world for you xD Big observables fan xDDD
What is it you are taking exception to? I would define declarative as essentially meaning a variables declaration contains all the information about what it is and isn't imperatively modified after its declaration. RxJS, and now signals, are a good way to achieve that but I'm not implying that RxJS is the only way to be declarative. Feel free to enlighten me if I'm missing something, but I don't see how you could create a declarative code base with just async/await if you intend to have state that changes
@Joshua Morony ok, sorry for if Im being too rude, Im just sick and tired of people who think that observables is best overall and you dont need anything else. In fact even angular core devs made decisions Im not agree with. For example their push to functional style approach instead of class-based, as it was from the angular roots. But, my concern is - many people trying to use observables where they suit very well and also where they pointless and make things worse. But because of the fact that community so much encourage only obseervables - many people even dont understand other conceptions. What I mean is... yes, promises. And you know what? Im a big fan of observables too. But Im a big fan also of proper use things which suits best particular situations. And observables do not suit best everywhere. Http requests is where promises are lightning years better. Why? Becasue of declarative code! When I say declarative I mean that you have line by line with no nesting with not callbacks and what more important with no nested callbacks! This is only achivable with promises and async\await. Absolutely not a single point exist in the wild which makes observable better than promises in htttp request! Oh, I hear you say cancellation and robust exception handling:) Man not a problem at all. We can use all power of observables under promises wrapper. With all power of cancellation. If you so interested can show you code snippet how to do it and have no whatsoever boilerplate code and have absolutely clean declarative code! So it will be more readable, more understandable for new comers and more maintainable. Basically thats my point
@@Sky4CE Thanks for elaborating, I think we're operating under different definitions of declarative here. I certainly have no issue with using async/await in places where it makes sense for me, but to demonstrate the issue I am thinking of with promises (for the definition of "declarative" that I mentioned before) is that if you have say the data for a page retrieved like this: myData = await getMyData(); Now if you say filter the data, or go to a new page or something, at some point in the code you will need to imperatively reassign "myData" - so in this case with just promises and not something like observables or signals, "myData = await getMyData();" can't be declarative (by the definition I'm using) because it needs to be imperatively reassigned after its initial declaration.
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.
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.
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 :)
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!
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.
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
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
The best channel about angular I even know! Love you so much!
That'd be wonderful. Thanks for the video.
Liked, left a comment and subscribed! 🍻
Great Video. Was waiting for a video to explain signals easily :D
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.
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.
Zoneless application is the right path!
Amazing video! Thank you :)
I never really loved rxjs so signal is maybe an altenative for some case
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.
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)
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.
Well explained👏
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.
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
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
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!
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
🔥🔥🔥🔥
Signal to Observable - Observable to Signal totally unnecessary!
Totally agree! I would like Angular team to move away from Rx JS. No other frameworks use this.
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?
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
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.
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!
Angular is the only matured professional JavaScript framework. Some tyrant libraries start with R, S and V
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 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
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)
Angular is becoming React
"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.
With the release of Angular 16, there will be a need for a brand new Angular course, perhaps a three-hour-long video on TH-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 👍
The reality is jr devs will make a race condition mess with signals that work great on their desktops and the senior devs will have to fix it in production.
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.
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
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.
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
If you have this problem, isn't your client getting too thick? (With all security problems that come along with that?)
Elm lang had Signals once. They were removed and replace with Subscriptions and other features...
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.
Wtf is computed(); that inherently, from the get-go, is so much less intuitive than piping stream changes through operators. It sounds like a poorly named (and more unintuitive) subscription.
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!
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!
First time watching your content , and .... subscribed!
Angular? Might as well just go back to Jquery. Maybe start a geocities site lol.
Thank you! It's looks like react state change.. very good
Man's copying Fireship's thumbnail style
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.
I really enjoyed this. Thank you Josh
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
This video is awesome and very informative. thank you so much
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).
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
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 TH-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.
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 thanks for sharing
Love it ❤️
Best video for signals
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)
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
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
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
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.
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.
Signals along with RXJS sounds really good 😍
Nice video, thanks a lot .
Thank you Josh, for keeping us all on the cutting edge!
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.
Great video! thanks
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.
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.
Joshua if you call something "declarative" it is not become declarative automatically just because you say that, ok? It is so funny that you showing rxjs example and say it is declarative xD LOL Please google some things before spread your thoughts. Now, here is the hint for you - check what is promises with async/await (and learn what is declarative) and maybe you will open whole new world for you xD Big observables fan xDDD
What is it you are taking exception to? I would define declarative as essentially meaning a variables declaration contains all the information about what it is and isn't imperatively modified after its declaration. RxJS, and now signals, are a good way to achieve that but I'm not implying that RxJS is the only way to be declarative.
Feel free to enlighten me if I'm missing something, but I don't see how you could create a declarative code base with just async/await if you intend to have state that changes
@Joshua Morony ok, sorry for if Im being too rude, Im just sick and tired of people who think that observables is best overall and you dont need anything else. In fact even angular core devs made decisions Im not agree with. For example their push to functional style approach instead of class-based, as it was from the angular roots. But, my concern is - many people trying to use observables where they suit very well and also where they pointless and make things worse. But because of the fact that community so much encourage only obseervables - many people even dont understand other conceptions. What I mean is... yes, promises. And you know what? Im a big fan of observables too. But Im a big fan also of proper use things which suits best particular situations. And observables do not suit best everywhere. Http requests is where promises are lightning years better. Why? Becasue of declarative code! When I say declarative I mean that you have line by line with no nesting with not callbacks and what more important with no nested callbacks! This is only achivable with promises and async\await. Absolutely not a single point exist in the wild which makes observable better than promises in htttp request! Oh, I hear you say cancellation and robust exception handling:) Man not a problem at all. We can use all power of observables under promises wrapper. With all power of cancellation. If you so interested can show you code snippet how to do it and have no whatsoever boilerplate code and have absolutely clean declarative code! So it will be more readable, more understandable for new comers and more maintainable. Basically thats my point
@@Sky4CE Thanks for elaborating, I think we're operating under different definitions of declarative here.
I certainly have no issue with using async/await in places where it makes sense for me, but to demonstrate the issue I am thinking of with promises (for the definition of "declarative" that I mentioned before) is that if you have say the data for a page retrieved like this:
myData = await getMyData();
Now if you say filter the data, or go to a new page or something, at some point in the code you will need to imperatively reassign "myData" - so in this case with just promises and not something like observables or signals, "myData = await getMyData();" can't be declarative (by the definition I'm using) because it needs to be imperatively reassigned after its initial declaration.
Can't wait for signals
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
Jocelyn, Joseph... is it a JOJO reference??
I do love putting in little hidden references, but I'm not familiar with JOJO so that was just a coincidence I'm afraid!
Great explanation! I love the "imperative force field" analogy
Imperative code trying to mess with your declarative code: th-cam.com/video/xrg-RgF5F8o/w-d-xo.html
AWESOME, THANKS!!
thanks for sharing
This is Gold!
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
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.
Can't wait to see how Angular devs will make signals 10x more complicated than they need to be.
Angular so slow with default change detection. We left angular as company.
good
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 :)
This suppose to be a pretty complex subject but your explanation is really good and make things much easier to understand. Thanks...
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!
Cant wait for this, absolutely Awesome!
Amazing video like always thank you Joshua !
also using signals with my own ui building library, they are cool
Loved how you related this to rxjs. Exactly what I wanted to see. Thank you
Nice video, thanks for the explanation
Wow this is a great news for the angular acosystem
Nice, I would love to try out this feature when it is released.
So, angular.signal === vue.reactive.
Congrats 2 angular 👍
That is just awesome. Waiting for this feature
This will be year of Angular!
I CANT WAIT TO START USING THIS AND I LOVE RXJS!