It has its own limits. I had just fix someone's code that used setters on multiple inputs, and it blew out of control. Those setters were fired up individually before all other code without knowing if other inputs setter were fired or not so half of the properties were undefined. OK nice for a a single input but for complicated components with multiple inputs the ngOnChanges is you saviour
What I thought of recently that you could maybe cover are common Design patterns and how they would translate to Angular. For example the observer pattern is already solved with rxjs but there are many more. I have looked it up before but only seen them in written form and not in a video format which could be interesting.
Very interesting. Is there a benefit to doing it this way over using ngOnChanges? I feel like having this type of logic at the top of the class could get messy and not be as clear as handling it within ngOnChanges.
I don't think there is any specific benefit to doing it this way, just a stylistic thing - for me, I think it makes things more clear/obvious that something happens in relation to an input changing and I also like the ability to separate concerns that way
@@JoshuaMorony I'll give it a go and see how it feels. I see what you're saying. I'd probably want to call another function from the @Input and handle the bulk of the logic away from the top of the class.
Imho, in the case of a component that has multiple inputs, if the logic only depends on only one input, it may be better to implement that logic into a setter for that input, as doing it in ngOnChanges would require you to add an additional check (or else the code would execute when not necessary, correct me if I'm wrong). In the other hand, if the logic depends on multiple input, it's better do implement that logic into the ngOnChange. And as said in the video, If you need to access the previous/next values, the ngOnChange would be the way to go. Finally, If the component has only one Input, either way is identical.
Hey, i always have this confusion.. what is the best practice. Is it by using ngOnchange method or by using set method on input(like you showed in the example)
I don't think there really is a best practice - personally I will use a setter if I want to trigger some side effect as a result of the input changing but don't need to store the input itself, otherwise I would use ngOnChanges. Many people just prefer to use ngOnChanges and not use setters at all.
Angular is 🔥🔥. AngularJS is dead, which is the first version of Angular that came out. Every version including Angular2 is completely different from the first and it's getting better with every update.
Yeah as Mircea said, AngularJS has reached end-of-life as of Dec 2021 which means it won't get updates/patches anymore, but "AngularJS" was replaced by "Angular" (aka Angular2) back around 2017. I don't think you need to worry about Angular going anywhere anytime soon since pretty much Googles entire product suite depends on it and it is being actively developed (v13 just came out)
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
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 has its own limits. I had just fix someone's code that used setters on multiple inputs, and it blew out of control. Those setters were fired up individually before all other code without knowing if other inputs setter were fired or not so half of the properties were undefined.
OK nice for a a single input but for complicated components with multiple inputs the ngOnChanges is you saviour
Had no idea you could do that with an input. Thanks for sharing.
one of the greates channels you have a great way of explaining things 👍🏻 helped me out a few times now 😁
thank you for the effort joshua 👏🏼👏🏼👏🏼
What I thought of recently that you could maybe cover are common Design patterns and how they would translate to Angular. For example the observer pattern is already solved with rxjs but there are many more. I have looked it up before but only seen them in written form and not in a video format which could be interesting.
Very interesting. Is there a benefit to doing it this way over using ngOnChanges? I feel like having this type of logic at the top of the class could get messy and not be as clear as handling it within ngOnChanges.
I don't think there is any specific benefit to doing it this way, just a stylistic thing - for me, I think it makes things more clear/obvious that something happens in relation to an input changing and I also like the ability to separate concerns that way
@@JoshuaMorony I'll give it a go and see how it feels. I see what you're saying. I'd probably want to call another function from the @Input and handle the bulk of the logic away from the top of the class.
Imho, in the case of a component that has multiple inputs, if the logic only depends on only one input, it may be better to implement that logic into a setter for that input, as doing it in ngOnChanges would require you to add an additional check (or else the code would execute when not necessary, correct me if I'm wrong).
In the other hand, if the logic depends on multiple input, it's better do implement that logic into the ngOnChange.
And as said in the video, If you need to access the previous/next values, the ngOnChange would be the way to go.
Finally, If the component has only one Input, either way is identical.
@@shinomitsu7798 great summary, I agree with all of that
@@shinomitsu7798In case you need prev/next values, u can use encapsulation over input values. private _input, @Input() input: T
excellent trick, thanks for sharing, so I suppose performance is much better than using inputs.
That's a nice method indeed, a little less verbose than onChanges 🙂 Thanks for sharing !
Hey, i always have this confusion.. what is the best practice. Is it by using ngOnchange method or by using set method on input(like you showed in the example)
I don't think there really is a best practice - personally I will use a setter if I want to trigger some side effect as a result of the input changing but don't need to store the input itself, otherwise I would use ngOnChanges. Many people just prefer to use ngOnChanges and not use setters at all.
used it today
Isnt Angular deprecated now? :(
Angular is 🔥🔥. AngularJS is dead, which is the first version of Angular that came out. Every version including Angular2 is completely different from the first and it's getting better with every update.
Yeah as Mircea said, AngularJS has reached end-of-life as of Dec 2021 which means it won't get updates/patches anymore, but "AngularJS" was replaced by "Angular" (aka Angular2) back around 2017. I don't think you need to worry about Angular going anywhere anytime soon since pretty much Googles entire product suite depends on it and it is being actively developed (v13 just came out)