A component Is meant to be reactive about its Inputs. In fact, a well written presentational component (which UserComponent should be) should be the result of its inputs, just like pure functions return always the same value given the same arguments. Mantainable doesn’t necessarily mean “less code”, that “paradise” you’re talking about is the result of SoC, functional programming (a component is a function, if you use React you’ll see it even better), reactivity. This is what DOESN’T lead to bugs. Your example DOES lead to bugs because you’re giving the parent component the responsibility to DESTROY the component in order for it to be functional. And on top of this, there are all of my previous considerations about performance.

I’m not in a team, that was an example: I’m a consultant and I work with lots of teams (from really small to really large ones), and I can’t count the amount of times I had to debug applications because of these problems. If you’re fine with your solution, I am happy for you (even if it’s clear in my mind where this mentality will lead) but this doesn’t make this technique a best practice. Not at all! It should be stated that you can use this technique if you’re given a component which needs to be constantly re-rendered, it should not be perceived as “Since there is this way, you can avoid using ngOnChanges/setters/whatsoever”, because I’m telling you that THIS is what comes out from your article.

I hope you understand my message, if you don’t agree with me that’s fine (I don’t have the time to continue this discussion forever :P), but you’re on Medium and your post is read by lots of people: All I’m telling you from the first message is that if you wanted to, you could rearrange it just a bit to make sure people don’t take it as a common/best practice, and it would still be an interesting read (and possibly a solution for those who are given a “broken” component to work with, whether you consider it broken or not ;))

Cheers!