Form control value is null when initialized with undefined

Which @angular/* package(s) are the source of the bug?

forms

Is this a regression?

No

Description

When you initialize a FormControl with an undefined value (initial state) the FormControl#value is null. The value is null instead of undefined to be short

Please provide a link to a minimal reproduction of the bug

https://stackblitz.com/edit/angular-ivy-x37dzv

Please provide the exception or error you saw

If you try to do test something like the test will fail


// control was initialized with undefined
expect(control.value).toBe(undefined) // <-- in fact, this is null

Please provide the environment you discovered this bug in (run ng version)

Angular CLI: 14.1.0
Node: 16.16.0
Package Manager: npm 8.15.1
OS: win32 x64

Angular: 14.1.0
... animations, cdk, cli, common, compiler, compiler-cli, core 
... forms, material, platform-browser, platform-browser-dynamic
... router

Package                         Version
---------------------------------------------------------      
@angular-devkit/architect       0.1401.0
@angular-devkit/build-angular   14.1.0
@angular-devkit/core            14.1.0
@angular-devkit/schematics      14.1.0
@angular/flex-layout            14.0.0-beta.40
@schematics/angular             14.1.0
rxjs                            7.5.6
typescript                      4.7.4

Anything else?

No response

[AndrewKushnir]

@MikaStark thanks for reporting the issue. It’s a known limitation of the Forms APIs where null is used as a default value in FormControl (see here). Changing this behavior to drop null as the default value would result in a breaking change, see my comment here: https://github.com/angular/angular/issues/40608#issuecomment-769424323. To make it a non-breaking change, we can potentially think of some additional APIs to define what the default value should be (like new FormControl(undefined, {defaultValue: undefined}) on per-control basis or FormControl.useAsDefault(undefined) to set if globally). In any case, this would require extra design work to figure out how that would affect the rest of the Forms logic (there might be more places were the code relies on the null being the default value). We don’t have any ETA, so I’d recommend using a workaround for now.

Given the fact that this issue is reported periodically (#40608, #40978), I’m keeping it open so that we can collect more signal.

[jnizet]

@alxhub maybe I misunderstood what you meant, but regarding your first point, null is and should still be accepted as a value for a nonNullable control. This looks contradictory, but that’s only because it was decided to rename initialValueIsDefault to nonNullable, making things very confusing IMHO.

A nonNullable control can have a null value. nonNullable only means that the reset() method won’t set the value of the control to null, but will instead set it to its initial value (which can be null, BTW). There are many control types (such as an input of type number for example) which should be reset to their initial value when reset() is called, but which must accept null as their value, simply because the user can clear the input, or because we want the input to be initially empty.