fix(core): allow explicit read generic with signal input transforms#67997
Conversation
|
That would be a fix for #53969, right ? |
|
@JeanMeche Indeed, it looks like it is! 👍 According to the discussion between @JoostK and @devversion , maybe my fix is too naive? But maybe it is a usable workaround until TS natively support it (even if the linked PR upstream has been closed, so it might not be soon). |
|
This is interesting, I hadn't considered this. Would this behave the same as specifying |
|
@JoostK That was my first intuition, but this breaks the following test: __requiredWithTransformButNoWriteT = input.required<string>({
// @ts-expect-error
transform: (v: string | boolean) => '',
});I think adding overloads is the way to go. |
108df9e to
8571ed4
Compare
|
Is there anything I need to do to cleanup this PR? |
Using explicit single generic arguments with transforms (for example, input<boolean>(false, {transform: booleanAttribute})) previously failed overload resolution.
Before this fix, type-checking produced:
````
✘ [ERROR] TS2769: No overload matches this call.
Overload 1 of 5, '(initialValue: boolean, opts?: InputOptionsWithoutTransform<boolean> | undefined): InputSignal<boolean>', gave the following error.
Type '(value: unknown) => boolean' is not assignable to type 'undefined'.
Overload 2 of 5, '(initialValue: undefined, opts: InputOptionsWithoutTransform<boolean>): InputSignal<boolean | undefined>', gave the following error.
Argument of type 'true' is not assignable to parameter of type 'undefined'. [plugin angular-compiler]
```
This change adds specialized overloads for explicit read generics.
8571ed4 to
3ead51e
Compare
|
This pull request has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Using explicit single generic arguments with transforms, e.g.
input<boolean>(false, {transform: booleanAttribute}), failed overload resolution.Before this fix, type-checking produced:
What is the new behavior?
Add specialized overloads for
input(...)with transform write type equal to read type, and add signature tests forbooleanAttribute/numberAttributewith both defined and undefined initial values.Does this PR introduce a breaking change?
Other information