The value changes emitted additionally when enable disable were called
documented the above behaviour in AbstractControl class documentaion
Fixes#34407
PR Close#34497
Changed `setValue` documentation for throwing an error as it contained a grammar
mistake and also may have caused ambiguity around when exactly the
method would throw.
PR Close#33126
This method is a more convenient and efficient way of removing all
components from a FormArray. Before it, we needed to loop the FormArray
removing each component until empty.
Resolves#18531
PR Close#28918
BREAKING CHANGE
Previous to this change, when a control was reset, value and status change
events would be emitted before the control was reset to pristine. As a
result, if one were to check a control's pristine state in a valueChange
listener, it would appear that the control was still dirty after reset.
This change delays emission of value and status change events until after
controls have been marked pristine. This means the pristine state will be
reset as expected if one checks in a listener.
Theoretically, there could be applications depending on checking whether a
control *used to be dirty*, so this is marked as breaking. In these cases,
apps should cache the state on the app side before calling reset.
Fixes#28130
PR Close#28395
Internally getError and hasError call the AbstractControl#get method which takes `path: Array<string | number> | string` as input, since there are different ways to traverse the AbstractControl tree.
This change matches the method signitures of all methods that use this.
PR Close#20211
All errors for existing fields have been detected and suppressed with a
`!` assertion.
Issue/24571 is tracking proper clean up of those instances.
One-line change required in ivy/compilation.ts, because it appears that
the new syntax causes tsickle emitted node to no longer track their
original sourceFiles.
PR Close#24572
closes#17958
BREAKING CHANGE:
- `AbstractControl#statusChanges` now emits an event of `'PENDING'` when you call `AbstractControl#markAsPending`
- Previously it did not emit an event when you called `markAsPending`
- To migrate you would need to ensure that if you are filtering or checking events from `statusChanges` that you account for the new event when calling `markAsPending`
PR Close#20212
Includes:
* display ToC for API docs
* update dgeni-packages to 0.24.1
* add floating sidebar in API docs
* add breadcrumbs and structured data for Google crawler
* improved rendering of method overloads
* properties rendered in a table
* params rendered with docs
* removal of outdated "infobox" from all API docs
PR Close#21874
Previously, the emitEvent flag was only checked when emitting on the current control.
Thus, if the control was part of a hierarchy, events were emitted on the parent and the childrens.
This fixes the issue by properly passing the emitEvent flag to both parent and childrens.
Fixes#12366
PR Close#21018