Commit Graph

228 Commits

Author SHA1 Message Date
atscott 5e60215470 Revert "test: handle bootstrap templated_args in jasmine_node_test defaults.bzl (#34589)" (#34730)
This reverts commit da4782e67f.

PR Close #34730
2020-01-10 14:12:15 -08:00
atscott 24679d8676 Revert "build: derive ts_library dep from jasmine_node_test boostrap label if it ends in `_es5` (#34589)" (#34730)
This reverts commit 79a0d007b4.

PR Close #34730
2020-01-10 14:12:14 -08:00
Greg Magolan 79a0d007b4 build: derive ts_library dep from jasmine_node_test boostrap label if it ends in `_es5` (#34589)
PR Close #34589
2020-01-10 08:32:00 -08:00
Greg Magolan da4782e67f test: handle bootstrap templated_args in jasmine_node_test defaults.bzl (#34589)
PR Close #34589
2020-01-10 08:31:59 -08:00
Greg Magolan 9bb349e1c8 refactor: handle breaking changes in rules_nodejs 1.0.0 (#34589)
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
2020-01-10 08:31:59 -08:00
Paul Gschwendtner 6315acae94 fix(forms): disabled input acceptance member not properly applied (#34502)
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
2020-01-09 15:12:09 -08:00
7006 18d89c9c89 docs(forms): remove redundant word (#34584)
PR Close #34584
2020-01-07 10:59:51 -08:00
Paul Gschwendtner 5cecd97493 feat(forms): expand NgModel disabled type to work with strict template type checking (#34438)
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
2019-12-16 15:34:03 -08:00
Paul Gschwendtner 6d3a25d897 ci: run acceptance tests on saucelabs with ivy (#34277)
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
2019-12-16 07:43:41 -08:00
Miško Hevery 85b551a388 Revert "refactor: use isObservable provided by rxjs 6.1+ (#27668)"
This reverts commit 92c547830a.
2019-11-27 13:00:59 -08:00
Christopher Dahm 92c547830a refactor: use isObservable provided by rxjs 6.1+ (#27668)
Refactor common, core, forms, router to use the isObservable method from rxjs 6.1+. Remove the isObservable method from core.

PR Close #27668
2019-11-27 10:33:45 -08:00
Kara Erickson 1a0ee18d62 fix(ivy): run pre-order hooks in injection order (#34026)
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
2019-11-25 18:41:22 -05:00
Miško Hevery a681c8553a fix(ivy): shadow all DOM properties in `DebugElement.properties` (#33781)
Fixes #33695

PR Close #33781
2019-11-18 15:49:22 -08:00
Greg Magolan 9a68f23dd2 build: ts_web_test & ts_web_test_suite deprecated in favor of karma_web_test & karma_web_test_suite (#33802)
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
2019-11-13 13:33:38 -08:00
Joey Perrott 1d563a7acd build: set up all packages to publish via wombot proxy (#33747)
PR Close #33747
2019-11-13 11:34:33 -08:00
Robin Dupret 602eeee7d6 docs(forms): Add a missing space (#33352)
PR Close #33352
2019-10-31 23:46:54 +00:00
Kara Erickson 383457f898 docs: clean up deprecation guide (#33338)
PR Close #33338
2019-10-23 09:11:13 -07:00
Colum Ferry 403bb6bee3 docs(forms): fix grammar and add clarification to setValue docs (#33126)
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
2019-10-21 15:58:38 -04:00
Igor Minar 86e1e6c082 feat: typescript 3.6 support (#32946)
BREAKING CHANGE: typescript 3.4 and 3.5 are no longer supported, please update to typescript 3.6

Fixes #32380

PR Close #32946
2019-10-18 13:15:16 -04:00
Alan Agius e2d5bc2514 feat: change tslib from direct dependency to peerDependency (#32167)
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
2019-10-14 16:34:47 +00:00
crisbeto 0b1daa9ebd refactor(forms): remove ngForm element selector (#33058)
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
2019-10-11 15:43:56 -07:00
Nikita Potapenko f54adf10b5 refactor(forms): replace instanceof Array (#33078)
PR Close #33078
2019-10-10 15:24:45 -07:00
Danny Skoog 6ab5f3648a refactor: utilize type narrowing (#33075)
PR Close #33075
2019-10-10 15:18:44 -07:00
LASLEDJ fee28e20bb feat(forms): formGroupName and formArrayName also accepts a number (#32607)
For consistency, `FormGroupName` and `FormaArrayName` also accepts a
number as input's type like `FormControlName`

Closes https://github.com/angular/angular/issues/32436

PR Close #32607
2019-10-07 11:00:49 -07:00
George Kalpakas e007918e35 refactor(forms): refactor `Validators.email()` regexp for easier comparison with WHATWG version (#32961)
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
2019-10-07 10:51:00 -07:00
George Kalpakas 3c2770bfc7 docs(forms): expand e-mail validation description (#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 #18985
Fixes #25186
Closes #32747

PR Close #32961
2019-10-07 10:51:00 -07:00
Alan Agius 66658c447f feat: update rxjs peerDependencies minimum requirment to 6.5.3 (#32812)
PR Close #32812
2019-10-01 14:56:45 -07:00
lazarljubenovic 18798a1cb2 docs(forms): correct parameter names in jsdoc (#32530)
PR Close #32530
2019-09-09 15:55:42 -04:00
Misko Hevery 8a47b48912 refactor: Move `dom_adapter.ts` to `@angular/common` (#32154)
This work is needed in preparation for turning tokens into tree-shakable injectables.

PR Close #32154
2019-08-29 21:51:56 -07:00
Kara Erickson ede5786d1e refactor(core): remove testing-only style utils from DomAdapters (#32291)
PR Close #32291
2019-08-28 17:10:29 -07:00
cexbrayat 628b0c1154 feat(forms): formControlName also accepts a number (#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
2019-08-13 14:21:25 -07:00
Kara Erickson 9a37e827e2 Revert "feat(forms): formControlName also accepts a number (#30606)" (#32088)
This reverts commit a647298412.

PR Close #32088
2019-08-09 17:29:27 -07:00
cexbrayat a647298412 feat(forms): formControlName also accepts a number (#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
2019-08-09 10:39:22 -07:00
Igor Minar 6ece7db37a build: TypeScript 3.5 upgrade (#31615)
https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes#typescript-35

PR Close #31615
2019-07-25 17:05:23 -07:00
George Kalpakas 1bcd58cee8 refactor(docs-infra): remove `linenums=false` since it is now the default (#31674)
PR Close #31674
2019-07-24 14:38:54 -07:00
Paul Gschwendtner 647d7bdd88 refactor: fix typescript strict flag failures in all tests (#30993)
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
2019-07-18 14:21:26 -07:00
Paul Gschwendtner 221cbd0b47 refactor(forms): ensure compatibility with typescript strict flag (#30993)
As part of FW-1265, the `@angular/forms` package is made compatible
with the TypeScript `--strict` flag. Read more about the strict flag [here](https://www.typescriptlang.org/docs/handbook/compiler-options.html)

PR Close #30993
2019-07-18 14:21:26 -07:00
Judy Bogart 54794f9b31 docs: clarify docs for runtime validation change (#31596)
PR Close #31596
2019-07-16 23:58:11 -04:00
Alex Eagle ef0b2cc74d build: convert entry_point to label (#30627)
PR Close #30627
2019-06-11 00:03:11 +00:00
Alex Eagle 337b6fe003 build: remove unreferenced tsconfig-build.json files (#30858)
These are no longer needed since Bazel generates a tsconfig for each compilation

PR Close #30858
2019-06-05 09:03:36 -07:00
Filipe Silva ac34a1429b refactor: remove toplevel property accesses (#29329)
PR Close #29329
2019-05-16 12:08:49 -07:00
Ly-lns d2c83ea81b docs(forms): add comment of the value (#29898)
PR Close #29898
2019-05-09 11:25:58 -07:00
benbot1 ea9a381c8c docs(forms): fix import line ending (#30290)
PR Close #30290
2019-05-06 16:05:23 -07:00
Vinit Tomar 39f2c9f46b docs(forms): fix ControlValueAccessor registerOnChange code example (#30276)
PR Close #30276
2019-05-06 09:27:12 -07:00
Ben Lesh 94aeeec1dc build: update rxjs version requirements to 6.4.0 (#30032)
PR Close #30032
2019-04-22 11:15:33 -07:00
John Reese e769f9cfe4 docs(forms): fix small typo in forms documentation (#29370)
PR Close #29370
2019-03-19 13:11:11 -04:00
Renan Montebelo fc305305e1 docs(forms): adding `clear` method to FormArray documentation (#29180)
PR Close #29180
2019-03-08 12:39:18 -08:00
Renan Montebelo a68b1a1894 feat(forms): clear (remove all) components from a FormArray (#28918)
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
2019-03-07 19:52:49 -08:00
Alan e8bb8f4912 build: enable bundle_dts for forms package (#28854)
This PR also changes the name of NgNoValidate` to `ɵNgNoValidate`. This is because `ngcc` requires the node to retain the original name while dts bundler will rename the node is it's only exported using the aliases.

Example typings files:
```ts
declare class NgNoValidate{
}
export {NgNoValidateas ɵNgNoValidate}
```

will be emitted as
```ts
export declare class ɵNgNoValidate {
}
```

PR Close #28854
2019-03-05 11:39:16 -08:00
Greg Magolan ea09430039 build: rules_nodejs 0.26.0 & use @npm instead of @ngdeps now that downstream angular build uses angular bundles (#28871)
PR Close #28871
2019-02-28 12:06:36 -08:00