-
-
Notifications
You must be signed in to change notification settings - Fork 56
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
Uninitialized FormControl can generate runtime errors #97
Comments
We mimic the same functionality of Angular.
You can add it: |
Thanks. I would argue this doesn't follow the principle of least surprise. I feel the type system is lying to me at this point. Regarding Angular, I understand you want to mimic it's functionality but this one is bug inducing. Also by introducing type safety you have already improved and changed the default functionality, so I feel you could go one step further. Maybe the following screenshot will make you reconsider this design decision. Otherwise please feel free to close ;) |
Don't get me wrong. I agree with you. But the focus of this library, at least for step one, is providing a seamless migration. I'll leave it open to v2. |
Sounds good, thanks ;) Have a great Sunday. |
Just a "food for thought" update, I think I got this backwards. Or at least there are other gotchas to be aware of. Angular differs in behavior depending on the form input type:
That kind of behavior is not immediately obvious to me. And I can only imagine you have to plug into the Angular behavior at some point... So to sum up, it may be a good idea to force the developer to handle the null case by forcing him to declare the nullability at the initialization stage,as such:
A runtime error on initializing would be fine since you'd make the mistake once, fix it then move on. |
BREAKING CHANGE: refactor the entire code I completely rewrote the library from scratch for two reasons: 1. Provide as much support as possible without introducing bugs, breaking strict mode, or creating an inconvenient API. 2. Reduce the library size. Here are the changes: - Angular's peer dependency is now `>= 12`. - FormGroup's generic was removed in favor of the **experimental** `ControlsOf` interface. - Remove `mergeValidators`. Use addValidators in v12. - Remove `validateOn`. - Remove `getControl` in favor of `get(key)` or `get(['nested', 'key'])`. - Remove errors typing. - Validators should now be imported from Angular. - `FormBuilder` doesn't support generic anymore. Due to the complexity of the builder API, we're currently couldn't create a "good" implementation of `ControlsOf` for the builder. - Remove the `group.persist()` from the instance to an exported function to make it tree-shakeable. Fixes #197,#103,#102,#97,#100
I am closing this issue as I released v3. |
I'm submitting a...
Current behavior
Hello, neat library ;) And looking to be a great time saver
I'm puzzled by the possibility of initializing a
FormControl
with bad data. Please see the following screenshots:Here, I forgot to initialize the
activityName
form control with a value.Later, I feed this form control to a function that requires a string:
The compiler doesn't have my back unfortunately, and I get a runtime error!
Expected behavior
I would expect to have as much type safety as possible at compile time.
I'm not familiar with writing generics producing code. But a quick prototype shows me it is possible to add this constraint at the language level.
Is this a bug? I can't se a valid use case for the current behavior.
I can see you mark the formState as optional here:
reactive-forms/projects/ngneat/reactive-forms/src/lib/formControl.ts
Line 70 in 4c886dc
If that's really a necessity, I would expect the underlying form control value to return a
string | undefined
(which would still be annoying be better than getting a runtime error)Thanks :)
The text was updated successfully, but these errors were encountered: