BREAKING CHANGE:
Certain elements (like `<tr>` or `<col>`) require parent elements to be of a certain type by the HTML specification
(ex. <tr> can only be inside <tbody> / <thead>). Before this change Angular template parser was auto-correcting
"invalid" HTML using the following rules:
- `<tr>` would be wrapped in `<tbody>` if not inside `<tbody>`, `<tfoot>` or `<thead>`;
- `<col>` would be wrapped in `<colgroup>` if not inside `<colgroup>`.
This meachanism of automatic wrapping / auto-correcting was problematic for several reasons:
- it is non-obvious and arbitrary (ex. there are more HTML elements that has rules for parent type);
- it is incorrect for cases where `<tr>` / `<col>` are at the root of a component's content, ex.:
```html
<projecting-tr-inside-tbody>
<tr>...</tr>
</projecting-tr-inside-tbody>
```
In the above example the `<projecting-tr-inside-tbody>` component culd be "surprised" to see additional
`<tbody>` elements inserted by Angular HTML parser.
PR Close#29219
Previously, ngtsc would resolve forward references while evaluating the
bootstrap, declaration, imports, and exports fields of NgModule types.
However, when generating the resulting ngModuleDef, the forward nature of
these references was not taken into consideration, and so the generated JS
code would incorrectly reference types not yet declared.
This commit fixes this issue by introducing function closures in the
NgModuleDef type, similarly to how NgComponentDef uses them for forward
declarations of its directives and pipes arrays. ngtsc will then generate
closures when required, and the runtime will unwrap them if present.
PR Close#29198
Prior to this change default selector for Components was not applied in case selector is missing or defined as an empty string. This update aligns this behavior between Ivy and VE: now default selector is used for Components when it's needed. Directives with empty selector are not allowed and trigger a compile-time error in both Ivy and VE.
PR Close#29239
With 6215799, we introduced a schematic for the new static-query timing.
Currently when someone runs the update schematic manually within his
CLI project (the schematic does not run automatically yet), he might have
noticed that the migration is executed for the same `tsconfig` file multiple
times. This can happen because the `getProjectTsConfigPaths` function
can incorrectly return the same tsconfig multiple times. The paths are not
properly deduped as we don't normalize the determined project tsconfig paths
PR Close#29133
Currently the static-query migration does not properly handle functions which
are declared externally. This is because we don't resolve the symbol of the
call-expression through its type. Currently we just determine the symbol of the
call-expression through the given call expression node, which doesn't necessarily
refer to the *value declaration* of the call expression. e.g. the symbol refers to the
import declaration which imports the external function. This means that we currently
can't check the external function as we couldn't find the actual value declaration.
We can fix this by resolving the type of the call expression and using the type in order
to retrieve the symbol containing the *value declaration*
PR Close#29133
Currently when the static-query runs for a project with multiple TypeScript
configuration files (e.g. a usual CLI project), the migration incorrectly
applies the code transformation multiple times. This is because the migration
is currently based on the source file contents in the file system, while the
actual source file contents could have already changed in the devkit schematic
tree.
PR Close#29133
With 6215799055, we introduced a schematic
for the Angular core package that automatically migrates unexplicit
query definitions to the explicit query timing (static <-> dynamic).
As the initial foundation was already big enough, it was planned
to come up with a follow-up that handles asynchronous query
usages properly. e.g. queries could be used in Promises,
`setTimeout`, `setInterval`, `requestAnimationFrame` and more, but
the schematic would incorrectly declare these queries as static.
This commit ensures that we properly handle these micro/macro
tasks and don't incorrectly consider queries as static.
The declaration usage visitor should only check the synchronous
control flow and completely ignore any statements within function
like expressions which aren't explicitly executed in a synchronous
way. e.g. IIFE's still work as the function expression is
synchronously invoked.
PR Close#29133
Currently with ViewEngine, if someone runs the platform's
`bootstrapModule` method in order to boostrap a module in
JIT mode, external component resources are properly resolved
*automatically*.
Currently with Ivy, the developer would need to manually call
`resolveComponentResources` in order to asynchronously fetch
the determined external component resources. In order to make
this backwards compatible with ViewEngine, and also since
platforms can already specify a `ResourceLoader` compiler
provider, we need to automatically resolve all external
component resources on module bootstrap.
--
Since the `ResourceLoader` is part of the `@angular/compiler`,
because ViewEngine performed the factory creation in the compiler,
we can't access the `ResourceLoader` token from within core.
In order to workaround this without introducing a breaking change,
we just proxy the `ResourceLoader` token to `core` through the
compiler facade. In the future, we should be able to move the
`ResourceLoader` to core when ViewEngine code no longer exists in
the `@angular/compiler`.
PR Close#29083
Dynamic nodes are created at the end of the view stack, but we were removing all the placeholders between `i18nStart` and the last created node index, instead of removing everything between `i18nStart` and `i18nEnd`. This caused errors when dynamic nodes where created in multiple i18n blocks because we would remove all of the dynamic nodes created in the previous i18n blocks.
PR Close#29252
`ng_module` will now include an `src/r3_symbol.d.ts` when compiling the core package under `ngc` togather with `dts bundling`, This is due that `ngcc` relies on this file to be present, but the `r3_symbols` file which is not part of our public api.
With this change, we can now ship an addition dts file which is flattened.
PR Close#28884
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
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
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
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
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
Introduces an update schematic for the "@angular/core" package
that automatically migrates pre-V8 "ViewChild" and "ContentChild"
queries to the new explicit timing syntax. This is not required
yet, but with Ivy, queries will be "dynamic" by default. Therefore
specifying an explicit query timing ensures that developers can
smoothly migrate to Ivy (once it's the default).
Read more about the explicit timing API here:
https://github.com/angular/angular/pull/28810
PR Close#28983
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
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
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
This change helps highlight certain misoptimizations with Closure
compiler. It is also stylistically preferable to consistently use index
access on index sig types.
Roughly, when one sees '.foo' they know it is always checked for typos
in the prop name by the type system (unless 'any'), while "['foo']" is
always not.
Once all angular repos are conforming this will become a tsetse.info
check, enforced by bazel.
PR Close#28937
This commit removes code duplication around projectables nodes insertion.
It also simplfy the overall logic by using recursive function calls instead
of hand-unrolled stack (we can always optimise this part if needed).
PR Close#29008
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#24923Closes#25635
Jira Issue: FW-1091
Jira Issue: FW-1092
PR Close#28911
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
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
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
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
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
`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
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
If an interface is not exported publicly from its package, then the doc-gen
does not see it, and so cannot include it in the generated documentation.
This was the case for a number of `...Decorator` interfaces, such as
`PipeDecorator` and `InputDecorator.
This commit adds these interfaces to the public export to fix this problem.
PR Close#28836
Google3 detected circular references here, so splitting up this rather hodge-podge list of functions into slightly better organizational units.
PR Close#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
- Removes CONTAINER_INDEX
- LView[PARENT] now contains LContainer when necessary
- Removes now unused arguments to methods after refactor
PR Close#28382
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
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
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
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
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
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
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
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
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
Since we build and publish the individual packages
using Bazel and `build.sh` has been removed, we can
safely remove the `rollup.config.js` files which are no
longer needed because the `ng_package` bazel rule
automatically handles the rollup settings and globals.
PR Close#28646
Currently errors thrown inside event handler in Ivy are caught and forwarded to the `ErrorHandler`, however this means that if they happen during a unit test, the test won't fail. These changes add a test-specific `ErrorHandler` that throws the error rather than logging it out.
PR Close#28707
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
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
In the past, @Injectable had no side effects and existing Angular code is
therefore littered with @Injectable usage on classes which are not intended
to be injected.
A common example is:
@Injectable()
class Foo {
constructor(private notInjectable: string) {}
}
and somewhere else:
providers: [{provide: Foo, useFactory: ...})
Here, there is no need for Foo to be injectable - indeed, it's impossible
for the DI system to create an instance of it, as it has a non-injectable
constructor. The provider configures a factory for the DI system to be
able to create instances of Foo.
Adding @Injectable in Ivy signifies that the class's own constructor, and
not a provider, determines how the class will be created.
This commit adds logic to compile classes which are marked with @Injectable
but are otherwise not injectable, and create an ngInjectableDef field with
a factory function that throws an error. This way, existing code in the wild
continues to compile, but if someone attempts to use the injectable it will
fail with a useful error message.
In the case where strictInjectionParameters is set to true, a compile-time
error is thrown instead of the runtime error, as ngtsc has enough
information to determine when injection couldn't possibly be valid.
PR Close#28523
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
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
Prior to this update we had separate contentQueries and contentQueriesRefresh functions to handle creation and update phases. This approach was inconsistent with View Queries, Host Bindings and Template functions that we generate for Component/Directive defs. Now the mentioned 2 functions are combines into one (contentQueries), creation and update logic is separated with RenderFlags (similar to what we have in other generated functions).
PR Close#28503
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
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
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
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
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
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
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
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
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
We need to support rendering in contexts like web workers where
nodes are emulated and properties may not be set directly. This
commit gates property validation checks to environments that have
real Node objects.
FW-1043 #resolve
PR Close#28610
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
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
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
`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
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
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
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
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
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
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
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
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
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
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
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
Prior to this change we didn't verify types passed to bootstrap as a part of NgModule semantics verification. Now we check whether all types passed to bootstrap are actually Components.
PR Close#28386
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
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
Adds the information that the templateUrl and styleUrls options supports only relative Urls.
Adds more information about relative paths and absolute URLs in project metadata.
PR Close#27962
When testing whether `value` is an object, use the ideal sequence of
strictly not equal to `null` followed by `typeof value === 'object'`
consistently. Specifically there's no point in using double equal with
`null` since `undefined` is ruled out by the `typeof` check.
Also avoid the unnecessary ToBoolean check on `value.ngOnDestroy` in
`hasOnDestroy()`, since the `typeof value.ngOnDestroy === 'function'`
will only let closures pass and all closures are truish (with the
notable exception of `document.all`, but that shouldn't be relevant
for the `ngOnDestroy` hook).
PR Close#28400
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
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
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
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
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
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
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
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
DebugElement.properties should contain a map of element
property names to element property values, with entries
for both normal property bindings and host bindings.
This commit adds support for property bindings in
DebugElement.properties (including interpolations).
PR Close#28355
DebugElement.properties should contain a map of element
property names to element property values, with entries
for both normal property bindings and host bindings.
Many Angular core tests depend on this map being present.
This commit adds support for host property bindings in
DebugElement.properties, which fixes the Angular core tests.
There is still work to be done for normal property bindings.
PR Close#28355
Previous to this change, we were storing view queries at the
wrong index. This is because we were passing a raw index to the
store() instruction instead of an adjusted index (i.e. an
index that does not include the HEADER_OFFSET). We had an
additional issue where TView.blueprint was not backfilled
when TView.data was backfilled, so new component instances
created from the blueprint would end up having a shorter LView.
Both of these problems together led to the Material demo app
failing with Ivy. This commit fixes those discrepancies.
PR Close#28327
Previously, bootstrapping a component with render3 would create a chained injector with the test bed ngModule instead of the ngModule that the component belongs to.
Now when a component belongs to an ngModule, we use that for the chained injector, ensuring the correct injection of any providers that this ngModule contains.
FW-776 #resolve
PR Close#28183
Fixes components with native content projection (using `<content>` or `<slot>`) not working under Ivy.
The issue comes from the fact that when creating elements inside a component, we sometimes don't append the element immediately, but we leave it to projection to move it into its final destination. This ends up breaking the native projection, because the slots have to be in place from the beginning. The following changes switch to appending the element immediately when inside a component with Shadow DOM encapsulation.
This PR resolves FW-841.
PR Close#28261
There are cases where we should check an element injector but don't go
into the associated module injector if a token is not found. In both the
view engine and ngIvy this is acheived by passing the
`NOT_FOUND_CHECK_ONLY_ELEMENT_INJECTOR` as the `notFoundValue`.
Before this fix the view engine and ngIvy were using different objects to
represent `NOT_FOUND_CHECK_ONLY_ELEMENT_INJECTOR`. This was causing problems
as ngUpgrade is using `NOT_FOUND_CHECK_ONLY_ELEMENT_INJECTOR` const in its
`NgAdapterInjector` to prevent searching of module injectors.
This commit makes sure that ngIvy is using the same object to represent
`NOT_FOUND_CHECK_ONLY_ELEMENT_INJECTOR` as the view engine.
PR Close#28313
Prior to this change `viewQuery` functions that represent @ViewQuery list were not composable, which caused problems in case one Component/Directive inherits another one and both of them contain View Queries. Due to the fact that we used indices to reference queries, resulting query set was corrupted (child component queries were overridden by super class ones). In order to avoid that we no longer use indices assigned at compile time and instead maintain current view query index while iterating through them. This allows us to compose `viewQuery` functions and make inheritance feature work with View Queries.
PR Close#28309
- Wraps the NgOnChangesFeature in a factory such that no side effects occur in the module root
- Adds comments to ngInherit property on feature definition interface to help guide others not to make the same mistake
- Updates compiler to generate the feature properly after the change to it being a factory
- Updates appropriate tests
PR Close#28187
This changes restores parity between VE TestBed and R3TestBed logic related to retrieving tokens using TestBed.get function. Now R3TestBed also tries to retrieve tokens from Compiler Injector.
PR Close#28196
Before this commit we were creating a "fake" TNode for each and every
projectable node passed during dynamic component creation. This approach
had several problems:
- the existing TView structure had to be mutated to accomodate new TNodes and
it was very easy to "corrupt" TView / TNode data structures;
- TNodes are not really needed to fully support projectable nodes so we were
creating objects and updating existing data structures for nothing.
This commit changes the approach so we don't create "fake" TNodes for projectable
nodes but instead we process projectable nodes directly in the projection instruction.
As a result we've got less code, less object allocation and - as a bonus - we fix few
bugs where TView / TNode data structures were corrupted when using projectable nodes.
PR Close#28275
Fixes Ivy not applying properties that are set in camelCase, because it goes through the `CSSStyleDeclaration` API via `setProperty` and `removeProperty` which requires for [the values to be in dash-case](https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleDeclaration/setProperty).
**Note:** I opted to let the browser normalize the value, rather than convert it to dash-case during compile time, because there are some special cases like browser-prefixed properties where we might not normalize it in-line with the browser.
This PR fixes FW-579.
PR Close#28276
Previous to this change, the isStylingContext() function was improperly
returning true for LContainers because it used the presence of an array
at index 2 to determine whether it was a styling context. Unfortunately,
LContainers also contain arrays at index 2, so this would return a false
positive. This led to other errors down the line because we would treat
nodes with containers as if they already had styling contexts (even if
they did not), so the proper initialization logic for styling contexts
was not run.
This commit fixes the isStylingContext() function to use LCONTAINER_LENGTH
as a marker rather than the presence of an array, which in turn fixes
host bindings to styles on nodes with containers.
PR Close#28221
Destroys the module's injector when an `NgModule` is destroyed which in turn calls the `ngOnDestroy` methods on the instantiated providers.
This PR resolves FW-739.
PR Close#27793
Due to the fact that animations in Angular are defined in the component metadata,
all animation trigger definitions are localized to the component and are
inaccessible outside of it. Animation host listeners in Ivy are
rendered in the context of the parent component, but the VE renders them
differently. This patch ensures that animation host listeners are
always registered in the sub component's renderer
Jira issue: FW-943
Jira issue: FW-958
PR Close#28210
Prior to this fix Ivy would not execute any animation triggers
that exist as host bindings on an element if it is removed by
the parent template.
PR Close#28162
In Ivy when elements are created a series of static attribute names are provided
over to the construction instruction of that element. Static attribute names
include non-binding attribues (like `<div selected>`) as well as animation bindings
that do not have a RHS value (like `<div @foo>`). Because of this distinction,
value-less animation triggers are rendered first before value-full animation
bindings are and this improper ordering has caused various existing tests to fail.
This patch ensures that animation bindings are evaluated in the order that they
exist within the HTML template code (or host binding code).
PR Close#28165
With the refactoring or how styles/classes are implmented in Ivy,
interpolation has caused the binding code to mess up since interpolation
itself takes up its own slot in Ivy's memory management code. This patch
makes sure that interpolation works as expected with class and style
bindings.
Jira issue: FW-944
PR Close#28190
In VE the renderer.begin() and renderer.end() methods are only called
when CD is called on an element. This patch ensures that Ivy does the
same thing.
Jira issue: FW-945
PR Close#28192
When we look for matching annotations in TestBed, we should always take the last
matching annotation. Otherwise, we will return superclass data for subclasses,
which would have unintended consequences like directives matching the wrong selectors.
PR Close#28195
Initial thinking was that the bug is in the content projection logic but
it turned out to be a wrong assumption - hence adding a test to illustrate
that basic content projection of view containers works correctly.
What fails in the marked test is the logic quering debug nodes - content
peojection is fine but we never create the 'B' text node since we call
show() method on the "wrong" directive instance.
PR Close#28152
Fixes the `ModuleWithComponentFactories.componentFactories` not being populated when calling `compileModuleAndAllComponentsSync` in Ivy.
These changes resolve FW-929.
PR Close#28112
Prior to this change element's i18n attributes like "i18n-title" were processed after "i18n" ones that placed "i18n" and "i18nAttributes" instructions in wrong order, thus "i18nAttributes" failed to target its host element at runtime. This change updates processing order and puts "i18nAttributes" instructions in front of "i18n" ones to resolve the problem.
PR Close#28163
There were two issues with multiple ICU expressions in the same i18n block:
- the regexp that was used to parse the text wasn't able to handle multiple ICU expressions, I've replaced it with parsing the text and searching for brackets (which is what we ended up doing in the end anyway)
- we allocate node indexes for nodes generated by the ICU expressions which increases the expando value, but we would create the nodes for those cases during the update phase. In the mean time we would create some nodes during the creation phase (comment nodes for ICU expressions, text nodes, ...) with an auto increment index. This means that any node created after an ICU expression would get the following index value, but the ICU case nodes expected to use the same index as well... There was a mismatch between the auto generated index, and the expected index which was causing problems when we needed to select those nodes for updates later on. To fix it, I've added the expected node index to the list of mutate codes that we generate, and we do not use an auto increment value anymore.
FW-905 #resolve
PR Close#28083
The implementation of the `compileComponents` method for `TestBedRender3` was missing.
We now pass each component through `resolveComponentResources` when `TestBed.compileComponents` is called so that `templateUrl` and `styleUrls` can be resolved asynchronously and used once `TestBed.createComponent` is called.
The component's metadata are overriden in `TestBed` instead of mutating the original metadata like this is the case outside of TestBed. The reason for that is that we need to ensure that we didn't mutate anything so that the following tests can run with the same original metadata, otherwise we it could trigger or hide some errors.
FW-553 #resolve
PR Close#27778
Throws a similar error to ViewEngine when encountering an `@Output` that hasn't been initialized to an `Observable`.
These changes resolve FW-680.
PR Close#28085
Up until this point, all static attribute values (things like `title` and `id`)
defined within the `host` are of a Component/Directive definition were
generated into a `def.attributes` array and then processed at runtime.
This design decision does not lend itself well to tree-shaking and is
inconsistent with other static values such as styles and classes.
This fix ensures that all static attribute values (attributes, classes,
and styles) that exist within a host definition for components and
directives are all assigned via the `elementHostAttrs` instruction.
```
// before
defineDirective({
...
attributes: ['title', 'my title']
...
})
//now
defineDirective({
...
hostBindings: function() {
if (create) {
elementHostAttrs(..., ['title', 'my-title']);
}
...
}
...
})
```
PR Close#28089
Angular allows for `<ng-content>` elements to include a selector which
filters which content-projected entries are inserted into the container
depending on whether or not the selector is matched.
With Ivy this feature has not fully worked due to the massive changes
that took place inside of Ivy's styling algorithm code (which is
responsible for assigning classes and styles to an element). This
fix ensures that content-projection can correctly identify which slot
an element should be placed into when class-based selectors are used.
PR Close#27849
Fixes the `DebugNode.references` returning a reference to the underlying comment node, rather than the `TemplateRef` that the reference is pointing to. The issue comes from the fact that `discoverLocalRefs` falls back directly to returning the native node, if the ref isn't pointing to a directive, rather than looking through the locals.
These changes resolve FW-870.
PR Close#28101
When requesting a queries instance for a node, it was previously
decided whether it needs to be cloned if the node was not already marked
as hosting a query. This check is in place to have only a single queries
instance per node.
The issue with this approach is that no clone is created for subsequent
instantiations of a component, as the TNode is already marked as hosting
a query during first template pass, whereas the cloning of queries
should be independent of first template pass.
To overcome this issue, the queries are assigned an owner TNode such
that it can reliably be determined if a clone needs to be created.
PR Close#27892
This update fixes the way the @internal and @nocollapse annotations are used together, which produced errors while running it with Closure compiler. Now two annotations are a part of the same comment block.
PR Close#28138
Prior to this change we performed prop and attr name validation at compile time, which failed in case a given prop/attr is an input to a Directive (thus should not be a subject to this check). Since Directive matching in Ivy happens at runtime, the corresponding checks are now moved to runtime as well.
PR Close#28054
This change is a prerequasity for a later change which will turn the
'di' into its own bazel package. In order to do that we have to:
- have `Injector` type be importable by Ivy. This means that we need
to create `Injector` as a pure type in `interface` folder which is
already a bazel package which Ivy can depend on.
- Remove the dependency of `class Injector` on Ivy so that it can be
compiled in isolation. We do that by using `-1` as special value for
`__NG_ELEMENT_ID__` which tells the Ivy `NodeInjector` than
`Injector` is being requested.
PR Close#28066
This update aligns Ivy behavior with ViewEngine related to empty bindings (for example <div [someProp]></div>): empty bindings are ignored.
PR Close#28059
__NG_ELEMENT_ID__ static fields are a part of how the Ivy node injector
works. In order to survive closure minification correctly, they need to
be annotated with @nocollapse.
PR Close#28050
When an @NgModule decorator executes, the module is added to a queue in
render3/jit/module.ts. Reading an ngComponentDef property causes this queue
to be flushed, ensuring that the component gets the correct module scope
applied.
In before_each.ts, a global beforeEach is added to all Angular tests which
calls TestBed.resetTestingModule() prior to running each test. This in turn
clears the module compilation queue (which is correct behavior, as modules
declared within the test should not leak outside of it via the queue).
So far this is okay. But before the first test runs, the module compilation
queue is full of modules declared in global scope. No definitions have been
read, so no flushes of the queue have been triggered. The global beforeEach
triggers a reset of the queue, aborting all of the in-progress global
compilation, breaking those classes when they're later used in tests.
This commit adds logic to TestBedRender3 to respect the state of the module
queue before the TestBed is first initialized or reset. The queue is flushed
prior to such an operation to ensure global compilation is allowed to finish
properly.
With this fix, a platform-server test now passes (previously the <my-child>
element was not detected as a component, because the encompassing module
never finished compilation.
FW-887 #resolve
PR Close#28033
Previously when testing code injected the Compiler, it received the
top-level Compiler implementation defined in linker/compiler.ts
(and governed by the __PRE_R3__ switch). Code running under the
TestBed, however, should always use a TestBed-aware Compiler
implementation.
This commit adds such an implementation to the TestBedRender3,
which passes compiled modules through the _compileNgModule()
function.
With this change, 3 formerly disabled router integration tests
now pass.
FW-855 #resolve
PR Close#28033
An @NgModule with invalid provider declarations produces errors under
normal circumstances. However, within the TestBed two small issues with
provider overrides interfered with the correct production of these errors:
1. a 'null' provider object caused a premature crash when the TestBed
attempted to check for a 'provide' property on it with hasOwnProperty().
2. the array of providers would have an empty override array appended to it
for each input provider, which would pollute the error messages produced
down the line.
This commit fixes both of these issues, by 1) checking for null and 2)
filtering out the empty override arrays.
Testing strategy: future commits change the way the TestBed compiles
modules, causing tests to become sensitive to this bug if not fixed.
PR Close#28033
An @NgModule with an 'id' property has its type registered in a global map
of modules by id. This happens during compilation of the module.
In Ivy, modules are first compiled when the @NgModule decorator executes.
In tests, they might be passed again through the TestBed's compiler,
resulting in a second compilation and registration.
Before this fix, this second registration would cause an error, as the id
was previously registered. This commit makes the registration idempotent,
so if the same module type is being registered for the same id then no
error is thrown.
Testing strategy: future commits change the way the TestBed compiles
modules, causing tests to become sensitive to this bug if not fixed.
PR Close#28033
Previously, we had the logic to schedule a change detection tick
inside markViewDirty(). This is fine when used in markDirty(),
the user-facing API, because it should always schedule change
detection. However, this doesn't work when used in markForCheck()
because historically markForCheck() does not trigger change
detection.
To be backwards compatible, this commit moves the scheduling
logic out of markViewDirty() and into markDirty(), so
markForCheck no longer triggers a tick.
PR Close#28048
Libraries that create components dynamically using component factories,
such as `@angular/upgrade` need to pass blocks of projected content
through to the `ComponentFactory.create()` method. These blocks
are extracted from the content by matching CSS selectors defined in
`<ng-content select="..">` tags found in the component's template.
The Angular compiler collects these CSS selectors when compiling a component's
template, and exposes them via the `ComponentFactory.ngContentSelectors`
property.
This change ensures that this property is filled correctly when the
component factory is created by compiling a component with the Ivy engine.
PR Close#27867
When a pipe returns an instance of WrappedValue we should "invalidate" value
of a binding where the pipe in question is used.
Before this change we've always wrtten the invalidation value (NO_CHANGE) to
the binding root this invalidating the first binding in a LView. This commit
corrects the binding index calculation so the binding with a pipe is invalidated.
PR Close#28044
exportAs in @Directive metadata supports multiple values, separated by
commas. Previously it was treated as a single value string.
This commit modifies the compiler to understand that exportAs is a
string[]. It stops short of carrying the multiple values through to the
runtime. Instead, it only emits the first one. A future commit will modify
the runtime to accept all the values.
PR Close#28001
Currently the ImportManager class handles various rewriting actions of
imports when compiling @angular/core. This is required as code compiled
within @angular/core cannot import from '@angular/core'. To work around
this, imports are rewritten to get core symbols from a particular file,
r3_symbols.ts.
In this refactoring, this rewriting logic is moved out of the ImportManager
and put behind an interface, ImportRewriter. There are three implementers
of the interface:
* NoopImportRewriter, used for compiling all non-core packages.
* R3SymbolsImportRewriter, used when ngtsc compiles @angular/core.
* NgccFlatImportRewriter, used when ngcc compiles @angular/core (special
logic is needed because ngcc has to rewrite imports in flat bundles
differently than in non-flat bundles).
This is a precursor to using this rewriting logic in other contexts besides
the ImportManager.
PR Close#27998
TestBed used to have its own implementation of the `transitiveScopesFor` function, customized for TestBed needs (to compile NgModules). This change unifies the `transitiveScopesFor` function usage by importing it from the `jit/module.ts` script and adding extra argument to configure its behavior (how to compile NgModule), so that TestBed can leverage it.
PR Close#27860
These tests validate the ability of the View Engine TestBed to consume
summary metadata, a mechanism which allows the TestBed to use
AOT-compiled components & directives in tests. It achieves this through
two operations which are independently obsolete in Ivy:
1. It injects CompileMetadataResolver, a View Engine specific compiler
internal class which extracts global analysis metadata from classes,
and uses it to construct summary metadata. This happens in a
beforeEach() block which calls createSummaries().
2. It uses TestBed.initTestEnvironment to pass summary metadata to the
TestBed itself. Any such metadata is ignored in Ivy.
Operation #1 makes it impossible to run these tests under Ivy, as the
CompileMetadataResolver is not available with an Ivy compiler.
Ivy itself does not rely on summary data, and the R3TestBed can depend
directly on AOT compiled components without it. Thus, the spirit of thes
tests is obsolete in an Ivy world.
FW-838 #resolve
PR Close#28027
Previously the canInsertNativeNode and getRenderParent functions had almost
_exaclty_ the same logic. What was worse that getRenderParent was calling
canInsertNativeNode thus executing the same, non-trivial logic twice.
This commit merges canInsertNativeNode and getRenderParent into one function.
Now getRenderParent will return a native parent or null if a node can't be
inserted (content projection, root of a view that is not inserted etc.).
PR Close#28011
Previously presence and type of a parent tNode was split among
canInsertNativeNode, canInsertNativeChildOfView and canInsertNativeChildOfElement.
This commit centralises the logic in canInsertNativeNode thus simplifying
the overall logic and making canInsertNativeChildOfElement trivial.
PR Close#28011
The problem that `fixmeIvy`s refer to is resolved, but the tests are still broken due to other issue (not possible to retrieve host property bindings for DebugElement).
PR Close#28003
This commit adds sanitization for `elementProperty` and `elementAttribute` instructions used in `hostBindings` function, similar to what we already have in the `template` function. Main difference is the fact that for some attributes (like "href" and "src") we can't define which SecurityContext they belong to (URL vs RESOURCE_URL) in Compiler, since information in Directive selector may not be enough to calculate it. In order to resolve the problem, Compiler injects slightly different sanitization function which detects proper Security Context at runtime.
PR Close#27939
Previously the appendChild / removeChild could take null as an argument for
a child to be added / removed. This is difficult to understand since the
mentioned methods are noop if a child is null.
This commit clarifies the appendChild / removeChild signature to systematically
require a child node to be added removed. It turns out that null could be passed
only for a very specific i18n cases so now we guard a call to removeChild with
an explicit check on the i18n side.
PR Close#27987
This update introduces support for global object (window, document, body) listeners, that can be defined via host listeners on Components and Directives.
PR Close#27772
`i18nAttributes` was throwing an error when it was called multiple times in the create part of the template function with the same index, for example when we create multiple components with the same template. It shouldn't throw in this case, and just use the cache when available.
FW-903 #resolve
PR Close#27911
Fixes Ivy's `QueryList` not being an instance of the exported ViewEnginer `QueryList`.
Also reworks `first`, `last` and `length` to be regular properties, rather than setters. Reworking `length` was required to be able to extend the ViewEngine `QueryList`, but I reworked `first` and `last` as well since getters generate a lot more code when transpiled to ES5.
These changes fix FW-706.
PR Close#27942
`R3TestBed` allows consumers to configure a "testing module", declare components, override various metadata, etc. To do this, it implements its own JIT compilation, where components/directives/modules have Ivy definition fields generated based on testing metadata. It results in tests interfering with each other. One test might override something in a component that another test tries to use normally, causing failures.
In order to resolve this problem, we store current components/directives/modules defs before applying overrides and re-compiling. Once the test is complete, we restore initial defs, so the next tests interact with "clean" components.
PR Close#27786
Previously, there could be identical template/listener function names
for a component's template, if it had multiple similarly structured
nested sub-templates or listeners.
This resulted in build errors:
`Identifier '<SOME_IDENTIFIER>' has already been declared`
This commit fixes this by ensuring that the template index is included
in the `contextName` passed to the `TemplateDefinitionBuilder`
responsible for processing nested sub-templates.
Similarly, the template or element index is included in the listener
names.
PR Close#27766
This PR assures that content projection works if an <ng-content> tag is
placed inside an <ng-template> in one component and that <ng-template>
is inserted into a different component. It fixes a bug where the
projection instruction code would walk up the insertion tree to find
selector data instead of the declaration tree.
PR Close#27783
Prior to this change, ICU extraction logic was not taking into account nested bindings (that look like this: �0:1�) and only accounted for top level bindings (like this �0�). As a result, ICUs were not parsed and remained as text in the output. Now the extraction logic (regular expressions) take into account the nested bindings format as well.
PR Close#27914
Some of the animation tests have been failing because animation gets
triggered multiple times. The reason for this is that the compiler was
generating static attribute bindings in addition to dynamic bindings.
This created multiple writes to the animation render which failed the
tests.
PR Close#27805
Forward refs in some places (like imports/export/providers/viewProviders/queries) were not resolved before passing to compilation phase. Now we resolve missing refs before invoking compile function.
PR Close#27737
Prior to this change, provider overrides defined via TestBed.overrideProvider were not applied to Components/Directives. Now providers are taken into account while compiling Components/Directives (metadata is updated accordingly before being passed to compilation).
PR Close#27693
In some cases in our tests we can define multiple overrides for a given class. As a result, only the last override is actually applied due to the fact that we store overrides in a Type<->Override map. This update changes the logic to keep all overrides defined in a given test for a Type (i.e. Type<->Override[] map) and applies them one by one at resolution phase. This behavior is more inline with the previous TestBed.
PR Close#27734
Previously ivy code generation was emmiting the projectionDef instruction in
a template where the <ng-content> tag was found. This code generation logic was
incorrect since the ivy runtime expects the projectionDef instruction to be present
in the main template only.
This PR ammends the code generation logic so that the projectionDef instruction is
emmitedin the main template only.
PR Close#27755
Prior to this commit, we had two different modes for change detection
execution for Ivy, depending on whether you called `bootstrap()` or
`renderComponent()`. In the former case, we would complete creation
mode for all components in the tree before beginning update mode for
any component. In the latter case, we would run creation mode and
update mode together for each component individually.
Maintaining code to support these two different execution orders was
unnecessarily complex, so this commit aligns the two bootstrapping
mechanisms to execute in the same order. Now creation mode always
runs for all components before update mode begins.
This change also simplifies our rendering logic so that we use
`LView` flags as the source of truth for rendering mode instead of
`rf` function arguments. This fixed some related bugs (e.g. calling
`ViewRef.detectChanges` synchronously after the view's creation
would create view nodes twice, view queries would execute twice, etc).
PR Close#27744
We invoked `hostBindings` function in Create and Update modes with different element index due to the fact that we did not subtract HEADER_OFFSET from the index before passing it to `hostBindings` function in Create mode. Now we subtract HEADER_OFFSET value before invoking `hostBindings`, which makes Ceate and Update calls consistent.
PR Close#27694
Context discovery was only available on elements. This PR adds support for containers and ICU expressions.
FW-378 #resolve
FW-665 #comment linker integration tests
PR Close#27644
Pawel Kozlowski
Kristiyan Kostadinov
Alex Rickabaugh
Andrew Kushnir
Paul Gschwendtner
Olivier Combe
Riley Littlefield
Ivan Tham
Alan
Kara Erickson
Pete Bacon Darwin
Marc Laval
Matias Niemelä
Judy Bogart
Misko Hevery
Greg Magolan
Rado Kirov
George Kalpakas
Wassim Chegham
Brandon
Ben Lesh
Jeremy Elbourn
Trotyl Yu
JoostK
cexbrayat
Alexey Zuev
Erick Xavier
onlyflix
jithil-kore
Benedikt Meurer
Daniel Ruf
Jason Aden
Sarun Intaralawan
Sander Elias
Alex Eagle
Ernest Galbrun
Kara
Teamop
Meknassih
Dario Braun
Michael De Wree