Skip to content
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

Open
maxime1992 opened this issue Feb 20, 2020 · 7 comments · Fixed by #188
Assignees
Labels
released on @feat-rewrite released scope: lib Anything related to the library itself state: has PR A PR is available for that issue type: bug/fix This is a bug or at least needs a fix workaround: none No workaround

Comments

@maxime1992
Copy link
Contributor

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 and valueChanges.

Issue

This is not working as if we look into the code of ngx-sub-form:

if (shouldDisable) {
this.formGroup.disable({ emitEvent: false });
} else {
this.formGroup.enable({ emitEvent: false });
}

We're not emitting the disable event.

Why was is done that way?

When calling disable or enable methods, the formGroup emits all the values again. Example:

  fg = new FormGroup({
    a: new FormControl(),
  });

  constructor() {
    this.fg.valueChanges.subscribe(x => console.log('VALUE CHANGE'));

    this.fg.disable();
    this.fg.enable();

    this.fg.patchValue({ a: 1 });
  }

Gives us:

VALUE CHANGE
VALUE CHANGE
VALUE CHANGE

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

if (shouldDisable) {
  this.formGroup.disable({ emitEvent: false });
} else {
  this.formGroup.enable({ emitEvent: false });
}

to

if (shouldDisable) {
  this.formGroup.disable();
} else {
  this.formGroup.enable();
}

Can anyone think of a down side? Or confirm that it's probably a good idea?

@maxime1992 maxime1992 added scope: lib Anything related to the library itself state: needs design This feature or fix should be discussed before writing any code type: bug/fix This is a bug or at least needs a fix workaround: none No workaround labels Feb 20, 2020
@maxime1992
Copy link
Contributor Author

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

@tyroneneill
Copy link

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 registerOnDisabledChange(fn: (isDisabled: boolean) => void): void, could we not hook into this to be notified of changes?

It looks to be triggered regardless of the mentioned emitEvent value defined:

image

@maxime1992
Copy link
Contributor Author

maxime1992 commented Apr 22, 2020

Just another thought on that:

If we turn emitEvent to true, with #103 we'd broadcast up an empty object which is likely to be an error.

Also, if the RootForm is disabled we should probably never broadcast any update.

@maxime1992
Copy link
Contributor Author

Discussed offline with @zakhenry and Ty:

  • We should follow what angular does by default: emit the value when the form is enabled/disabled
  • It's easy to not trigger downstreams if needed by just using distinctUntilChanged

To do:

  • Remove the emitEvent: false
  • Do not broadcast the value up for a RootForm if it's disabled

maxime1992 added a commit that referenced this issue Jun 15, 2020
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
@maxime1992 maxime1992 added state: has PR A PR is available for that issue and removed state: needs design This feature or fix should be discussed before writing any code labels Jun 15, 2020
@maxime1992 maxime1992 self-assigned this Jun 15, 2020
@maxime1992
Copy link
Contributor Author

🎉 This issue has been resolved in version 5.2.0-feat-rewrite.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

@maxime1992 maxime1992 linked a pull request Oct 11, 2020 that will close this issue
zakhenry pushed a commit that referenced this issue Oct 23, 2020
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
@zakhenry
Copy link
Contributor

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

maxime1992 added a commit that referenced this issue Nov 21, 2021
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
@github-actions
Copy link

🎉 This issue has been resolved in version 5.2.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
released on @feat-rewrite released scope: lib Anything related to the library itself state: has PR A PR is available for that issue type: bug/fix This is a bug or at least needs a fix workaround: none No workaround
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants