-
Notifications
You must be signed in to change notification settings - Fork 27k
Closed
Labels
area: coreIssues related to the framework runtimeIssues related to the framework runtimecore: inputs / outputscross-cutting: signalsstate: has PR
Milestone
Description
Which @angular/* package(s) are relevant/related to the feature request?
core
Description
There is a difference in the design of the input() and of the signal() functions.
signal<T>() expects an argument and returns a Signal<T>, whereas input<T>() can be called with or without argument and returns a Signal<T | undefined> if no argument is passed.
Moreover, if we have code that uses input() without argument:
collapsed = input<boolean>();and want to pass it options, then suddenly we're forced to
- pass an initial value, although the initial value is the same as before;
- change the generic type passed to the function, even though the type of the signal to create is the same as before:
collapsed = input<boolean | undefined>(undefined, { alias: 'appCollapsed' });Proposed solution
Even though it requires a bit more code, I find the the result would be more consistent, more explicit, and less surprising if input() always required an initial value:
collapsed = input<boolean | undefined>(undefined);- adding options requires just that: adding options
- the generic type is the same as the generic type of the created Signal
- it works the same way as signal()
Alternatives considered
NA
urugator and vneogi199hakimio, ashley-hunter, simeyla and nifiro
Metadata
Metadata
Assignees
Labels
area: coreIssues related to the framework runtimeIssues related to the framework runtimecore: inputs / outputscross-cutting: signalsstate: has PR