Commit Graph

18 Commits

Author SHA1 Message Date
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 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
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
Matias Niemelä 627cecdfe2 fix(ivy): ensure host bindings and host styling works on a root component (#28664)
Prior to this fix if a root component was instantiated it create host
bindings, but never render them once update mode ran unless one or more
slot-allocated bindings were issued. Since styling in Ivy does not make
use of LView slots, the host bindings function never ran on the root
component.

This fix ensures that the `hostBindings` function does run for a root
component and also renders the schedlued styling instructions when
executed.

Jira Issue: FW-1062

PR Close #28664
2019-02-14 19:23:25 +00:00
Marc Laval 3842dd6a6d fix(ivy): OnChanges should support updating one Input among many (#28693)
PR Close #28693
2019-02-13 19:15:44 -08:00
Pawel Kozlowski 6d057cc05d fix(ivy): should mark OnPush ancestor of dynamically created views as dirty (#28687)
While marking a given views tree as dirty we should go all the way to the
root of the views tree and cross boundaries of dynamically inserted views.
In other words the markForCheck functionality should consider parents of
dynamically inserted views.

PR Close #28687
2019-02-13 12:12:45 -08:00
Andrew Kushnir 553f80ff46 fix(ivy): set proper implementation for module injector (#28667)
Prior to this change we used current injector implementation for module injector, which was causing problems and produces circular dependencies in case the same token is referenced (with @SkipSelf flag) in the `deps` array. The origin of the problem was that once `directiveInject` implementation becomes active, it was used for module injector as well, thus searching deps in Component/Directive DI scope. This fix sets `injectInjectorOnly` implementation for module injector to resolve the problem.

PR Close #28667
2019-02-13 12:05:13 -08:00
JoostK 2afc40608d fix(ivy): support injecting ChangeDetectorRef on templates (#27565)
Previously, using a pipe in an input binding on an ng-template would
evaluate the pipe in the context of node that was processed before the
template. This caused the retrieval of e.g. ChangeDetectorRef to be
incorrect, resulting in one of the following bugs depending on the
template's structure:

1. If the template was at the root of a view, the previously processed
node would be the component's host node outside of the current view.
Accessing that node in the context of the current view results in a crash.
2. For templates not at the root, the ChangeDetectorRef injected into the
pipe would correspond with the previously processed node. If that node
hosts a component, the ChangeDetectorRef would not correspond with the
view that the ng-template is part of.

The solution to the above problem is two-fold:

1. Template compilation is adjusted such that the template instruction
is emitted before any instructions produced by input bindings, such as
pipes. This ensures that pipes are evaluated in the context of the
template's container node.
2. A ChangeDetectorRef can be requested for container nodes.

Fixes #28587

PR Close #27565
2019-02-13 09:46:53 -08:00
Marc Laval 94b8aaeba8 fix(ivy): ngOnChanges should be inherited from super class (#28563)
PR Close #28563
2019-02-11 16:22:31 -08:00
Pawel Kozlowski e5861e1c79 fix(ivy): support checkNoChanges on embedded views (#28644)
Before this fix our ViewRef implementation assumed that checkNoChanges can be
only called on component views. In reality checkNoChanges can be also called on
embedded views (ex.: when an embedded view is attached to ApplicationRef).

PR Close #28644
2019-02-11 14:52:32 -08:00
Alexey Zuev 2bf0d1a56f fix(ivy): compile pipe in context of ternary operator (#28635)
Previously, it wasn't possible to compile template that contains pipe in context of ternary operator `{{ 1 ? 2 : 0 | myPipe }}` due to the error `Error: Illegal state: Pipes should have been converted into functions. Pipe: async`.

This PR fixes a typo in expression parser so that pipes are correctly converted into functions.

PR Close #28635
2019-02-11 14:52:13 -08:00
Andrew Kushnir a9afe629c7 feat(ivy): allow non-unique #localRefs to be defined in a template (#28627)
Prior to this change in Ivy we had strict check that disabled non-unique #localRefs usage within a given template. While this limitation was technically present in View Engine, in many cases View Engine neglected this restriction and as a result, some apps relied on a fact that multiple non-unique #localRefs can be defined and utilized to query elements via @ViewChild(ren) and @ContentChild(ren). In order to provide better compatibility with View Engine, this commit removes existing restriction.

As a part of this commit, are few tests were added to verify VE and Ivy compatibility in most common use-cases where multiple non-unique #localRefs were used.

PR Close #28627
2019-02-11 14:51:31 -08:00
Andrew Kushnir 7660d0d74a fix(ivy): extended next pointer lookup while traversing tNode tree (#28533)
Prior to this change we only checked whether current lView has a next pointer while traversing tNode tree. However in some cases this pointer can be undefined and we need to look up parents chain to find suitable next pointer. This commit adds the logic of searching for the next pointer taking parents chain into account.

PR Close #28533
2019-02-07 12:37:13 -08:00
Kara Erickson 8f15cdbc7c test(ivy): move some local ref tests to use TestBed infrastructure. (#28534)
When we first started writing tests for Ivy, we did not yet have a
compatible compiler. For this reason, we set up the Ivy runtime tests
to run with generated code that we wrote by hand (instead of real code
generated by the compiler).

Now that we have a working Ivy compiler and TestBed infrastructure
that is compatible with Ivy, we should start writing integration
tests that leverage them (no more handwritten generated code!). This
will prevent bugs where the compiler code and runtime code become
out of sync (which is easy if they are tested separately). And
eventually, we should migrate all the existing runtime tests in
"core/test/render3" to TestBed and ngtsc.

To kick off this effort, this commit migrates some existing tests
from "core/test/render3/exports_spec.ts" and saves them in a new file
with the same name in the "core/test/acceptance" folder.

PR Close #28534
2019-02-05 23:31:08 -05:00