Add default/optional parameters to support easy upgrade on ViewChild/ContentChild breaking changes

🚀 feature request

Relevant Package

This feature request is for @angular/core

Description

we have a large application with large number of references to ViewChild/ContentChild decorators. with latest v8 these decorators are modified with breaking change to include {static: true/false} parameter. can we make this as a optional/default parameter so we do not have to make large set of changes across our application and depended libraries. (we do use depended libraries which also reference ViewChild/ContentChild and it will be really hard to migrate all the depended libraries to new format)

Describe the solution you’d like

Make {static: true/false} parameter optional or use default value = false.

Describe alternatives you’ve considered

we are considering alternative to use @ViewChild('foo', <any>{static: false}) on all our existing v7 codebase to mitigate the upgrade complexity (still not tested or finalized). but we are still blocked on doing same steps in libraries we are depending on (not in our control).

[trotyl]

If I look into the code I can read that this was expected to be optional

That’s true, it should definitely be optional, and that’s already happening: https://github.com/angular/angular/pull/32582, https://github.com/angular/angular/pull/32686, https://github.com/angular/angular/pull/32720

Making it required in v8 and optional again v9 is for warning about this breaking change, as the fallback behavior in v7 and v9 are different.

[mlakmal]

Make {static: true/false} parameter optional or use default value = false.

Making any static default value will also become breaking change, as the previously runtime has a dynamic default value based on usage, which is worse as not even awared by user.

i was not aware of this being dynamic earlier. yes it will not be ideal (unless we have it like before by default) but user will have option to override based on their requirement.

at-least having default/optional value would allow us to start progressing on upgrade validation instead of being blocked on this issue (since this breaks, and not being able to update external library code we are now blocked until all dependencies are corrected).