Add rule "Component change detection strategy should be OnPush" (GCI536)

[hindsellouk]

No description provided.

[MP-Aubay]

Hi @hindsellouk , could you :

• Update the PR title like this "GCI120 [Team X][2025] - Angular rule"
• Update CHANGELOG.md
• Update RULES.md

[MP-Aubay]

@hindsellouk I think this rule is to generic, Angular doc said that "It could be usefull" and "It may be effective on performance".

So this rule is situational and it's difficult to determine if it should be used (with static analysis)

[utarwyn]

Hello! Thank you for the first Angular rule proposal 🥳

I also think we lack precise measurements of the effectiveness and relevance of using OnPush rather than the default detection system. Can you provide us with precise documentation and why not run some benchmarks ourselves?

It will also be very useful to reference them in the rule documentation. In the meantime, I propose not to merge the PR.

[github-actions]

This PR has been automatically marked as stale because it has no activity for 60 days.
Please add a comment if you want to keep the issue open. Thank you for your contributions!

[utarwyn]

Just few thoughts about the rule, to be discussed further I think:

• OnPush only works correctly when input objects are treated as immutable. Codebases that mutate objects directly (very common in Angular) will have silent view update bugs after enabling it — the rule creates a correctness risk, not just a refactoring task.
• High noise on legacy codebases. Every @Component without OnPush raises a violation. A large existing Angular app could generate hundreds of issues, most of which require more than the claimed 5-minute fix.
• Angular's current recommendation (v17+) is signals-based reactivity, which provides even finer-grained change detection than OnPush without requiring manual immutability discipline. The OnPush pattern is increasingly a mid-tier solution.
• Some UI libraries interact poorly with OnPush if they manipulate the DOM imperatively outside Angular's zone.

[github-actions]

This PR has been automatically marked as stale because it has no activity for 60 days.
Please add a comment if you want to keep the issue open. Thank you for your contributions!