Watch this BEFORE updating to signal inputs in Angular

My Angular course: angularstart.com/
Converting to signal inputs in Angular is a reasonably straightforward refactor, but it's even easier with the migration schematic from ngxtension.
ngxtension docs: ngxtension.netlify.app/utilit...
Get weekly content and tips exclusive to my newsletter: mobirony.ck.page/4a331b9076
Want to build mobile apps with Angular?: ionicstart.com
0:00 Introduction
0:50 Using the schematic
2:13 Results
#angular #signals #ngxtension
- More tutorials: modernangular.com
- Follow me on Twitter: / joshuamorony

[@JoshuaMorony]

Join the newsletter: mobirony.ck.page/4a331b9076

[@jordisarrato331]

I love to hear about this, will save me a massive amount of time!

[@danielbarrientos722]

Great video!!!!! I always learn something new when I watch your videos!

[@nouchance]

Thanks!

[@jonathangamble]

Would love to see video if angular didn't have signals and did zoneless with just observables

[@TayambaMwanza]

That's just RxAngular

[@kylerjohnson988]

Keep in mind that Signals aren’t just a reactive primitive, but a way for the framework to track dependencies for change detection. They tell angular exactly what components need to be rerendered instead of having a change detection cycle dirty check the entire component tree to determine which components may need to be rendered. That wouldn’t be possible with RxJS/observables. Because of this, signals are the best way to consume state in your components. RxJS is the best way to handle async tasks and side effects, though so luckily we have the interop, but NgRx SignalStore completes the story here. I can still use RxJS to handle data streams and update signal state while consuming signals in my component in a seamless way without any boilerplate.

[@jonathangamble]

@@kylerjohnson988 - Hey Kyle, this was a Twitter conversation recently that Angular could theoretically use Observable / Behavioral Subjects instead of Signals. Observable do track dependences when you subscribe, or I am misunderstanding something here?

[@kylerjohnson988]

@@jonathangamble BehaviorSubjects/Observables as they are in RxJS are great for reactivity and managing async tasks. If we’re just talking about reactivity, they’d be a great fit. RxJS was not made in such a way that it can provide a notification to the framework as far as what needs to rerender and when. The angular would have had to build a reactive primitive no matter what in order to solve the change detection problem. So the question became, “what should that reactive primitive look like?” Should they build their own version of a BehaviorSubject that has dependency tracking capabilities that would be different from the RxJS subject? That seems unintuitive and confusing. Besides, the ability to pipe onto a behavior subject and transform data in a pipeline means that referencial changes can occur out of scope of where the dependency tracking for the BehaviorSubject would have to live. Signals solve these problems and are rapidly emerging as a cross-framework standard because of how efficient they are for change detection.

[@cinnamonrage]

What IDE are you using, if you don’t mind me asking?

[@cinnamonrage]

@@sulsammy Thank you!

[@faceeverychallenge]

What NVIM color scheme is this? I like it a lot

[@JoshuaMorony]

tokyodark, I just switched to it from gruvbox and I'm loving it

[@faceeverychallenge]

@@JoshuaMorony thanks!! I’ve been on caatppuccin but I may need to switch over. I feel like so many color schemes look great in Lua but in angular/ts I find a lot are not quite up to snuff

[@theoverself800]

Isnt that too risky to jump to new features so early? I mean I would rather wait for couple of months that add something like input signal to production code

[@JoshuaMorony]

Depends on your (or the specific projects) risk tolerance/strategy, technically this is developer preview so the Angular team could change something about it. I consider that pretty low risk generally, and even more so for features not in developer preview. Some people/companies have a policy of remaining one major version behind. If you don't have any strong incentives for incorporating new features, then I don't think waiting is a bad strategy.

[@creative.money_eu]

Nice video! My general feeling is similar, it may be super helpful in some situations, but it does not understand intentions and the code base well enough to usually accept the solution, unless the problem is so clear that you should automate a solution for it. I stopped the subscription for now, as currently I am working on more complex issues, where the autocomplete just does not understand the task at hand.

[@asadrahman6123]

just use tailwind pls you already defining classes in a file

[@JoshuaMorony]

I actually prefer using tailwind but I also prefer to keep things as vanilla as possible when teaching something