Post strictPropertyInitialization flag flip cleanup

I'm submitting a...

[x] Other... Please describe: Tracking issue for internal cleanup.

What needs to be done

In order to quickly turn on strictPropertyInitialization flag in the whole code base, we introduced ! on every non-initialized class field. Each one of those fields needs to be individually checked and decided whether:

the field should be initialized. Thus foo!: string, should become foo = 'default'.
the field should be marked as optional. Thus foo!: string, should become foo?: string.
the field is reliably initialized, but TS cannot infer that (initialization can occur outside the ctor, for example), so ! should be kept.

@rkirov

@rkirov when an input is required, would you mark with a band !? As in my option in you don't know that the consumer will provide that value, thus, a component should be doing check if that value has been actually provided or not. ! should only be used if the value is initialised such as on ngOnInit. that said though, if one used that component using the viewChild etc... the property will be marked that it will never be undefined. Which in some cases it might be wrong, based on which lifecycle hook the value is initialized in.

And seeing the comment from @mhevery in #21571 it seems that we are on the same page;

Nothing forces @input() to be set. A user of the your component may simply chose not to bind to that input in which case your @input() is not initialize and you should have checks for non-initialized case. I know we disagree, but I think this is the correct behavior.

Truth to the told I am not a particular fan of using the !

@input

If you want to have required semantics for your Inputs what we have been recommending is ! and an assert in ngOnInit. If are to be pedantic the assert should be in ngOnChanges, but that might be too much for some.

The general advice for ! in any place (on expressions or in field declarations names) is that it is unsafe and to be avoided unless there is a compelling reason.

I have an additional advice on cleaning up after my change specifically for angular components.

For Angular components

For angular components, use the following rules in deciding between:
a) adding initializer
b) make the field optional
c) leave the '!'

If the field is annotated with @input - Make the field optional b) or add an initializer a).
If the input is required for the component user - add an assertion in ngOnInit and apply c.
If the field is annotated @ViewChild, @ContentChild - Make the field optional b).
If the field is annotated with @ViewChildren or @ContentChildren - Add back '!' - c).
Fields that have an initializer, but it lives in ngOnInit. - Move the initializer to the constructor.
Fields that have an initializer, but it lives in ngOnInit and cannot be moved because it depends on other @input fields - Add back '!' - c).

Thanks for the detailed explanation much appreciated.

I quite like what you suggest above.

refactor(core): handle #24571 todos. (#49221)

refactor(core): handle angular#24571 todos. (angular#49221)

refactor(core): handle angular#24571 todos

refactor(core): remove TODOs referencing angular#24571

refactor(core): remove TODOs referencing #24571 (#60648)

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}

Navigation Menu

Repository navigation

Post strictPropertyInitialization flag flip cleanup #24571

I'm submitting a...

What needs to be done

For Angular components

153 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Post strictPropertyInitialization flag flip cleanup #24571

Description

I'm submitting a...

What needs to be done

Activity

alan-agius4 commented on Jul 3, 2018

rkirov commented on Jul 12, 2018

For Angular components

alan-agius4 commented on Jul 12, 2018

153 remaining items

angular-automatic-lock-bot commented on Oct 26, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions