Commit Graph

408 Commits

Author SHA1 Message Date
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