Good video overall! I just feel like it would have been better to pick a simpler example. The decipher game is fun and a part of me likes that it's not your everyday-create-a-counter-example (we have seen that 1000 times), but to me it felt really distracting and added unnecessary complexity to the understanding of the core concepts. Actually, now that I think about it the counter example, boring as it may be, might actually be good for that very reason. You grasp the requirements within seconds and can concentrate on learning the new things. Also you can easily compare it with other implementations and really grasp the beauty of signals. Got burnt a bit too much by "early adoption", but I can't wait for a stable version. Thank you!
I don't know why Angular team loves to complicate things. You could have explained signals easily with like an auth service that changes an authenticated signal from false to true and how can it be used in template or imported in other services and update UI component accordingly. But NOOO, we have first to figure out what does this app do, and then get lost in code
I never expect some Front End devs to understand what a Full Framework means in an enterprise solution. But Angular is actually what we call a Full Framework. It's a complete solution for enterprise projects. I always liked it.
All these changes are great but it feels like they are for getting other/new people on board with Angular. People already using Angular can do similar things with Subjects and stuff? But then again its all backward compatible so I'm not complaining. :)
Don't know about you, but subscribes aren't always the best way to handle observables. Signals make it clear that there is no subscribe to be called and hence managed. When one signal is computed from another, the dependency is clearly established. No need to manage subscriptions. Angular manages the subscriptions for you.
I really wish angular would have stayed away from the terminologies like signal, computed, effect etc. It's very confusing it also increases the learning curve. Rather I would have used the same naming convention from Dart or Kotlin such as streams (sink & streams) from the Dart (Or) coroutines & flow from Kotlin (Or) even redux - State & Action & selector.
@@user-if1de8pt2j I would assume if they are renaming API they would also change the name of the library. The name & the api seems very react-ish. I feel like that can be somehow improved.
Thanks for your response. We are actually interested in all functions of the signal. Our goal is to replace all synchronous functions of RxJS with signal functions.
This computed concept is not very new. It was there in knockoutJS since 2016. The computed concept is similar like KnockoutJS computed/pure computed observables. Glad that Angular is adding it finally. Based on my experience in KnockoutJS, computed observables creates lot of performance overheads. Hence knockoutJS added pure computed observables. I am very confident that Angular team definitely takes care of performance headaches with these concepts.
So instead of counter+=1, with the ui updating. It's going to be counter: Signal = new Signal(0);counter.next(counter.value + 1); all over the codebase... seems like a lot of boilerplate to help angular out :(
No matter how many simple reactivity primitives (signal, computed , effect ) brings into the framework, the overcomplicated Template is the problem (TemplateOutlet, TemplateOutletContext, ....) - The ideal Template is an HTML string sprinkled with Template Literal Tags: (${age}). The overcomplicated Template neeeds an overcomplicatede Compiler!
I've gone through years of Angular use and never used such things as TemplateOutlet and TemplateOutletContext, etc. But just last week I did finally find a good use for TemplateOutlet, haha. Most of the time Templates will look just like regular HTML with some Angular binding stuff mixed in.
Watch all the Angular Sessions → goo.gle/IO23_angular_pin
Good video overall! I just feel like it would have been better to pick a simpler example. The decipher game is fun and a part of me likes that it's not your everyday-create-a-counter-example (we have seen that 1000 times), but to me it felt really distracting and added unnecessary complexity to the understanding of the core concepts.
Actually, now that I think about it the counter example, boring as it may be, might actually be good for that very reason. You grasp the requirements within seconds and can concentrate on learning the new things. Also you can easily compare it with other implementations and really grasp the beauty of signals.
Got burnt a bit too much by "early adoption", but I can't wait for a stable version. Thank you!
Yeah, like you said I think the cipher example is a little too complex to get a quick overview on how everything comes together.
Best update since angular 2
Thanks to angular core team
I don't know why Angular team loves to complicate things. You could have explained signals easily with like an auth service that changes an authenticated signal from false to true and how can it be used in template or imported in other services and update UI component accordingly. But NOOO, we have first to figure out what does this app do, and then get lost in code
Clear and motivating presentation, I can't wait to implement this new approach in my projects 👍
Great explanation! thank you. I have been a fan of reactivity since Rx. Looking forward to the full release of Signals in Angular.
Great explanation. I'm looking forward to trying these out for the first time.
I never expect some Front End devs to understand what a Full Framework means in an enterprise solution. But Angular is actually what we call a Full Framework. It's a complete solution for enterprise projects. I always liked it.
what does "support for inputs, outputs and queries" mean in the timeline related to Angular Signals?
Great stuff!
Great advancement 💟
I'd like to see some materials by the angular team on signals + rxjs
All these changes are great but it feels like they are for getting other/new people on board with Angular. People already using Angular can do similar things with Subjects and stuff? But then again its all backward compatible so I'm not complaining. :)
Don't know about you, but subscribes aren't always the best way to handle observables. Signals make it clear that there is no subscribe to be called and hence managed.
When one signal is computed from another, the dependency is clearly established. No need to manage subscriptions. Angular manages the subscriptions for you.
signal - computed - effect in ELM : Model (signal or state) - Update ( or computed, recomputed state) - Effect ( update view with recomputed state)
You mean Elm lang TEA - Model-View-Update?
Oh this feels good.
Tour of Heroes with signals, please.
I really wish angular would have stayed away from the terminologies like signal, computed, effect etc. It's very confusing it also increases the learning curve. Rather I would have used the same naming convention from Dart or Kotlin such as streams (sink & streams) from the Dart (Or) coroutines & flow from Kotlin (Or) even redux - State & Action & selector.
It’s not that confusing
@@user-if1de8pt2j I would assume if they are renaming API they would also change the name of the library. The name & the api seems very react-ish. I feel like that can be somehow improved.
how PWA will support there
This feels very similar to what MobX does.
"Is this feature now stable for use in production apps?"
We are still in developer preview. What part of this new API are you most interested in?
Thanks for your response.
We are actually interested in all functions of the signal. Our goal is to replace all synchronous functions of RxJS with signal functions.
Awesome!
This computed concept is not very new. It was there in knockoutJS since 2016. The computed concept is similar like KnockoutJS computed/pure computed observables. Glad that Angular is adding it finally. Based on my experience in KnockoutJS, computed observables creates lot of performance overheads. Hence knockoutJS added pure computed observables. I am very confident that Angular team definitely takes care of performance headaches with these concepts.
So instead of counter+=1, with the ui updating. It's going to be counter: Signal = new Signal(0);counter.next(counter.value + 1); all over the codebase... seems like a lot of boilerplate to help angular out :(
No
To create a counter it would be
counter = signal(0);
To update counter, it would be
counter.update(value => value+1);
10 years later you conceeded that KnockoutJS / MobX were right all along...
Vue has also a veeeeeery similar concept. Simple and beautiful
@@Matrium0 meanwhile Elm lang - that's cute 😂
@@Matrium0 They copied it, it is the same with a strange name "SIGNALS"
No matter how many simple reactivity primitives (signal, computed , effect ) brings into the framework, the overcomplicated Template is the problem (TemplateOutlet, TemplateOutletContext, ....) - The ideal Template is an HTML string sprinkled with Template Literal Tags: (${age}). The overcomplicated Template neeeds an overcomplicatede Compiler!
dont know my angular html looks like actual html with {{}} bindings :)
I've gone through years of Angular use and never used such things as TemplateOutlet and TemplateOutletContext, etc. But just last week I did finally find a good use for TemplateOutlet, haha. Most of the time Templates will look just like regular HTML with some Angular binding stuff mixed in.
var signal = useState
I like the video but the example is not good
this is a copy from Computed, data(vue2) ref(vue3) in VueJs and in useCallback, useEffect and useState from react
And the Effect is a copy from Watchers from Vue
Oh boy yet more terms to describe old concepts!
And bad terms.
We alredy have subjects to multicast data to our subscribers
I think this is to make it simpler for new Angular devs, and in the long term to totally get rid of Zone.js for change detection.