feat(core): allow passing undefined without needing to include it i…
#57621
Conversation
| @@ -51,6 +51,8 @@ export interface InputFunction { | |||
| <T>(): InputSignal<T | undefined>; | |||
| /** Declares an input of type `T` with an explicit initial value. */ | |||
| <T>(initialValue: T, opts?: InputOptionsWithoutTransform<T>): InputSignal<T>; | |||
| /** Declares an input of type `T|undefined` without an initial value, but with input options */ | |||
| <T>(initialValue: undefined, opts: InputOptionsWithoutTransform<T>): InputSignal<T | undefined>; | |||
There was a problem hiding this comment.
I decided to make opts required if an explicit undefined is passed, making input<string>(undefined) a type error, with the intention that that should always be achieved using just input<string>().
There was a problem hiding this comment.
I wonder if that is not confusing. TS error messages are not super great, but I like the incentive to encourage the shorthand.
…n the type argument of `input` This commit introduces an overload for `input` to accept `undefined` as initial value if only options are needed to be provided, inferring an input of type `T|undefined`. Prior to this change, the type argument as specified needed to include `|undefined` explicitly even though that isn't necessary when passing options isn't needed. Relates to angular#53909
3c2c0fb to
ff25cab
Compare
|
The most difficult thing in the migration is if you have an input:
and you migrate it to signal input:
The type is now "broken" because the consumers of this |
That's unrelated to the changes here. The original input declaration is unsafe as the input may not be assigned, making it |
|
We can't use the required because it's not required. I'm not saying that this is the correct way things should have been done but Angular was "forgiven" in that matter and it's now difficult to migrate. I'm sure there are more applications that did the same. |
| @@ -51,6 +51,8 @@ export interface InputFunction { | |||
| <T>(): InputSignal<T | undefined>; | |||
| /** Declares an input of type `T` with an explicit initial value. */ | |||
| <T>(initialValue: T, opts?: InputOptionsWithoutTransform<T>): InputSignal<T>; | |||
| /** Declares an input of type `T|undefined` without an initial value, but with input options */ | |||
| <T>(initialValue: undefined, opts: InputOptionsWithoutTransform<T>): InputSignal<T | undefined>; | |||
There was a problem hiding this comment.
I wonder if that is not confusing. TS error messages are not super great, but I like the incentive to encourage the shorthand.
I guess it depends on whether your application is built using If you were to convert from |
|
TGP green |
|
This PR was merged into the repository by commit c93b510. The changes were merged into the following branches: main |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
…n the type argument of
inputThis commit introduces an overload for
inputto acceptundefinedas initial value if only options are needed to be provided, inferring an input of typeT|undefined. Prior to this change, the type argument as specified needed to include|undefinedexplicitly even though that isn't necessary when passing options isn't needed.Note: this is an experiment to determine if such change could impact existing code, it is yet to be determined if this is the direction we want to take.
Relates to #53909