It's perfectly valid for an abstract control not to have a defined parent; yet previously the
types were asserting that AbstractControl#parent is not a null value. This changes correctly
reflects the run-time behavior through the types.
BREAKING CHANGE: Type of AbstractFormControl.parent now includes null
`null` is now included in the types of .parent. If you don't already have a check for this case,
the TypeScript compiler might compain. A v11 migration exists which adds the not-null assertion
operator where necessary.
In an unlikely case your code was testing the parnet against undefined with sitrct equality,
you'll need to change this to `=== null` instead, since the parent is not explicily initialized
with `null` instead of being left `undefined`.
Fixes#16999
PR Close#32671
NG_VALUE_ACCESSOR is a multi injection token, users can and
should expect more than one ControlValueAccessor to be
available (and this is how it is used in @angular/forms).
This is now reflected in the definition of the injection token
by typing it as an array of ControlValueAccessor. The motivating
reason is that using the programmatic Injector api will now
type Injector#get correspondingly.
fixes#29351
BREAKING CHANGES
NG_VALUE_ACCESSOR is now typed as a readonly array rather than
a mutable scalar. It is used as a multi injection token and as
such it should always be expected that more than one accessor
may be returned.
PR Close#29723
This commit ensures that the `updateValueAndValidity` method takes the
`asyncValidator` into consideration to emit on the `statusChanges` observables.
This is necessary so that any subsequent changes are emitted properly to any
subscribers.
Closes#20424Closes#14542
BREAKING CHANGE:
Previously if FormControl, FormGroup and FormArray class instances had async validators
defined at initialization time, the status change event was not emitted once async validator
completed. After this change the status event is emitted into the `statusChanges` observable.
If your code relies on the old behavior, you can filter/ignore this additional status change
event.
PR Close#38354
Prior to this commit, a lot of internal-only class properties and methods (such as `ngOnChanges`)
of the Forms package directives were exposed on angular.io website. These fields are not expected
to be called externally (they are used/invoked by framework only), since they are part of internal
implementations of the following interfaces:
* Angular lifecycle hook interfaces
* ControlValueAccessor interface
* Validator interface
Having these internal-only fields in docs creates unnecessary noise on directive detail pages.
This commit adds the `@nodoc` annotation to these properties and methods to keep fields in the
golden files, but hide them in docs.
PR Close#38583
This commit adds a guard before throwing any forms errors. This will tree-shake
error messages which cannot be minified. It should also help to reduce the
bundle size of the `forms` package in production by ~20%.
Closes#37697
PR Close#37821
This commit performs minor refactoring in Forms package to get rid of duplicate functions.
It looks like the functions were duplicated due to a slightly different type signatures, but
their logic is completely identical. The logic in retained functions remains the same and now
these function also accept a generic type to achieve the same level of type safety.
PR Close#38371
A util file is added to forms test package:
- it exposes simpleAsyncValidator, asyncValidator and asyncValidatorReturningObservable validators
- it refactors simpleAsyncValidator and asyncValidator to use common promise creation code
- it exposes currentStateOf allowing to get the validation state of a list of AbstractControl
Closes#37831
PR Close#38020
This commit refactors the way we store validators in AbstractControl-based classes:
in addition to the combined validators function that we have, we also store the original list of validators.
This is needed to have an ability to clean them up later at destroy time (currently it's problematic since
they are combined in a single function).
The change preserves backwards compatibility by making sure public APIs stay the same.
The only public API update is the change to the `AbstractControl` class constructor to extend the set
of possible types that it can accept and process (which should not be breaking).
PR Close#37881
Previously, `registerOnChange` used `hasOwnProperty` to identify if the
property is supported. However, this does not work as the `selectedOptions`
property is an inherited property. This commit fixes this by verifying
the property on the prototype instead.
Closes#37433
PR Close#37620
introduce a boolean to track form groups/arrays own pending async validation to distinguish between pending state due to children and pending state due to own validation
Fixes#10064
PR Close#22575
Error message mention that ngModel and ngModelChange will be removed in Angular v7 but right not now sure when it will be removed so changed it to a future version
PR Close#37643
The method was previously looping through all controls, even after finding at least one that
satisfies the provided condition. This can be a bottleneck with large forms. The new version
of the method returns as soon as a single control which conforms to the condition is found.
PR Close#32534
Use an explicit type guard when checking if a given object is of type AbstractControlOptions,
instead of a simple function returning a boolean value. This allows us to remove manual type
casting when using this function, relying instead on TypeScript to infer correct types.
PR Close#32541
Remove `looseIdentical` implementation and instead use the ES2015 `Object.is` in its place.
They behave exactly the same way except for `+0`/`-0`.
`looseIdentical(+0, -0)` => `true`
`Object.is(+0, -0)` => `false`
Other than the difference noted above, this is not be a breaking change because:
1. `looseIdentical` is a private API
2. ES2015 is listed as a mandatory polyfill in the [browser support
guide](https://angular.io/guide/browser-support#mandatory-polyfills)
3. Also note that `Ivy` already uses `Object.is` in `bindingUpdated`.
PR Close#37191
Due to an outage with the proxy we rely on for publishing, we need
to temporarily directly publish to NPM using our own angular
credentials again.
PR Close#37378
Tslib version is bound to the TypeScript version used to compile the library. Thus, we shouldn't list `tslib` as a `peerDependencies`. This is because, a user can install libraries which have been compiled with older versions of TypeScript and thus require multiple `tslib` versions to be installed.
Reference: TOOL-1374 and TOOL-1375
Closes: #37188
PR Close#37198
In the code example of the AsyncValidator example there was an aliased
import for the rxjs operator `of`. To align with the RxJS docs it should
just use a plain import of `of`
PR Close#36856
Prior to this commit, number input fields would to fire valueChanges twice: once for `input` events when typing and second for the `change` event when the field lost focus (both events happen at once when using the increment and decrement buttons on the number field).
Fixes#12540
BREAKING CHANGE: Number inputs no longer listen to the `change` event.
* Tests which trigger `change` events need to be updated to trigger `input` events instead.
* The `change` event was in place to support IE9, as we found that `input` events were not fired with backspace or cut actions. If you need to maintain IE9 support, you will need to add a change event listener to number inputs and call the `onChange` method of `NumberValueAccessor` manually.
* Lastly, old versions of WebDriver would synthetically trigger the `change` event on `WebElement.clear` and `WebElement.sendKeys`. If you are using an old version of WebDriver, you may need to update tests to ensure `input` events are triggered. For example, you could use `element.sendKeys(Keys.chord(Keys.CONTROL, "a"), Keys.BACK_SPACE);` in place of `element.clear()`.
PR Close#12540
PR Close#36087
We can remove all of the entry point resolution configuration from the package.json
in our source code as ng_package rule adds the properties automatically and correctly
configures them.
This change simplifies our code base but doesn't have any impact on the package.json
in the distributed npm_packages.
PR Close#36944
Previously, the behavior of the `minLength` and `maxLength` validators
caused confusion, as they appeared to work with numeric values but
did not in fact produce consistent results. This commit fixes the issue
by skipping validation altogether when a numeric value is used.
BREAKING CHANGES:
* The `minLength` and `maxLength` validators now verify that a value has
numeric `length` property and invoke validation only if that's the case.
Previously, falsey values without the length property (such as `0` or
`false` values) were triggering validation errors. If your code relies on
the old behavior, you can include other validators such as [min][1] or
[requiredTrue][2] to the list of validators for a particular field.
[1]: https://angular.io/api/forms/Validators#min
[2]: https://angular.io/api/forms/Validators#requiredTrueCloses#35591
PR Close#36157
Previously, it was not clear that the `minLength` and `maxLength` validators
can only be used with objects that contain a `length` property. This commit
clarifies this.
PR Close#36297
ts-api-guardian uses `require.resolve` to resolve the actual and golden files under bazel. In Windows for these files to be resolved correct the full path including the workspace name as per the MANIFEST entries is required.
This used to be the case until the recent changes done to use npm_integration tests
83c74ceacf/tools/public_api_guard/public_api_guard.bzl (L19)83c74ceacf/tools/public_api_guard/public_api_guard.bzl (L28)
```
bazel test //packages/... --test_tag_filters=api_guard
//packages/animations:animations_api (cached) PASSED in 18.4s
//packages/common:common_api (cached) PASSED in 25.5s
//packages/compiler-cli:compiler_options_api (cached) PASSED in 12.4s
//packages/compiler-cli:error_code_api (cached) PASSED in 11.6s
//packages/core:core_api (cached) PASSED in 20.6s
//packages/core:ng_global_utils_api (cached) PASSED in 13.5s
//packages/elements:elements_api (cached) PASSED in 11.9s
//packages/forms:forms_api (cached) PASSED in 13.9s
//packages/http:http_api (cached) PASSED in 14.8s
//packages/localize:localize_api (cached) PASSED in 6.3s
//packages/platform-browser:platform-browser_api (cached) PASSED in 18.1s
//packages/platform-browser-dynamic:platform-browser-dynamic_api (cached) PASSED in 14.0s
//packages/platform-server:platform-server_api (cached) PASSED in 13.9s
//packages/platform-webworker:platform-webworker_api (cached) PASSED in 13.7s
//packages/platform-webworker-dynamic:platform-webworker-dynamic_api (cached) PASSED in 11.7s
//packages/router:router_api (cached) PASSED in 19.9s
//packages/service-worker:service-worker_api (cached) PASSED in 18.1s
//packages/upgrade:upgrade_api (cached) PASSED in 13.5s
```
Reference: DEV-71
PR Close#36034
Moves the public api .d.ts files from tools/public_api_guard to
goldens/public-api.
Additionally, provides a README in the goldens directory and a script
assist in testing the current state of the repo against the goldens as
well as a command for accepting all changes to the goldens in a single
command.
PR Close#35768
* it's tricky to get out of the runfiles tree with `bazel test` as `BUILD_WORKSPACE_DIRECTORY` is not set but I employed a trick to read the `DO_NOT_BUILD_HERE` file that is one level up from `execroot` and that contains the workspace directory. This is experimental and if `bazel test //:test.debug` fails than `bazel run` is still guaranteed to work as `BUILD_WORKSPACE_DIRECTORY` will be set in that context
* test //integration:bazel_test and //integration:bazel-schematics_test exclusively
* run "exclusive" and "manual" bazel-in-bazel integration tests in their own CI job as they take 8m+ to execute
```
//integration:bazel-schematics_test PASSED in 317.2s
//integration:bazel_test PASSED in 167.8s
```
* Skip all integration tests that are now handled by angular_integration_test except the tests that are tracked for payload size; these are:
- cli-hello-world*
- hello_world__closure
* add & pin @babel deps as newer versions of babel break //packages/localize/src/tools/test:test
@babel/core dep had to be pinned to 7.6.4 or else //packages/localize/src/tools/test:test failed. Also //packages/localize uses @babel/generator, @babel/template, @babel/traverse & @babel/types so these deps were added to package.json as they were not being hoisted anymore from @babel/core transitive.
NB: integration/hello_world__systemjs_umd test must run with systemjs 0.20.0
NB: systemjs must be at 0.18.10 for legacy saucelabs job to pass
NB: With Bazel 2.0, the glob for the files to test `"integration/bazel/**"` is empty if integation/bazel is in .bazelignore. This glob worked under these conditions with 1.1.0. I did not bother testing with 1.2.x as not having integration/bazel in .bazelignore is correct.
PR Close#33927
In https://github.com/angular/angular/pull/33058, we removed support
for the `ngForm` selector in the NgForm directive. We deleted most
of the deprecation notices in that PR, but we missed a paragraph
of documentation in the API docs for NgForm.
This commit removes the outdated paragraph that makes it seem like
the selector is still around and deprecated (as opposed to removed),
as it might confuse users.
PR Close#35435
There is currently a bug in Chrome 80 that makes Array.reduce
not work according to spec. The functionality in forms that
retrieves controls from FormGroups and FormArrays (`form.get`)
relied on Array.reduce, so the Chrome bug broke forms for
many users.
This commit refactors our forms code to rely on Array.forEach
instead of Array.reduce to fix forms while we are waiting
for the Chrome fix to go live.
See https://bugs.chromium.org/p/chromium/issues/detail?id=1049982.
PR Close#35349
we should be documenting when an API is eligible for removal and not when it will be removed.
The actual removal depends on many factors, e.g. if we were able to automate the refactoring to
the recommended API in time or not.
PR Close#35263
The value changes emitted additionally when enable disable were called
documented the above behaviour in AbstractControl class documentaion
Fixes#34407
PR Close#34497
The major one that affects the angular repo is the removal of the bootstrap attribute in nodejs_binary, nodejs_test and jasmine_node_test in favor of using templated_args --node_options=--require=/path/to/script. The side-effect of this is that the bootstrap script does not get the require.resolve patches with explicitly loading the targets _loader.js file.
PR Close#34736
Both `MinLengthValidator` and `MaxLengthValidator` accepted only string inputs for the length required, which throws with Ivy and `fullTemplateTypeCheck` enabled:
<!-- min = 2 in the component -->
<input [minlength]="min">
with:
Type 'number' is not assignable to type 'string | undefined'
This relaxes the accepted type to `string | number` to avoid breakage when developers switch to Ivy and fTTC.
PR Close#32057
The major one that affects the angular repo is the removal of the bootstrap attribute in nodejs_binary, nodejs_test and jasmine_node_test in favor of using templated_args --node_options=--require=/path/to/script. The side-effect of this is that the bootstrap script does not get the require.resolve patches with explicitly loading the targets _loader.js file.
PR Close#34589
With 5cecd97493 we intended to expand
the input type of the `disabled` input of the `NgModel` directive.
Read more about the reason for this in the actual commit message.
Currently though, the acceptance coercion member does not have any
effect. This is because the acceptance member needs to refer to the
actual input property name, and not to the public input name.
`disabled` corresponds to the `isDisabled` property.
PR Close#34502
NgModel internally coerces any arbitrary value that will assigned
to the `disabled` `@Input` to a boolean. This has been done to
support the common case where developers set the disabled attribute
without a value. For example:
```html
<input type="checkbox" [(ngModel)]="value" disabled>
```
This worked in View Engine without any errors because inputs were
not strictly checked. In Ivy though, developers can opt-in into
strict template type checking where the attribute would be flagged.
This is because the `NgModel#isDisabled` property type-wise only
accepts a `boolean`. To ensure that the common pattern described
above can still be used, and to reflect the actual runtime behavior,
we should add an acceptance member that makes it work without type
checking errors.
Using a coercion member means that this is not a breaking change.
PR Close#34438
Currently we only run Saucelabs on PRs using the legacy View Engine
build. Switching that build to Ivy is not trivial and there are various
options:
1. Updating the R3 switches to use POST_R3 by default. At first glance,
this doesn't look easy because the current ngtsc switch logic seems to
be unidirectional (only PRE_R3 to POST_R3).
2. Updating the legacy setup to run with Ivy. This sounds like the easiest
solution at first.. but it turns out to be way more complicated. Packages
would need to be built with ngtsc using legacy tools (i.e. first building
the compiler-cli; and then building packages) and View Engine only tests
would need to be determined and filtered out. Basically it will result in
re-auditing all test targets. This is contradictory to the fact that we have
this information in Bazel already.
3. Creating a new job that runs tests on Saucelabs with Bazel. We specify
fine-grained test targets that should run. This would be a good start
(e.g. acceptance tests) and also would mean that we do not continue maintaining
the legacy setup..
This commit implements the third option as it allows us to move forward
with the general Bazel migration. We don't want to spend too much time
on our legacy setup since it will be removed anyway in the future.
PR Close#34277
This commit fixes a compatibility bug where pre-order lifecycle
hooks (onInit, doCheck, OnChanges) for directives on the same
host node were executed based on the order the directives were
matched, rather than the order the directives were instantiated
(i.e. injection order).
This discrepancy can cause issues with forms, where it is common
to inject NgControl and try to extract its control property in
ngOnInit. As the NgControl directive is injected, it should be
instantiated before the control value accessor directive (and
thus its hooks should run first). This ensures that the NgControl
ngOnInit can set up the form control before the ngOnInit
for the control value accessor tries to access it.
Closes#32522
PR Close#34026
This is a breaking change in nodejs rules 0.40.0 as part of the API review & cleanup for the 1.0 release. Their APIs are identical as ts_web_test was just karma_web_test without the config_file attribute.
PR Close#33802
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
BREAKING CHANGE:
We no longer directly have a direct depedency on `tslib`. Instead it is now listed a `peerDependency`.
Users not using the CLI will need to manually install `tslib` via;
```
yarn add tslib
```
or
```
npm install tslib --save
```
PR Close#32167
Removes the deprecated `ngForm` element selector and all of the code related to it.
BREAKING CHANGES:
* `<ngForm></ngForm>` can no longer be used as a selector. Use `<ng-form></ng-form>` instead.
* The `NgFromSelectorWarning` directive has been removed.
* `FormsModule.withConfig` has been removed. Use the `FormsModule` directly.
PR Close#33058
As mentioned in the previous commit, the regexp used by
`Validators.email()` is a slightly enhanced version of the
[WHATWG one](https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address).
This commit refactors the regexp (without changing its behavior) to make
it more closely match the format of WHATWG version, so that it is easier
for people to compare it against the WHATWG one and understand the
differences.
The main changes were:
- Changing the order of characters/character classes inside `[...]`;
e.g. `[A-Za-z]` --> `[a-zA-Z]`
- Mark all groups as non-capturing (since we do not use the captured
values); e.g. `(foo)` --> `(?:foo)`
(This could theoretically also have a positive performance impact, but
I suspect JavaScript engines are already optimizing away capturing
groups when they are not used.)
PR Close#32961
Previously, there was no documentation of what `Validators.email()`
expects as a valid e-mail address, making it difficult for people to
determine whether it covers their requirements or not. Even more so that
the used pattern slightly deviates from the
[WHATWG version](https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address).
One's only option was to look at the source code and try to decipher the
regexp pattern.
This commit adds a high-level description of the validator and mentions
its similarity to and differences from the WHATWG version. It also adds
a brief explanation of the regexp's behavior and references for more
information in the source code to provide more context to
maintainers/users trying to understand the implementation in the future.
Fixes#18985Fixes#25186Closes#32747
PR Close#32961
This commit relaxes the type of the `formControlName` input to accept both a `string` and a `number`.
Currently, when using a `FormArray`, most templates look like:
```
<div formArrayName="tags">
<div *ngFor="let tag of tagsArray.controls; index as i">
<input [formControlName]="i">
</div>
</div>
```
Here `formControlName` receives a number whereas its input type is a string.
This is fine for VE and `fullTemplateTypeCheck`, but not for Ivy which does a more thorough type checking on inputs with `fullTemplateTypeCheck` enabled and throws `Type 'number' is not assignable to type 'string'`. It is fixable by using `formControlName="{{i}}"` but you have to know the difference between `a="{{b}}"` and `[a]="b"` and change it all over the application codebase. This commit allows the existing code to still type-check.
PR Close#30606
This commit relaxes the type of the `formControlName` input to accept both a `string` and a `number`.
Currently, when using a `FormArray`, most templates look like:
```
<div formArrayName="tags">
<div *ngFor="let tag of tagsArray.controls; index as i">
<input [formControlName]="i">
</div>
</div>
```
Here `formControlName` receives a number whereas its input type is a string.
This is fine for VE and `fullTemplateTypeCheck`, but not for Ivy which does a more thorough type checking on inputs with `fullTemplateTypeCheck` enabled and throws `Type 'number' is not assignable to type 'string'`. It is fixable by using `formControlName="{{i}}"` but you have to know the difference between `a="{{b}}"` and `[a]="b"` and change it all over the application codebase. This commit allows the existing code to still type-check.
PR Close#30606
Fixes all TypeScript failures caused by enabling the `--strict`
flag for test source files. We also want to enable the strict
options for tests as the strictness enforcement improves the
overall codehealth, unveiled common issues and additionally it
allows us to enable `strict` in the `tsconfig.json` that is picked
up by IDE's.
PR Close#30993
lazarljubenovic
Ingo Bürk
Oscar Rosner
Sonu Kapoor
Juan José Arboleda
Andrew Kushnir
JiaLiPassion
Oussama Ben Brahim
Georgi K
danranVm
Ajit Singh
Aamir Mukaram
Joey Perrott
Andrew Scott
Alan Agius
Jan-Niklas W
Tidi
Paul Gschwendtner
Igor Minar
Greg Magolan
Judy Bogart
Stanislav Usov
crisbeto
Joey Perrott
Felix Becker
Kara Erickson
Francesco Leardini
cexbrayat
atscott
7006
Miško Hevery
Christopher Dahm
Robin Dupret
Colum Ferry
Nikita Potapenko
Danny Skoog
LASLEDJ
George Kalpakas
Alex Eagle
Filipe Silva
Ly-lns
benbot1
Vinit Tomar
Ben Lesh
John Reese
Renan Montebelo