-
Notifications
You must be signed in to change notification settings - Fork 33
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
disabled state is not emitted, blocking external listeners to react to changes of the form's status #143
Comments
Just had a random thought: If we do this before broadcasting the value up we probably want to check that the form is not disabled |
hey @maxime1992 Thank you for the amazing library! Looking through the formGroup I can see retrieving the disabled value is delegated onto the FormControl. The FormControl has the API It looks to be triggered regardless of the mentioned |
Just another thought on that: If we turn Also, if the RootForm is |
Discussed offline with @zakhenry and Ty:
To do:
|
This is a major architecture change which is brought without any breaking change 😄! We've split up the code base in 2: Old one and new one. The old one hasn't moved at all but is now deprecated (not removed yet!). You can keep using the old one for a bit and have a smooth/incremental update to use the new API. Few changes that you have to note with the new API: - Only works with Angular 9 or more - The app needs to have Ivy activated (this is because we use `ɵmarkDirty` internally. If it ever gets removed we'll probably have to ask to provide the `ChangeDetectorRef` but we were able to around this for now!) - We got rid of inheritance 🙌 - Form errors on a FormArray are now an object instead of an array. Previously the array contained null values on all the fields without any error. It's now an object containing only the ones with errors and you can access them using the index Please start upgrading to the new API as soon as possible as we stop supporting the old API as of today and will remove it in a near release. This closes #171 for the major architectural changes and also the following issues as a result: - closes #82 - closes #86 - closes #93 - closes #133 - closes #143 - closes #144 - closes #149 - closes #160 - closes #168
🎉 This issue has been resolved in version 5.2.0-feat-rewrite.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
This is a major architecture change which is brought without any breaking change 😄! We've split up the code base in 2: Old one and new one. The old one hasn't moved at all but is now deprecated (not removed yet!). You can keep using the old one for a bit and have a smooth/incremental update to use the new API. Few changes that you have to note with the new API: - Only works with Angular 9 or more - The app needs to have Ivy activated (this is because we use `ɵmarkDirty` internally. If it ever gets removed we'll probably have to ask to provide the `ChangeDetectorRef` but we were able to around this for now!) - We got rid of inheritance 🙌 - Form errors on a FormArray are now an object instead of an array. Previously the array contained null values on all the fields without any error. It's now an object containing only the ones with errors and you can access them using the index Please start upgrading to the new API as soon as possible as we stop supporting the old API as of today and will remove it in a near release. This closes #171 for the major architectural changes and also the following issues as a result: - closes #82 - closes #86 - closes #93 - closes #133 - closes #143 - closes #144 - closes #149 - closes #160 - closes #168
This has now been reverted in the rewrite, unfortunately the rewrite implementation was causing forms to appear to be changed by the user, causing emit side effects. It will need some deeper thought to resolve this properly |
This is a major architecture change which is brought without any breaking change 😄! We've split up the code base in 2: Old one and new one. The old one hasn't moved at all but is now deprecated (not removed yet!). You can keep using the old one for a bit and have a smooth/incremental update to use the new API. Few changes that you have to note with the new API: - Only works with Angular 9 or more - The app needs to have Ivy activated (this is because we use `ɵmarkDirty` internally. If it ever gets removed we'll probably have to ask to provide the `ChangeDetectorRef` but we were able to around this for now!) - We got rid of inheritance 🙌 - Form errors on a FormArray are now an object instead of an array. Previously the array contained null values on all the fields without any error. It's now an object containing only the ones with errors and you can access them using the index Please start upgrading to the new API as soon as possible as we stop supporting the old API as of today and will remove it in a near release. This closes #171 for the major architectural changes and also the following issues as a result: - closes #82 - closes #86 - closes #93 - closes #133 - closes #143 - closes #144 - closes #149 - closes #160 - closes #168
🎉 This issue has been resolved in version 5.2.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Context
A classic way of showing that the form is invalid and cannot be saved is by disabling the "send" button.
As we deal with a lot of real time data we're using
NgxAutomaticRootFormComponent
quite a lot and therefore, on these kind of forms, we don't have a save button.To show the user some global feedback on the form we've created a component that takes the formgroup as input and listen to both
statusChanges
andvalueChanges
.Issue
This is not working as if we look into the code of ngx-sub-form:
ngx-sub-form/projects/ngx-sub-form/src/lib/ngx-sub-form.component.ts
Lines 417 to 421 in b8890b8
We're not emitting the disable event.
Why was is done that way?
When calling
disable
orenable
methods, the formGroup emits all the values again. Example:Gives us:
After all, maybe this is expected as it's Angular's behavior anyway but I'm just trying to think if there's any downside updating the code above from
to
Can anyone think of a down side? Or confirm that it's probably a good idea?
The text was updated successfully, but these errors were encountered: