Thanks for the recommendation, Sander. To your point, the provided example doesn't reflect the originating code. The originating code uses a custom setter on the @Input to toggle the listener. The examples provided were refactored and optimized for conveying the problematic behavior.
Joe Allan Muharsky AlphaSource TL | PeopleOps Facilitator "Stop making decisions for the user based on technology's requirements, and start making decisions on technology based on the user's requirements." On Tue, Mar 21, 2017 at 9:47 AM, Sander Elias <[email protected]> wrote: > Joe, > > You are aware that if you check a @input property in ngOnit only gets > evaluated once? If you want to react to changes on a property, you can use > a @input setter/getter to take care of changes. > This needs different tests anyway. > And yes, I'm aware that this is a quick one-off to show the problem, but > still, it probably reflects the originating code. Making the change I > proposed will make testing and maintenance simpler. > > Regards > Sander > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Angular and AngularJS discussion" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/angular/V4RWlqCzdh4/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/angular. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Angular and AngularJS discussion" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
