Closed timdeschryver closed 4 months ago
Taking the example from the Angular docs the decorator input properties are typed with their "to-be" type.
@Input({ transform: numberAttribute }) id: number;
After running the input migrator, this turns into (notice the generic types):
id = input<number, number>(numberAttribute(undefined), { transform: numberAttribute });
However, the transformed output results in compile errors, which previously could compile:
<!-- This is OK --> <app-child [id]="1" /> <!-- Error: Type 'string' is not assignable to type 'number'.ngtsc(2322) --> <app-child id="1" />
I think the output needs to be:
id = input<number, number|string>(numberAttribute(undefined), { transform: numberAttribute }); // or id = input<number, unknown>(numberAttribute(undefined), { transform: numberAttribute });
If accepted I can create a PR to resolve this.
Sorry for the issues, I'm using these generators to migrate our codebase over to signals and I bump into some corner cases 😅.
Hello @timdeschryver I love this issues (I've been trying to find as many usecases as possible), and I don't think you should be sorry 😅. These will help everyone at some point. And any PR is welcome 🙏
Taking the example from the Angular docs the decorator input properties are typed with their "to-be" type.
After running the input migrator, this turns into (notice the generic types):
However, the transformed output results in compile errors, which previously could compile:
I think the output needs to be:
If accepted I can create a PR to resolve this.
Sorry for the issues, I'm using these generators to migrate our codebase over to signals and I bump into some corner cases 😅.