Commit Graph

971 Commits

Author SHA1 Message Date
Kara Erickson 014841dfef test(ivy): fix failing view ref test (#29178)
PR Close #29178
2019-03-07 18:56:22 -08:00
Andrew Kushnir fd5cd100a3 fix(ivy): move i18n instructions after listener ones (#29173)
Prior to this commit, i18n instructions (i18n, i18nStart) were generated before listener instructions. As a result, event listeners were attached to the wrong element (text node, not the parent element). This change updates the order of instructions and puts i18n ones after listeners, to make sure listeners are attached to the right elements.

PR Close #29173
2019-03-07 15:36:39 -08:00
Pete Bacon Darwin 809452b921 test(ivy): add tests for projection on inline-templates (#29041)
PR Close #29041
2019-03-07 11:27:36 -08:00
Pete Bacon Darwin f535f31d78 fix(ivy): match attribute selectors for content projection with inline-templates (#29041)
The content projection mechanism is static, in that it only looks at the static
template nodes before directives are matched and change detection is run.
When you have a selector-based content projection the selection is based
on nodes that are available in the template.

For example:

```
<ng-content selector="[some-attr]"></ng-content>
```

would match

```
<div some-attr="..."></div>
```

If you have an inline-template in your projected nodes. For example:

```
<div *ngIf="..." some-attr="..."></div>
```

This gets pre-parsed and converted to a canonical form.

For example:

```
<ng-template [ngIf]="...">
  <div some-attr=".."></div>
</ng-template>
```

Note that only structural attributes (e.g. `*ngIf`) stay with the `<ng-template>`
node. The other attributes move to the contained element inside the template.

When this happens in ivy, the ng-template content is removed
from the component template function and is compiled into its own
template function. But this means that the information about the
attributes that were on the content are lost and the projection
selection mechanism is unable to match the original
`<div *ngIf="..." some-attr>`.

This commit adds support for this in ivy. Attributes are separated into three
groups (Bindings, Templates and "other"). For inline-templates the Bindings
and "other" types are hoisted back from the contained node to the `template()`
instruction, so that they can be used in content projection matching.

PR Close #29041
2019-03-07 11:27:36 -08:00
Pete Bacon Darwin e3a401d20c refactor(ivy): define new `AttributeMarker.Template` marker (#29041)
This commit adds a new `AttributeMarker` type that will be used, in a
future commit, to mark attributes as coming from an inline-template
expansion, rather than the element that is being contained in the template.

PR Close #29041
2019-03-07 11:27:36 -08:00
Pete Bacon Darwin 423ac01dcf refactor: rename `AttributeMarker.ProjectOnly` to `AttributeMarker.Bindings` (#29041)
PR Close #29041
2019-03-07 11:27:35 -08:00
Marc Laval eccbc785b3 fix(ivy): ViewRef.detachFromAppRef should clean the DOM (#29159)
PR Close #29159
2019-03-07 08:56:26 -08:00
Pawel Kozlowski 22ddbf4b02 fix(ivy): content projection should not corrupt TNode data structures (#29130)
PR Close #29130
2019-03-06 11:02:47 -08:00
Pawel Kozlowski 268c3fe816 test(ivy): failing test for FW-1064 (#29130)
PR Close #29130
2019-03-06 11:02:47 -08:00
Andrew Kushnir 84406e4d6d fix(ivy): avoid innerHTML usage in exports test (to make it work in IE11) (#29127)
Some tests in exports spec rely on the exact output of innerHTML. In IE11 the order of attributes might change, thus causing tests to fail (in case an element contains more than one attribute). This commit avoids innerHTML usage and performs the necessary checks via element properties.

PR Close #29127
2019-03-05 21:08:08 -08:00
Kara Erickson c29d2a4f16 test(ivy): fix export tests to work in IE (#29125)
Some of the export tests had assertions that relied on capitalization
of attributes in the DOM. IE treats capitalization somewhat differently,
so our SauceLabs tests were failing.

This commit tweaks the tests so that the assertions do not rely on
attributes to be capitalized or not.

PR Close #29125
2019-03-05 18:02:16 -08:00
Marc Laval 25166d4f41 fix(ivy): support property values changed in ngOnChanges (forward rref case) (#29054)
PR Close #29054
2019-03-05 14:27:08 -08:00
Matias Niemelä 78adcfe0ee fix(ivy): ensure static styling is properly inherited into child components (#29015)
Angular supports having a component extend off of a parent component.
When this happens, all annotation-level data is inherited including styles
and classes. Up until now, Ivy only paid attention to static styling
values on the parent component and not the child component. This patch
ensures that both the parent's component and child component's styling
data is merged and rendered accordingly.

Jira Issue: FW-1081

PR Close #29015
2019-03-04 13:36:19 -08:00
Pawel Kozlowski c875851bb4 fix(ivy): remove query results from embedded views on view destroy (#29056)
PR Close #29056
2019-03-04 10:24:30 -08:00
Kristiyan Kostadinov c0757d1d44 fix(ivy): attached flag not being reset when view is destroyed (#29064)
Currently we only reset the `Attached` flag of a view if it is detached through its parent, however this means that if a root view is destroyed, its flag will never be reset. This manifested itself in one of the Material tests where we were destroying the root view.

This PR resolves FW-1130.

PR Close #29064
2019-03-01 16:56:03 -08:00
Kara Erickson 7ac58bec8a fix(ivy): move views that are already attached in insert() (#29047)
Currently if a user accidentally calls ViewContainerRef.insert() with
a view that has already been attached, we do not clean up the references
properly, so we create a view tree with a cycle. This causes an infinite
loop when the view is destroyed.

This PR ensures that we fall back to ViewContainerRef.move() behavior
if we try to insert a view that is already attached. This fixes the
cycle and honors the user intention.

PR Close #29047
2019-03-01 15:17:24 -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
Matias Niemelä a6ae759b46 fix(animations): ensure `position` and `display` styles are handled outside of keyframes/web-animations (#28911)
When web-animations and/or CSS keyframes are used for animations certain
CSS style values (such as `display` and `position`) may be ignored by a
keyframe-based animation. Angular should special-case these styles to
ensure that they get applied as inline styles throughout the duration of
the animation.

Closes #24923
Closes #25635

Jira Issue: FW-1091
Jira Issue: FW-1092

PR Close #28911
2019-02-27 11:57:31 -08:00
Andrew Kushnir 40833ba54b fix(ivy): process property bindings in i18n blocks similar to non-i18n bindings (#28969)
Prior to this change i18n block bindings were converted to Expressions right away (once we first access them), when in non-i18n cases we processed them differently: the actual conversion happens at instructions generation. Because of this discrepancy, the output for bindings in i18n blocks was generated incorrectly (with invalid indicies in pipeBindN fns and invalid references to non-existent local variables). Now the bindings processing is unified and i18nExp instructions should contain right bind expressions.

PR Close #28969
2019-02-27 11:56:12 -08:00
George Kalpakas 2dd44d712d ci(core): fix `legacy-unit-tests-saucelabs` job (#29009)
Karma is not configured to retrieve the imported scripts using those
absolute deep paths. Using relative paths instead.
See [here][1] for an example failing job.

[1]: https://circleci.com/gh/angular/angular/220751

PR Close #29009
2019-02-27 10:32:40 -08:00
Wassim Chegham dad5a258b8 style: enforce buildifier lint on CI (#28186)
PR Close #28186
2019-02-26 16:57:41 -08:00
Wassim Chegham ce68b4d839 style: enforce buildifier lint on CI (#28186)
PR Close #28186
2019-02-26 16:57:41 -08:00
George Kalpakas 262ba67525 fix(core): traverse and sanitize content of unsafe elements (#28804)
In the past, the sanitizer would remove unsafe elements, but still
traverse and sanitize (and potentially preserve) their content. This was
problematic in the case of `<style></style>` tags, whose content would
be converted to HTML text nodes.

In order to fix this, the sanitizer's behavior was changed in #25879 to
ignore the content of _all_ unsafe elements. While this fixed the
problem with `<style></style>` tags, it unnecessarily removed the
contents for _any_ unsafe element. This was an unneeded breaking change.

This commit partially restores the old sanitizer behavior (namely
traversing content of unsafe elements), but introduces a list of
elements whose content should not be traversed if the elements
themselves are considered unsafe. Currently, this list contains `style`,
`script` and `template`.

Related to #25879 and #26007.

Fixes #28427

PR Close #28804
2019-02-26 13:32:09 -08:00
Marc Laval dc9f0af080 fix(ivy): static host classes and styles should work on root component (#28926)
PR Close #28926
2019-02-26 13:29:36 -08:00
Kristiyan Kostadinov 25a2fef303 fix(ivy): ViewRef.rootNodes not including projected nodes (#28951)
Currently if an embedded view contains projected nodes, its `rootNodes` array will include `null` instead of the root nodes inside the projection slot. This manifested itself in one of the Material unit tests where we stamp out a template and then move its `rootNodes` into the overlay container.

This PR is related to FW-1087.

PR Close #28951
2019-02-26 10:49:01 -08:00
Misko Hevery 3cb497c6ac refactor(ivy): simplify differentiation of LView, `RNode`, `LView`, `LContainer`, `StylingContext` (#28947)
For efficiency reasons we often put several different data types (`RNode`, `LView`, `LContainer`,
`StylingContext`) in same location in `LView`. This is because we don't want to pre-allocate
space
for it because the storage is sparse. This file contains utilities for dealing with such data
types.
How do we know what is stored at a given location in `LView`.
- `Array.isArray(value) === false` => `RNode` (The normal storage value)
- `Array.isArray(value) === true` => than the `value[0]` represents the wrapped value.
  - `typeof value[TYPE] === 'object'` => `LView`
     - This happens when we have a component at a given location
  - `typeof value[TYPE] === 'number'` => `StylingContext`
     - This happens when we have style/class binding at a given location.
  - `typeof value[TYPE] === true` => `LContainer`
     - This happens when we have `LContainer` binding at a given location.
NOTE: it is assumed that `Array.isArray` and `typeof` operations are very efficient.

PR Close #28947
2019-02-26 02:01:07 +00:00
Misko Hevery bd65f58784 refactor(ivy): moved wrapped reference to 0 position in array (#28947)
`LView`, `LContainer`, `StylingContext` are all arrays which wrap either
an `HTMLElement`, `LView`, `LContainer`, `StylingContext`. It is often
necessary to retrieve the correct type of element from the location
which means that we often have to wrap the arrays. Logically it makes
more sense if the thing  which we are wrapping is at `0` location. Also
it may be more performant since data is more local which may result in
more L2 cache hits in CPU.
PR Close #28947
2019-02-26 02:01:07 +00:00
Misko Hevery 22880eae16 feat(ivy): add debug view of internal deta structures (#28945)
This change contains conditionally attached classes which provide human readable (debug) level
information for `LView`, `LContainer` and other internal data structures. These data structures
are stored internally as array which makes it very difficult during debugging to reason about the
current state of the system.

Patching the array with extra property does change the array's hidden class' but it does not
change the cost of access, therefore this patching should not have significant if any impact in
`ngDevMode` mode. (see: https://jsperf.com/array-vs-monkey-patch-array)

So instead of seeing:

```
Array(30) [Object, 659, null, …]
```

```
LViewDebug {
  views: [...],
  flags: {attached: true, ...}
  nodes: [
    {html: '<div id="123">', ..., nodes: [
      {html: '<span>', ..., nodes: null}
    ]}
  ]
}
```

PR Close #28945
2019-02-25 08:15:35 -08:00
Ben Lesh c64b13e593 refactor(ivy): split util functions into different files (#28382)
Google3 detected circular references here, so splitting up this rather hodge-podge list of functions into slightly better organizational units.

PR Close #28382
2019-02-22 13:17:30 -08:00
Ben Lesh 929fe029c2 refactor(ivy): LView is a proper linked list (#28382)
- TView no longer stores childIndex
- LView now as CHILD_HEAD and CHILD_TAIL

TView used to store the head of the list, therefor all LViews had to have the same head, which is incorrect.

PR Close #28382
2019-02-22 13:17:30 -08:00
Ben Lesh ba6aa93aa3 refactor(ivy): LContainer now stored in LView[PARENT] (#28382)
- Removes CONTAINER_INDEX
- LView[PARENT] now contains LContainer when necessary
- Removes now unused arguments to methods after refactor

PR Close #28382
2019-02-22 13:17:30 -08:00
Greg Magolan 75357ecb32 build(bazel): run a number of web tests with karma_web_test in saucelabs in CircleCI (#27721)
PR Close #27721
2019-02-22 13:07:08 -08:00
Greg Magolan fafabc0b92 build(bazel): use http_server rule from rules_nodejs (#28905)
PR Close #28905
2019-02-22 12:14:55 -08:00
Kristiyan Kostadinov 43181ea568 fix(ivy): host listeners being inherited twice (#28902)
Fixes inherited host event listeners being registered twice.

This PR resolves FW-1071.

PR Close #28902
2019-02-22 12:00:56 -08:00
Marc Laval 9dac04ff50 fix(ivy): ngOnChanges hooks should be inherited from grand-superclasses (#28888)
PR Close #28888
2019-02-22 12:00:15 -08:00
Kristiyan Kostadinov 32ae84da28 fixup! fix(ivy): incorrectly remapping certain properties that refer to inputs (#28765)
PR Close #28765
2019-02-21 17:59:50 -08:00
Kristiyan Kostadinov 93a7836f7a fix(ivy): incorrectly remapping certain properties that refer inputs (#28765)
During build time we remap particular property bindings, because their names don't match their attribute equivalents (e.g. the property for the `for` attribute is called `htmlFor`). This breaks down if the particular element has an input that has the same name, because the property gets mapped to something invalid.

The following changes address the issue by mapping the name during runtime, because that's when directives are resolved and we know all of the inputs that are associated with a particular element.

PR Close #28765
2019-02-21 17:59:50 -08:00
Kristiyan Kostadinov e1aaa7ec48 fix(ivy): component destroy hook called twice when configured as provider (#28470)
Fixes the `ngOnDestroy` hook on a component or directive being called twice, if the type is also registered as a provider.

This PR resolves FW-1010.

PR Close #28470
2019-02-21 09:34:26 -08:00
Greg Magolan ebffde7143 build: update to rules_typescript 0.25.1 (#28625)
Updated a spot in the compiler which assumed es5 downlevelling get ready for es2015 devmode in the future.

PR Close #28625
2019-02-21 07:46:21 -08:00
Matias Niemelä cfb2d176f8 feat(ivy): convert [ngStyle] and [ngClass] to use ivy styling bindings (#28711)
Prior to this fix, both the `NgStyle` and `NgClass` directives made use
of `Renderer2` and this dependency raised issues for future versions of
Angular that cannot inject it. This patch ensures that there are two
versions of both directives: one for the VE and another for Ivy.

Jira Issue: FW-882

PR Close #28711
2019-02-20 13:46:15 -08:00
Greg Magolan 67ad8a2632 build: move rxjs type reference to event emitter (#28720)
PR Close #28720
2019-02-19 16:28:14 -08:00
Greg Magolan 25aae64274 build(bazel): do not build rxjs from source under Bazel (#28720)
PR Close #28720
2019-02-19 16:28:14 -08:00
Olivier Combe ad6475ffac fix(ivy): re-create node links after creating/moving/removing nodes with i18n (#28827)
I18n can change the order of the nodes, or insert new dynamic nodes. When that happens it can break the existing links (`TNode.next`) or even create loops:
```
div1 → div2 → div3 → div4 → div5
```

Can become:
```
div1 → div4 → div2 → div3  div5
         🡑             │
         └─────────────┘
```

This PR fixes this issue by recreating the broken links between those nodes.
PR Close #28827
2019-02-19 15:54:33 -08:00
Kara Erickson 3c1a1620e3 fix(ivy): support static ContentChild queries (#28811)
This commit adds support for the `static: true` flag in `ContentChild`
queries. Prior to this commit, all `ContentChild` queries were resolved
after change detection ran. This is a problem for backwards
compatibility because View Engine also supported "static" queries which
would resolve before change detection.

Now if users add a `static: true` option, the query will be resolved in
creation mode (before change detection runs). For example:

```ts
@ContentChild(TemplateRef, {static: true}) template !: TemplateRef;
```

This feature will come in handy for components that need
to create components dynamically.

PR Close #28811
2019-02-19 15:29:01 -08:00
Kara Erickson a4638d5a81 fix(ivy): support static ViewChild queries (#28811)
This commit adds support for the `static: true` flag in
`ViewChild` queries. Prior to this commit, all `ViewChild`
queries were resolved after change detection ran. This is
a problem for backwards compatibility because View Engine
also supported "static" queries which would resolve before
change detection.

Now if users add a `static: true` option, the query will be
resolved in creation mode (before change detection runs).
For example:

```ts
@ViewChild(TemplateRef, {static: true}) template !: TemplateRef;
```

This feature will come in handy for components that need
to create components dynamically.

PR Close #28811
2019-02-19 15:29:00 -08:00
Kara Erickson 19afb791b4 feat(core): allow users to define timing of ViewChild/ContentChild queries (#28810)
Prior to this commit, the timing of `ViewChild`/`ContentChild` query
resolution depended on the results of each query. If any results
for a particular query were nested inside embedded views (e.g.
*ngIfs), that query would be resolved after change detection ran.
Otherwise, the query would be resolved as soon as nodes were created.

This inconsistency in resolution timing had the potential to cause
confusion because query results would sometimes be available in
ngOnInit, but sometimes wouldn't be available until ngAfterContentInit
or ngAfterViewInit. Code depending on a query result could suddenly
stop working as soon as an *ngIf or an *ngFor was added to the template.

With this commit, users can dictate when they want a particular
`ViewChild` or `ContentChild` query to be resolved with the `static`
flag. For example, one can mark a particular query as `static: false`
to ensure change detection always runs before its results are set:

```ts
@ContentChild('foo', {static: false}) foo !: ElementRef;
```

This means that even if there isn't a query result wrapped in an
*ngIf or an *ngFor now, adding one to the template later won't change
the timing of the query resolution and potentially break your component.

Similarly, if you know that your query needs to be resolved earlier
(e.g. you need results in an ngOnInit hook), you can mark it as
`static: true`.

```ts
@ViewChild(TemplateRef, {static: true}) foo !: TemplateRef;
```

Note: this means that your component will not support *ngIf results.

If you do not supply a `static` option when creating your `ViewChild` or
`ContentChild` query, the default query resolution timing will kick in.

Note: This new option only applies to `ViewChild` and `ContentChild`
queries, not `ViewChildren` or `ContentChildren` queries, as those types
already resolve after CD runs.

PR Close #28810
2019-02-19 12:56:25 -08:00
Pawel Kozlowski 692ddfcbb5 fix(ivy): allign DebugNode.componentInstance semantics with view engine (#28756)
PR Close #28756
2019-02-19 12:51:47 -08:00
Kara Erickson 911599d9a3 test(ivy): mark unknown binding test modifiedInIvy (#28740)
This commit turns off an unknown binding test that is specific
to the View Engine implementation. In Ivy, we do property validation
at runtime for jit, so this test does not apply.

PR Close #28740
2019-02-16 20:58:25 -08:00
Kristiyan Kostadinov 80a5934af6 fix(ivy): support schemas at runtime (#28637)
Accounts for schemas in when validating properties in Ivy.

This PR resolves FW-819.

A couple of notes:
* I had to rework the test slightly, in order to have it fail when we expect it to. The one in master is passing since Ivy's validation runs during the update phase, rather than creation.
* I had to deviate from the design in FW-819 and not add an `enableSchema` instruction, because the schema is part of the `NgModule` scope, however the scope is only assigned to a component once all of the module's declarations have been resolved and some of them can be async. Instead, I opted to have the `schemas` on the component definition.

PR Close #28637
2019-02-14 19:31:51 +00:00
Jeremy Elbourn 83fd66d1d0 fix(ivy): DebugNode should read styles from StylingContext (#28709)
Previously `DebugNode.classes` and `DebugNode.styles` mistakenly used an
object that is only *sometimes* a `StylingContext`. Also fixes a mistake
in `debug_node_spec.ts` where a test component was not declared in the
testing module.

There is still a bug here where `DebugNode` is not exposing *static*
values. This will need to be fixed in a follow up.

PR Close #28709
2019-02-14 19:24:17 +00:00