That's pretty good 👍 :)

We prefer a principle of "local reasoning", not to have global configurations that modify the behavior of individual applications. You should be able to look at the component and understand how it behaves.

The same question was asked for standalone: true as well (#49667 (comment)). This same reasoning goes all the way back to the RFC for Standalone Components, where we noted NgModules often made it "hard to reason about components, directives, and pipes in isolation."

If I understand the RFC correctly, that's exactly what is planned (if you omit the changeDetection property, it will use OnPush change detection.

Adding ChangeDetectionStrategy.Eager as an alias for ChangeDetectionStrategy.Default rather than a rename in v22 would mean that ChangeDetectionStrategy.Default would have to follow the deprecation and removal policy timeline, which would either:

(a) delay the default flip until v23, when we could remove ChangeDetectionStrategy.Default
(b) flip the default in v22 but still have an enum named ChangeDetectionStrategy.Default which is no longer the default.

In the end, it's still the same number of files that need to be touched, but split across 2 different version updates.

After discussing this, we will add Eager in 21.2 and keep Default around until v24, with the default flip still planned for 22. @alxhub pointed out that Default means "run change detection on me by default" and not "I am the default strategy" which was news to me 😆

Thank you!
Just from a change management perspective, an Angular upgrade usually involves fixing subtle bugs in various components, and so I need to pull in our OWNERS to review those changes, but for a purely no-op change like renaming Default to Eager I can opt out of notifying OWNERS. If those were in the same PR I would be required to get the review of all of the OWNERS for the syntactic change, which would distract from the meaningful changes that require real review.

See discussion in #66779 (comment) about a global config

enableExperimentalZonelessChangeDetection is quite different because the scheduling was always an application-level thing while the change detection strategy is a per-component config that changes how the traversal works at that location in the view tree.

The Zoneless/zone scheduler was “when do I trigger change detection for the application” while change detection strategy is “what do I do when I reach this component during change detection”

Zoneless is a different concept from OnPush. Both are needed for maximal performance. One of many reasons this becomes so invaluable

Zoneless is a different concept from OnPush. Both are needed for maximal performance. One of many reasons this becomes so invaluable

Yes. I hope that Angular can provide the optimal performance configuration by default, rather than requiring me to choose. Although I have been developing with Angular for many years, I always felt that Angular is not friendly to newbies, with too many concepts.

This will be the new default, so no change is needed at bootstrap. nothing specified means OnPush.

This is always better to let user to have the choice.
It's like standalone command line option, we still have the choice to bootstrap as standalone or not, whatever the defaults are.
For now, we have to "manually" update change detection property for App component at bootstrap, I'm just asking an option to do it automatically. Particularly if Eager, Default and OnPush options co-habit in a while.

Until now, we are using a "parent" schematics (embedding angular one) to automatize this stuff (and many more things), but it is always better to have such behavior nativelly supported instead using external code, right ? :)

Difficult to justify the breaking change

Hmmm, need to think about it, but probably can be added instead of replacing, so it won't be breaking

// the existing enum
export enum ChangeDetectionStrategy {
  OnPush,
  Default,
}

// extend it with two string literals
export type ChangeDetectionStrategyInput =
  | ChangeDetectionStrategy
  | 'OnPush'
  | 'Default';

https://www.typescriptlang.org/play/?#code/PTAEBcAsFNWgPAlgZ3IgdgczugrgWwCgEAHAewCdwcDQBhSAQy2gBFpxoBjNM9AZXAVGnTAE9QAb0KhQAeXQAFXMkgAaGaHYAzRrgA24DQF9ChEHHid0AE1CJqAdweQIjsqFQUM2fQ+jC+sjE8ORUEGIksAzMmGwc3LwCQiLQ4gCS6CS41AC8mgA+9Ews7Jw8iHyCwqJihaAA5ArKqg31DTp6hg0A3GbmYFwlcRAwoDbclCKUoPgcjDYijBAejFxc0CTUULDo0I6W1hN24JHQIWHUGJwUuhv0ZPjke+jU0rJDsfHlSQD8AFzFL5lRKVZI1NJiTLZcB9UwDUDoMjUZYAIwo0EYAGsfKBPixgoQuHxUKAyPobM0VJBAXRHs9oK9QLkpDJ8XEQRU+LTht9QVUUrUAHRU1SEUzE9Ck8k2ToGcC0+l8Rl5Vl43mcpI84EJLng1LiIVywzisyS0l7RyimkPJ7Kpks97svl6wFNJTUtoSknUS3GhW2hkOtXOzVgt3+r1AA

from an enum to a string union

The reason they use enums is because you can add doc comments for each case, see: https://github.com/angular/angular/blob/4123ebf61e1c99c9efb79268527af8be4dc39cc3/packages/core/src/change_detection/constants.ts
AFAIK you can't do this with unions.

We've actually discussed a lot the name, the caveat is that non-OnPush children of OnPush components won't be checked if the parent isn't. So both Global and Always are kinda misleading.

What about ChangeDetectionStrategy.Implicit

Also maybe you guys can make a mascot sidekick, the Eager Beaver

btw I don't see breaking change here if we have an upgrade schematic in place.

It is a breaking change in a sense that the same code (no CD strategy) won't have the same behavior between v21 and v22.