New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reactive forms are not strongly typed #13721
Comments
related #11279 |
This is not related to #11279. |
Please explain how it is not related? |
Using There is also https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-1.html The way it is currently, unfortunately, I do not thing it's usable for large app and I need to design something on top of it. |
I just noticed that in TS 2.2 (https://github.com/Microsoft/TypeScript/wiki/Roadmap#22-february-2017) that they have planned Default Generic Types (microsoft/TypeScript#2175) once we have this I think it might be a good idea to revisit this issue since we could make |
Small update on this, looks like Default Generics have been been moved to TS2.3 . So with the support of TS 2.1 by Angular with version 4.0 it should not be long after that before they're able to support TS 2.3 which is now when we should wait to revisit this. |
TypeScript 2.3 with Default Generic Types is already here, do we have any plans when support for TS 2.3 in angular will be ready? |
+1 would love to see this feature. Anybody working on it? |
#16828 |
This might be of use - Angular Typesafe Reactive Forms |
Small update on this: |
So turns out my previous comment was incorrect. |
@Toxicable that still has the problem of lacking the ability to refactor safely. get('person') for example, is not really using the symbol itself. The example above, from @rpbeukes, has a retrofitted way of basically using the object symbol eg. get(obj.person) without using the string. That would be preferred over just having return types. |
I have no idea what you mean by this, what symbol are you referring to here?
This lacks the ability to traverse multiple FormGroups. |
@Toxicable I understand you're change is meant to not break things, not trying to criticize your solution. The other implementation (retrofitted) allows an actual property to be used rather than a string. By referencing the the field by string, if that property name changes, builds break, which for me isn't very safe. For example, changing the field name from 'name' to 'firstName', would break if I didn't change all the g.get('name') references. If I could do something like
They would all be tight references. The retrofit solution does it in a slightly hacky way but does solve that problem as well. |
@Toxicable thanx for the PR. Looking forward using it :) I do agree with @howiempt, if we can get something like this it would be first prize:
Again, I don't really know how feasible this is within the greater scope of things. Keep up the good work and thanx for the quick response. |
I think that this method of accessing other controls is not related to adding generics. |
I really don't think that having the return type set is really "strongly typed", seems like half of the implementation required, but it is a step in the right direction. |
Hi, I've released https://github.com/Quramy/ngx-typed-forms for workaround of this issue. Please check it out 😄 |
@Quramy I tried to use your package several weeks ago and as I remember, it doesn't really do a lot of enforcement :( |
PR #43834 merged the new types, and is released in You can now try out typed forms by switching to the |
I've tried new typed forms (Angular 14.0.0-next.12, TS 4.6.3 and TS 4.7.beta), and right now I don't quite understand how to use types with them.
Is it how it's supposed to work? |
One more question: how to remove a control now?
The only workaround I've found is |
One more thing: |
Sorry for posting a lot, but one more thing: TypeScript goes crazy when it has to parse code with some typed FormGroup. CPU skyrockets. It's just my wild assumption, but looks like there are some endless recursions. |
@e-oz Given your form consists of the following: interface Person {
firstName: string;
lastName: string;
}
const form = this.fb.group<IPerson>({
firstName: '',
lastName: '',
}); Typescript is complaining that the argument given of type string is not assignable to any of your forms parameters => 1.) Casting the function to type any form.controls.forEach((attr) => {
form.removeControl<any>(attr);
}); 2.) Casting the string form.controls.forEach((attr: keyof Person) => {
form.removeControl(attr);
}); |
Thanks, @fen89 , but my form has type Record<string, ComplicatedTypeHere>, so it should have string keys. |
We are using control types -- rely on the inference, or try
You need to add the following option to your constructor:
This is a use case for
Declare the control as optional (
This one is tricky to fix, unfortunately. I'm working on it, I'll post back with updates. |
@e-oz This is a perfect use case for (You could also use an index signature: |
More updates from me. With the time I've found ways how to use new forms more efficiently, and I can't imagine how sweet it will be with FormRecord, because it's pretty sweet already right now :) Thank you very much for implementing this feature!
Thanks again, I love to use new forms :) |
@e-oz Are you using IntelliJ/WebStorm? The crazy CPU usage is caused by a bug in WebStorm's TypeScript integration (which is not the standard language server; it's unique to WebStorm). We are working with Jetbrains currently, and hope to have it resolved soon. If you're using another IDE, that's concerning and I'd love to hear details. |
@dylhunn I use IntelliJ IDEA (not Webstorm, but from the same family). I've checked the code in VS Code and it works fine ("TypeScript: Tsdk" setting is set to "./node_modules/typescript/lib"). |
The performance issues with Jetbrains IDEs (Webstorm, IntelliJ) should be fixed in version 2022.1.1. Let us know if any issues are still occurring at that version or later. |
Hey all, here's a drop-in alternative while waiting for this issue to be resolved. npm package: ngx-forms-typed - https://www.npmjs.com/package/ngx-forms-typed |
Hi everyone! I'm thrilled to say that typed reactive forms will be landing today in Angular 14. If you discover any bugs, please open a new issue to report them. Although there are some more improvements we'd like to make in the future, such as changes to template type checking, we will track those on a different issue. |
Official doc about this fantastic featureWhen I came to this issue I tried to find the documentation and so I thought it is good to add it at the end of this discussion for those who wanted to immediately heave into it. |
@kasir-barati I'm finally getting around to doing this upgrade and I found a mismatch between the docs and the actual behavior. I think an API change is probably in order, but if not, at least the docs should be updated to match behavior. The docs say that
This is not true, the type is inferred as I think the constructor for constructor(initialValue: T, opts: {nonNullable: true})
constructor(initialValue: T|null)
constructor(initialValue: T|null, opts?: {nonNullable: true}) though I'm not sure what class generic param will be inferred for |
@thw0rted It'll be |
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. |
Reactive forms is meant to be used in complex forms but control's
valueChanges
areObservable<any>
, which are totally against good practices for complex code.There should be a way to create strongly typed form controls.
The text was updated successfully, but these errors were encountered: