Commit Graph

914 Commits

Author SHA1 Message Date
JoostK 06ec95f2ef fix(ivy): allow directive inheritance in strict mode (#28634)
For TypeScript compilation units that have the "strictFunctionTypes"
option enabled, an error would be produced for Ivy's definition fields
in declaration files in the case of inheritance across directives or
pipes.

This change loosens the definition types to allow for subtypes of the
defined type where necessary.

A test package that has the "strict" option enabled verifies that we
won't regress in environments where strict type checking is enabled.

Fixes #28079

PR Close #28634
2019-02-13 09:50:15 -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
Pete Bacon Darwin e6a00be014 test(core): update JIT source mapping tests for ivy (#28055)
There are some differences in how ivy maps template source
compared to View Engine.  In this commit we recreate the View Engine
tests for ivy.

PR Close #28055
2019-02-12 20:58:27 -08:00
Pete Bacon Darwin 8c3f1717a8 refactor(core): do not remove `templateUrl` when resolving (#28055)
When we resolve a component `templateUrl` we copy the contents of the
resolved template file into the `template` property.

Previously we would then remove the `templateUrl` to indicate that
the component has been resolved. But this meant that we no longer had
access to the URL of the original template file. This is essential for
diagnostics messages about the template compilation.

Now the existence of the `template` property overrides the existence of
`templateUrl`, which allows us to keep the `templateUrl` property.

PR Close #28055
2019-02-12 20:58:27 -08:00
Andrew Kushnir 0cb02d906e fix(ivy): mark query test as modified in Ivy (#28660)
Due to the fact that host nodes no longer match in ContentChild queries in Ivy, we disable test that was enabled previously in other commit.

PR Close #28660
2019-02-12 10:34: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
Matias Niemelä fe8301c462 feat(ivy): provide support for map-based host bindings for [style] and [class] (#28246)
Up until now, `[style]` and `[class]` bindings (the map-based ones) have only
worked as template bindings and have not been supported at all inside of host
bindings. This patch ensures that multiple host binding sources (components and
directives) all properly assign style values and merge them correctly in terms
of priority.

Jira: FW-882

PR Close #28246
2019-02-11 16:21:19 -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
Pawel Kozlowski e9bedc63bb fix(ivy): properly query root nodes of embedded views(shallow queries) (#28560)
PR Close #28560
2019-02-08 16:42:45 -08:00
Pawel Kozlowski 0e4705aec3 test(ivy): run view_injector_integration tests on node (#28593)
There is nothing browser specific in those tests and fakeAsync is supported on node.
Testing / debugging on node is often faster than on Karma.

PR Close #28593
2019-02-08 09:25:50 -08:00
Olivier Combe 9d109929be fix(ivy): remove nested placeholders with i18n (#28595)
PR Close #28595
2019-02-07 16:56:36 -08:00
Kara Erickson 1950e2d9ba fix(ivy): throw on bindings to unknown properties (#28537)
This commit adds a devMode-only check which will throw if a user
attempts to bind a property that does not match a directive
input or a known HTML property.

Example:
```
<div [unknownProp]="someValue"></div>
```

The above will throw because "unknownProp" is not a known
property of HTMLDivElement.

This check is similar to the check executed in View Engine during
template parsing, but occurs at runtime instead of compile-time.

Note: This change uncovered an existing bug with host binding
inheritance, so some Material tests had to be turned off. They
will be fixed in an upcoming PR.

PR Close #28537
2019-02-07 12:37:32 -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
Miško Hevery 62a13e795a refactor(ivy): pass host into createLView explicitly (#28461)
`LView` `HOST` was set in most cases right after creating `LView`.
This makes the API cleaner by explicitly passing it ont `createLView`.

PR Close #28461
2019-02-06 00:24:24 -05:00
Matias Niemelä 22d3226491 revert: fix(ivy): remove query results from destroyed embedded views (#28445)
This reverts commit 5ebc0da640.
2019-02-05 21:22:58 -08:00
Pawel Kozlowski 5ebc0da640 fix(ivy): remove query results from destroyed embedded views (#28445)
PR Close #28445
2019-02-05 23:48:39 -05: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
Olivier Combe baf103c98f fix(ivy): don't increment `expandoStartIndex` after directives are matched (#28424)
i18n instructions create text nodes dynamically and save them between bindings and the expando block in `LView`. e.g., they try to create the following order in `LView`.

```
| -- elements -- | -- bindings -- | -- dynamic i18n text -- | -- expando (dirs, injectors) -- |
```

Each time a new text node is created, it is pushed to the end of the array and the `expandoStartIndex` marker is incremented, so the section begins slightly later. This happens in `allocExpando`.

This is fine if no directives have been created yet. The end of the array will be in the "dynamic text node" section.

| -- elements -- | -- bindings -- | -- dynamic i18n text -- |

However, this approach doesn't work if dynamic text nodes are created after directives are matched (for example when the directive uses host bindings). In that case, there are already directives and injectors saved in the "expando" section. So pushing to the end of `LView` actually pushes after the expando section. What we get is this:

```
| -- elements -- | -- bindings -- | -- dynamic i18n text -- | -- expando -- | -- dynamic i18n text-- |
```

In this case, the `expandoStartIndex` shouldn't be incremented because we are not inserting anything before the expando section (it's now after the expando section). But because it is incremented in the code right now, it's now pointing to an index in the middle of the expando section.

This PR fixes that so that we only increment the `expandoStartIndex` if nothing was pushed into the expando section.

FW-978 #resolve

PR Close #28424
2019-02-05 23:30:37 -05:00
Pawel Kozlowski 7c5c1fae62 refactor(ivy): move around logic of getting render parent (#28455)
PR Close #28455
2019-02-05 23:29:24 -05:00
Jeremy Elbourn 89eac702b5 fix(ivy): remove DOM nodes from their real parent vs saved parent (#28455)
Currently, DOM node removal called `removeChild` on the saved parent
node when destroying a component. However, this will fail if the
component has been manually moved in the DOM. This change makes the
removal always use the node's real `parentNode` and ignore the provided
`parent`.

PR Close #28455
2019-02-05 23:29:24 -05:00
Andrew Kushnir 5a2c3ff8b5 fix(ivy): proper component resolution in case of inheritance (#28439)
Ivy allows Components to extend Directives (but not the other way around) and as a result we may have Component and Directive annotations present at the same time. The logic that resolves annotations to pick the necessary one didn't take this into account and as a result Components were recognized as Directives (and vice versa) in case of inheritance. This change updates the resolution logic by picking known annotation that is the nearest one (in inheritance tree) and compares it with expected type. That should help avoid mis-classification of Components/Directives during resolution.

PR Close #28439
2019-02-05 23:29:04 -05:00
Olivier Combe 728fe69625 feat(ivy): improve stacktrace for `R3Injector` errors (#28207)
Improve the stacktrace for `R3Injector` errors by adding the source component (or module) that tried to inject the missing provider, as well as the name of the injector which triggered the error (`R3Injector`).

e.g.:
```
R3InjectorError(SomeModule)[car -> SportsCar]:
    NullInjectorError: No provider for SportsCar!
```

FW-807 #resolve
FW-875 #resolve

PR Close #28207
2019-02-05 01:53:20 -05:00
Kara Erickson f2621dbb37 fix(core): remove createInjector() from public API (#28509)
createInjector() is an Ivy-only API that should not have
been exported as part of the public API. This commit removes
the export. It will be re-exported when Ivy is released.

PR Close #28509
2019-02-04 16:54:26 -05:00
Kristiyan Kostadinov fc88a79b32 fix(ivy): errors not being logged to ErrorHandler (#28447)
Fixes Ivy not passing thrown errors along to the `ErrorHandler`.

**Note:** the failing test had to be reworked a little bit, because it has some assertions that depend on an error context being logged, however Ivy doesn't keep track of the error context.

This PR resolves FW-840.

PR Close #28447
2019-02-04 16:48:14 -05:00
Matias Niemelä 52d3795336 revert: fix(ivy): remove query results from destroyed embedded views (#28445)
This reverts commit 71b9d5539b.
2019-02-04 12:52:37 -05:00
Pawel Kozlowski 71b9d5539b fix(ivy): remove query results from destroyed embedded views (#28445)
PR Close #28445
2019-02-04 10:51:15 -05:00
Kara Erickson 5c4d95541e fix(ivy): mark views dirty by default when events fire (#28474)
In Ivy, we support a new manual mode that allows for stricter control
over change detection in OnPush components. Specifically, in this mode,
events do not automatically mark OnPush views as dirty. Only changed
inputs and manual calls to `markDirty()` actually mark a view dirty.

However, this mode cannot be the default for OnPush components if we
want to be backwards compatible with View Engine. This commit re-adds
the legacy logic for OnPush components where events always mark views
dirty and makes it the default behavior.

Note: It is still TODO to add a public API for manual change detection.

PR Close #28474
2019-02-01 15:48:06 -05:00
Andrew Kushnir 8930f60a4b refactor(ivy): create an Ivy version of tree-shakable providers test (#28477)
Due to the fact that the test in 'ng_module_integration_spec.ts' relied on internal VE data structures (the '_def' field) to verify the state and the structure has changed in Ivy, this commit adds an Ivy version of the same test.

PR Close #28477
2019-02-01 14:00:41 -05:00
Pawel Kozlowski 1b6d8a78b0 fix(ivy): queries should match container node itself before matching its views (#28473)
PR Close #28473
2019-01-31 17:14:05 -05:00
Marc Laval 9efb39c8a2 test(ivy): ComponentFactoryResolver can resolve any component factory in Ivy (#28465)
PR Close #28465
2019-01-31 15:55:31 -05:00
Jeremy Elbourn 35e45dc894 fix(ivy): prevent errors from views being destroyed twice (#28413)
Previously, attempting to destroy a view with listeners more than once
throws an error during event listener cleanup. This happens because
`cleanup` field on the `TView` has already been cleared out by the time
the second destruction runs.

The `destroyed` flag on LView was previously being set in the `destroyLView` function,
but this flag was never _checked_ anywhere in the codebase. This commit
moves _setting_ this flag to the `cleanupView` function, just before
destroy hooks are called. This is necessary because the destroy hooks
can contain arbitrary user code, such as (surprise!) attempting to
destroy the view (again). We also add a check to `destroyLView` to skip
already-destroyed views. This prevents the cleanup code path from running twice.

PR Close #28413
2019-01-30 20:39:55 -05:00
Pawel Kozlowski b35ef184a7 refactor(ivy): remove firstTemplatePass as global state (#28450)
PR Close #28450
2019-01-30 20:39:35 -05:00
Pawel Kozlowski 51a592cdfc fix(ivy): mark query as dirty upon view insertion (#28429)
PR Close #28429
2019-01-29 16:40:47 -08:00
Kara Erickson fdc6e159b4 fix(ivy): throw if @Input and @ContentChild share a property (#28415)
In View Engine, we supported @Input and @ContentChild annotations
on the same property. This feature was somewhat brittle because
it would only work for static queries, so it would break if a
content child was passed in wrapped in an *ngIf. Due to the
inconsistent behavior and low usage both internally and externally,
we will likely be deprecating it in the next version, and it does
not make sense to perpetuate it in Ivy.

This commit ensures that we now throw in Ivy if we encounter the
two annotations on the same property.

PR Close #28415
2019-01-29 16:40:22 -08:00
Andrew Kushnir 495a9dd445 fix(ivy): update token used for fakeAsync test (#28383)
This commit updates the token used in fakeAsync test to the one available in both VE and R3 TestBeds. The goal of the test is to verify that fakeAsync works with inject function, so the actual token that is used for a test is irrelevant in that case. The logic to retrieve tokens from compiler injector (that the comment in "fixmeIvy" refers to) was implemented in PR #28196.

PR Close #28383
2019-01-29 16:39:14 -08:00
Andrew Kushnir 76cedb8bf3 fix(ivy): verify Host Bindings and Host Listeners before compiling them (#28356)
Prior to this change we may encounter some errors (like pipes being used where they should not be used) while compiling Host Bindings and Listeners. With this update we move validation logic to the analyze phase and throw an error if something is wrong. This also aligns error messages between Ivy and VE.

PR Close #28356
2019-01-29 16:36:22 -08:00
onlyflix 41e68f7a7a style: change to American English (#27266)
PR Close #27266
2019-01-29 16:30:25 -08:00
Jeremy Elbourn 2bb518c694 fix(ivy): add root components to the root view tree in renderComponent (#28409)
Previously, these components were not added to the view tree for the
(fake) root view in which they were bootstrapped. Without this,
root view destruction does not work as expected since the root view's
children are not present to be also destroyed.

PR Close #28409
2019-01-29 11:49:29 -08:00
Andrew Kushnir f38deb0f07 fix(ivy): update test after Content Queries inheritance fix (#28414)
This commit updates test that was added after Content Queries inheritance fix (that renames some instructions) was merged into master. The test used previous version of instructions, thus causing failures after merging Content Queries inheritance fix.

PR Close #28414
2019-01-28 22:07:32 -08:00
Andrew Kushnir bb94434d85 fix(ivy): Content Queries inheritance fix (#28324)
Prior to this change contentQueriesRefresh functions that represent refresh logic for @ContentQuery list were not composable, which caused problems in case one Directive inherits another one and both of them contain Content Queries. Due to the fact that we used indices to reference queries in refresh function, results were placed into wrong Queries. In order to avoid that we no longer use indices to reference queries and instead maintain current content query index while iterating through them. This allows us to compose contentQueriesRefresh functions and make inheritance feature work with Content Queries.

PR Close #28324
2019-01-28 19:59:00 -08:00
Alex Rickabaugh 7d954dffd0 feat(ivy): detect cycles and use remote scoping of components if needed (#28169)
By its nature, Ivy alters the import graph of a TS program, adding imports
where template dependencies exist. For example, if ComponentA uses PipeB
in its template, Ivy will insert an import of PipeB into the file in which
ComponentA is declared.

Any insertion of an import into a program has the potential to introduce a
cycle into the import graph. If for some reason the file in which PipeB is
declared imports the file in which ComponentA is declared (maybe it makes
use of a service or utility function that happens to be in the same file as
ComponentA) then this could create an import cycle. This turns out to
happen quite regularly in larger Angular codebases.

TypeScript and the Ivy runtime have no issues with such cycles. However,
other tools are not so accepting. In particular the Closure Compiler is
very anti-cycle.

To mitigate this problem, it's necessary to detect when the insertion of
an import would create a cycle. ngtsc can then use a different strategy,
known as "remote scoping", instead of directly writing a reference from
one component to another. Under remote scoping, a function
'setComponentScope' is called after the declaration of the component's
module, which does not require the addition of new imports.

FW-647 #resolve

PR Close #28169
2019-01-28 12:10:25 -08:00
Jeremy Elbourn 3deda898d0 fix(ivy): TestBed should tolerate synchronous use of `compileComponents` (#28350)
TestBed.compileComponents has always been an async API. However,
ViewEngine tolerated using this API in a synchronous manner if the
components declared in the testing module did not have any async
resources (templateUrl, styleUrls). This change makes the ivy TestBed
mirror this tolerance by configuring such components synchronously.

Ref: FW-992

PR Close #28350
2019-01-28 11:59:40 -08:00
Marc Laval d83307adab fix(ivy): init hooks should be called once and only once (#28239)
PR Close #28239
2019-01-25 14:31:23 -08:00
Marc Laval 873750609f fix(ivy): calling ChangeDetectorRef.detectChanges() from onChanges should not go infinite loop (#28239)
PR Close #28239
2019-01-25 14:31:23 -08:00
Pawel Kozlowski 99886bd159 fix(ivy): unify checkNoChanges logic with the view engine (#28366)
This commit unifies handling of the "check no changes" mode between
ngIvy and the view engine. More specifically:
- check no changes can be invoked before change detection in ivy;
- `undefined` values are considered equal `NO_CHANGES` for the "check no changes"
mode purposes.

Chanes in this commit enables several tests that were previously running only in ivy
or only in the view engine.

PR Close #28366
2019-01-25 14:22:57 -08:00
Miško Hevery 3d5a919ac5 refactor(ivy): clean up TNode not depending on LView (#28354)
PR Close #28354
2019-01-25 13:07:26 -08:00
Andrew Kushnir 2da82db3bc fix(ivy): proper i18n postprocessing in case of nested templates (#28209)
Prior to this change the postprocess step relied on the order of placeholders combined in one group (e.g. [�#1�|�*1:1�]). The order is not guaranteed in case we have nested templates (since we use BFS to process templates) and some tags are represented using same placeholders. This change performs postprocessing more accurate by keeping track of currently active template and searching for matching placeholder.

PR Close #28209
2019-01-25 12:54:29 -08:00
Matias Niemelä 7421534873 test(ivy): move error-handling test to be handled at a later stage (#28212)
Due to the fast moving nature of the Ivy codebase, the timing isn't
right to make changes to how errors and reported and handled during the
runtime.

Once ivy is stable this test should be revisted because that stage there
will be a better and more robust understanding of how ivy should recover
from runtime errors.

Jira Issue: FW-952

PR Close #28212
2019-01-25 12:54:04 -08:00