You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Form controls have internal API that allows subscribing to changes in a data collection of FormGroups and FormArrays (when a new control is added to a collection or existing one is removed). This internal API is used inside FormGroupDirective to trigger DOM updates. The problem with the current API is that there is no way to append a callback or remove a particular one (for ex. a callback that belongs to a directive that is being removed). Instead, new onCollectionChange callback always resets existing one.
We should consider updating the logic that handles onCollectionChange callback to provide an ability to add and remove
particular callbacks without affecting previous callbacks, similar to what we have for onChange callbacks. That should help implement more granular management of the onCollectionChange callbacks.
Note: this change would be backwards-incompatible since some exiting code may rely on the fact that the onCollectionChange callback is getting rewritten. There is a PR #39685 that implements the change proposed in this ticket.
The text was updated successfully, but these errors were encountered:
Form controls have internal API that allows subscribing to changes in a data collection of
FormGroup
s andFormArray
s (when a new control is added to a collection or existing one is removed). This internal API is used insideFormGroupDirective
to trigger DOM updates. The problem with the current API is that there is no way to append a callback or remove a particular one (for ex. a callback that belongs to a directive that is being removed). Instead, newonCollectionChange
callback always resets existing one.We should consider updating the logic that handles
onCollectionChange
callback to provide an ability to add and removeparticular callbacks without affecting previous callbacks, similar to what we have for
onChange
callbacks. That should help implement more granular management of theonCollectionChange
callbacks.Note: this change would be backwards-incompatible since some exiting code may rely on the fact that the
onCollectionChange
callback is getting rewritten. There is a PR #39685 that implements the change proposed in this ticket.The text was updated successfully, but these errors were encountered: