Thanks to you for reading and replying! :)

“The ngIf directive is meant to display some static content”

False, ngIf is meant to display html markup whether it’s static or dynamic. Why are you assuming everything inside an ngIf should be static?

It’s not designed to switch between different contents depending on the input

I think there’s some confusion here. The input has nothing to do with the ngIf directive, the input is a responsibility only of the child component.

Besides when you add another user to the list, you have most likely no objection against creating another component to represent that user.

We’re talking about different things. It’s natural that if we ADD a new user we are going to create another component/element. There’s no other way, that’s how HTML works. Instead, if a user CHANGES, its component could be almost identical to its previous state but with some minor differences. Or it may be completely different, that’s the worst case scenario. It just doesn’t make sense to re-render all of its HTML (and its children, too!) if a small portion of its template has to change.

Apart from that (which is sufficient to say it’s not a best practice), if you usually work alone (and therefore you’re maintaining all of the components) you may not see this as a bad practice, because you know exactly how the child component behaves. You know that unless you re-render it, it won’t update. That’s not how components should work though. A component should be reactive about its inputs and from the perspective of who will use your UserComponent, that behavior makes no sense :)

If you really don’t like using setters or NgOnChanges (which is totally fine to use, but it indeed makes your code more messy) I suggest you read this article which explains how to write a custom decorator for this specific use-case. It’s really interesting, and the guy had a talk about it at the last NgConf which you can find on YouTube! https://blog.angularindepth.com/creatively-decouple-ngonchanges-fab95395cc6e