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
`NgModule` requires that `Component`s/`Directive`s/`Pipe`s are listed in
declarations, and that each `Component`s/`Directive`s/`Pipe` is declared
in exactly one `NgModule`. This change adds runtime checks to ensure
that these sementics are true at runtime.
There will need to be seperate set of checks for the AoT path of the
codebase to verify that same set of semantics hold. Due to current
design there does not seem to be an easy way to share the two checks
because JIT deal with references where as AoT deals with AST nodes.
PR Close#27604
While creating FESM files, rollup usually drops all unused symbols.
All *__POST_R3__ are unused unless ngcc rewires stuff. To prevent this DCE
we reexport them as private symbols. If ngcc is not used, these symbols will
be dropped when we optimize an application bundle.
PR Close#27438
Prior to this change, we were unable to match directives using `ng-template` tags (for example the following selector would not work even though there might be some <ng-template>s in a template: `ng-template[directiveA]`. As a result, that broke some components that relies on such selectors to work. In order to resolve the problem, we now pass tag name to the `template` instruction (where we passed `null` before) and this tag name is used for matching at runtime. This update should also help support projecting containers, because the tag name is required to properly match such elements.
PR Close#27636
All the tests in `packages/core/test/view/` are specific to the `ViewEngine` and shouldn't run for ivy. This PR introduces a new BUILD.bazel file to run those tests separately.
PR Close#27645
In Ivy, a pure call to `setClassMetadata` is inserted to retain the
information that would otherwise be lost while eliding the Angular
decorators. In the past, the Angular constructor decorators were
wrapped inside of an anonymous function which was only evaluated once
`ReflectionCapabilities` was requested for such metadata. This approach
prevents forward references from inside the constructor parameter
decorators from being evaluated before they are available.
In the `setClassMetadata` call, the constructor parameters were not wrapped
within an anonymous function, such that forward references were evaluated
too early, causing runtime errors.
This commit changes the `setClassMetadata` call to pass the constructor
parameter decorators inside of an anonymous function again, such that
forward references are not resolved until requested by
`ReflectionCapabilities`, therefore avoiding the early reads of forward refs.
PR Close#27561
Currently the `ViewRef.destroy` method assumes that its index inside the view container will always be valid, however if it has been removed already, it'll be -1 which will throw an error.
The error manifested itself in one of the unit tests where a view had been detached during the test and then `TestBed` attempted to destroy its `ComponentRef` which ended threw an `Error during cleanup of component`.
PR Close#27585
Since Renderer is shared across root and child views, we need to avoid `destroy` method invocation for child views and only invoke is for root view when needed. Prior to this change, the `destroy` function was called whenever child view was destroyed, thus causing errors at runtime.
PR Close#27592
Previously in Ivy, host bindings did not work if they shared a public name
with an Input because they used the `elementProperty` instruction as is.
This instruction was originally built for inside component templates, so it
would either set a directive input OR a native property. This is the
correct behavior for inside a template, but for host bindings, we always
want the native properties to be set regardless of the presence of an Input.
This change adds an extra argument to `elementProperty` so we can tell it to
ignore directive inputs and only set native properties (if it is in the
context of a host binding).
PR Close#27589
In `ViewRef.detectChanges`, we are passing `ViewRef.context` into `detectChanges` to trigger change detection. This only makes sense for component `ViewRefs` (i.e. injected `ChangeDetectorRefs`) because with embedded views, `context` is not a component instance where the view has been monkey-patched. It's a just a normal object, so the view will be undefined.
In order to resolve this problem, we now invoke `detectChangesInternal` and also pass `LView` (to make sure we always have a view available).
PR Close#27521
We had two `NodeInjector` classes: one in `view_compatibility` and one in `di`. We replaced the one in `di` with the one from `view_compatibility` and reconciled their differences.
PR Close#27541
While generating attributes for `projection` instruction, we checked whether attribute name is equal to 'select' in lower case. However in other cases we treat 'select' attribute name as case-insensitive. This PR makes 'select' attribute consistently case-insensitive.
PR Close#27500
Prior to this change, animation properties were defined as element attributes, which caused errors at runtime. Now all animation-related attributes are defined as element properties.
Also as a part of this update, we start to account for bindings used in animations, which was previously missing.
PR Close#27496
Analogously to directives, the `ngInjectableDef` field in .d.ts files is
annotated with the type of service that it represents. If the service
contains required generic type arguments, these must be included in
the .d.ts file.
PR Close#27037
(FW-777)
When an Injector is provided, R3Injector instantiates it by calling its
constructor instead of its factory, not resolving dependencies.
With this fix, the ngInjectorDef is checked and the factory is correctly
used if it is found.
PR Close#27456
When detaching a view by its index via `ViewContainerRef.detach(index)`, in `ViewEngine` we used to return a new `ViewRef` ([for reference](https://github.com/angular/angular/blob/master/packages/core/src/view/refs.ts#L227)), however in Ivy we return the same `ViewRef` which means that its internal `_viewContainerRef` is never reset and we'll throw an error if the consumer tried to attach it to the `ApplicationRef`. These changes return a new `ViewRef` in order to match the original behavior.
These changes also add the same errors as `ViewEngine` when attempting to attach a view that is attached already. This was the original goal of this PR, however it ended up uncovering the issues with the `ViewRef`.
PR Close#27437
Prior to this change, the number of host vars stored for directives with `hostBindings` in expando block was incorrect for inherited directives (in case both parent and child directive have `hostBindings` defined). Now if we identify that we already added a `hostBinding` into expando block, we just increase the corresponding number of host binding vars
PR Close#27392
In Angular, it used to be an accepted practice to use strings as dependency
injection tokens. E.g. {provide: 'test', useValue: 'provided'}. However,
the Ivy node injection system did not support this. The Ivy DI system
attempts to patch a Bloom bit index onto each type registered with it, and
this patch operation does not work for a string token.
This commit adds string token support to the bloom filter system by
reserving bit 0 for string tokens. This eliminates the need for each string
token to store its own Bloom bit, at the expense of slightly more expensive
lookups of string tokens.
PR Close#27383
Previously the concept of multiple directives with the same selector was
not supported by ngtsc. This is due to the treatment of directives for a
component as a Map from selector to the directive, which is an erroneous
representation.
Now the directives for a component are stored as an array which supports
multiple directives with the same selector.
Testing strategy: a new ngtsc_spec test asserts that multiple directives
with the same selector are matched on an element.
PR Close#27298
BREAKING CHANGE:
The public API for `DebugNode` was accidentally too broad. This change removes
1. Public constructor. Since `DebugNode` is a way for Angular to communicate information
on to the developer there is no reason why the developer should ever need to
Instantiate the `DebugNode`
2. We are also removing `removeChild`, `addChild`, `insertBefore`, and `insertChildAfter`.
All of these methods are used by Angular to constructor the correct `DebugNode` tree.
There is no reason why the developer should ever be constructing a `DebugNode` tree
And these methods should have never been made public.
3. All properties have been change to `readonly` since `DebugNode` is used by Angular
to communicate to developer and there is no reason why these APIs should be writable.
While technically breaking change we don’t expect anyone to be effected by this change.
PR Close#27223
This fixes an issue where a value would hide the type.
```
export interface Foo {
someMethod(): void;
}
export const Foo: Function = ...;
```
In the above example the `Foo` constant will hide the `interface Foo` symbol.
This change properly saves the interface in addition to the type.
PR Close#27223
A recent commit (probably 2c7386c) has changed the import graph of the
DI types in core, and somehow results in the ngc compiler deciding to
re-export core DI types from application factories which tangentially
use inject(). This is not really surprising; ngc's import graph can be
very unstable.
However, this results in a re-export of InjectFlags surviving JS
compilation. InjectFlags was a const enum, akin to an interface in TS,
with no runtime repesentation. This causes a warning to be emitted by
Webpack when it sees the re-export of InjectFlags.
This commit avoids the issue by removing 'const' from the declaration
of InjectFlags, causing it to have a runtime value. This is a temporary
fix. The real fix will be for ngc to no longer write exports of const
enums.
Testing strategy: manually verified. Due to the problem only manifesting
when recompiling after a change and then running Webpack, there is no
existing framework via which this could be easily tested with an
integration test. Additionally, the potential for this issue is gone in
Ivy, so this solution is only temporarily needed.
Fixes#27251.
PR Close#27279
These paths are no longer needed / used.
I had to disable one jit mode spec because it fails now that we actually run it.
I root caused the jit test failure as missing forwardRef support. See FW-645.
PR Close#27278
Currently we store the `_appRef` when a `ViewRef` is attached, however we don't use it for anything. These changes use it to detach the view from the `ApplicationRef` when it is destroyed. These changes also fix that the `ComponentRef` doesn't remove its `ViewRef` on destroy.
PR Close#27276
When ngtsc compiles @angular/core, it rewrites core imports to the
r3_symbols.ts file that exposes all internal symbols under their
external name. When creating the FESM bundle, the r3_symbols.ts file
causes the external symbol names to be rewritten to their internal name.
Under ngcc compilations of FESM bundles, the indirection of
r3_symbols.ts is no longer in place such that the external names are
retained in the bundle. Previously, the external name `ɵdefineNgModule`
was explicitly declared internally to resolve this issue, but the
recently added `setClassMetadata` was not declared as such, causing
runtime errors.
Instead of relying on the r3_symbols.ts file to perform the rewrite of
the external modules to their internal variants, the translation is
moved into the `ImportManager` during the compilation itself. This
avoids the need for providing the external name manually.
PR Close#27055
Currently the `useJit` option from `TestBed.configureCompiler` isn't supported. These changes rework the existing test suites not to pass in `useJit` when running with Ivy.
PR Close#27067
Adds support for the `providers` that are passed in through `TestBed.configureCompiler` and scopes the error only if the consumer has passed in `useJit`.
PR Close#27066
This API is part of our public api surface and needs to be monitored by the public_api_guard.
I also had to go back and mark all of the exported functions with @publicApi jsdoc tag.
PR Close#27008
When compiling the flat-file version of the `@angular/core` we need to be aware
that we cannot rely upon imported names to access the ivy definition functions.
The compiler is already clever enough to use local function calls rather than
trying to add a namespaced import, but there is a problem if the local name of the
function is different to the exported name. This is the case for functions that
are not part of the public API, and so are exported under a barred-O private alias.
In `@angular/core` the only decorations in use are `@NgModule` and `@Injectable`.
There are no directives, components, pipes, etc.
Since `defineInjectable` is part of the public API of `@angular/core`, the compiler
is able to generate code that references the original non-barred-O version of the
function.
But the `defineNgModule` is not part of the public API and so the compiler must
generate code that refers to it by the private barred-O version of the function.
This commit imports and then re-exports this barred-O version of `defineModule` to
ensure that the symbol is available in the local scope of the flat-file versions of
the `@angular/core` library.
PR Close#26403
This commit causes a call to setClassMetadata() to be emitted for every
type being compiled by ngtsc (every Angular type). With this metadata,
the TestBed should be able to recompile these classes when overriding
decorator information.
Testing strategy: Tests in the previous commit for
generateSetClassMetadataCall() verify that the metadata as generated is
correct. This commit enables the generation for each DecoratorHandler,
and a test is added to ngtsc_spec to verify all decorated types have
metadata generated for them.
PR Close#26860
This commit introduces the setClassMetadata() private function, which
adds metadata to a type in a way that can be accessed via Angular's
ReflectionCapabilities. Currently, it writes to static fields as if
the metadata being added was downleveled from decorators by tsickle.
The plan is for ngtsc to emit code which calls this function, passing
metadata on to the runtime for testing purposes. Calls to this function
would then be tree-shaken away for production bundles.
Testing strategy: proper operation of this function will be an integral
part of TestBed metadata overriding. Angular core tests will fail if this
is broken.
PR Close#26860
These tests were previously not running on CI so they have always been broken,
or got broken just recently :-(.
test(ivy): mark failing test targets with fixme-ivy-jit and fixme-ivy-local tags
PR Close#26735
Comment nodes that are child nodes of unsafe elements are identified as text nodes. This results in the comment node being returned as an encoded string.
Add a check to ignore such comment nodes.
PR Close#25879
We are close enough to blacklist a few test targets, rather than whitelist targets to run...
Because bazel rules can be composed of other rules that don't inherit tags automatically,
I had to explicitly mark all of our ts_library and ng_module targes with "ivy-local" and
"ivy-jit" tags so that we can create a query that excludes all fixme- tagged targets even
if those targets are composed of other targets that don't inherit this tag.
This is the updated overview of ivy related bazel tags:
- ivy-only: target that builds or runs only under ivy
- fixme-ivy-jit: target that doesn't yet build or run under ivy with --compile=jit
- fixme-ivy-local: target that doesn't yet build or run under ivy with --compile=local
- no-ivy-jit: target that is not intended to build or run under ivy with --compile=jit
- no-ivy-local: target that is not intended to build or run under ivy with --compile=local
PR Close#26471
Originally, the ivy_switch mechanism used Bazel genrules to conditionally
compile one TS file or another depending on whether ngc or ngtsc was the
selected compiler. This was done because we wanted to avoid importing
certain modules (and thus pulling them into the build) if Ivy was on or
off. This mechanism had a major drawback: ivy_switch became a bottleneck
in the import graph, as it both imports from many places in the codebase
and is imported by many modules in the codebase. This frequently resulted
in cyclic imports which caused issues both with TS and Closure compilation.
It turns out ngcc needs both code paths in the bundle to perform the switch
during its operation anyway, so import switching was later abandoned. This
means that there's no real reason why the ivy_switch mechanism needed to
operate at the Bazel level, and for the ivy_switch file to be a bottleneck.
This commit removes the Bazel-level ivy_switch mechanism, and introduces
an additional TypeScript transform in ngtsc (and the pass-through tsc
compiler used for testing JIT) to perform the same operation that ngcc
does, and flip the switch during ngtsc compilation. This allows the
ivy_switch file to be removed, and the individual switches to be located
directly next to their consumers in the codebase, greatly mitigating the
circular import issues and making the mechanism much easier to use.
As part of this commit, the tag for marking switched variables was changed
from __PRE_NGCC__ to __PRE_R3__, since it's no longer just ngcc which
flips these tags. Most variables were renamed from R3_* to SWITCH_* as well,
since they're referenced mostly in render2 code.
Test strategy: existing test coverage is more than sufficient - if this
didn't work correctly it would break the hello world and todo apps.
PR Close#26550
Using Renderer’s setElementAttribute or setElementStyle with a null or undefined value removes the
corresponding attribute or style. The argument type should allow this when using strictNullChecks.
Closes#13686
PR Close#17065
The 'animations' field of @Component metadata should be copied directly
into the ngComponentDef for that component and should not pass through
static resolution.
Previously the animations array was statically resolved and then the
values were translated back when generating ngComponentDef.
PR Close#26322
While creating FESM files, rollup usually drops all unused symbols.
All *__POST_NGCC__ are unused unless ngcc rewires stuff. To prevent this DCE
we reexport them as private symbols. If ngcc is not used, these symbols will
be dropped when we optimize an application bundle.
PR Close#26071
This commit adds an ngTemplateGuard_ngIf static method to the NgIf
directive and an ngTemplateContextGuard static method to NgFor. The
function of these two static methods is to enable type narrowing
within generated type checking code for consumers of the directives.
PR Close#26203
Previously in Ivy, metadata for directives/components/modules/etc was
carried in .d.ts files inside type information encoded on the
DirectiveDef, ComponentDef, NgModuleDef, etc types of Ivy definition
fields. This works well, but has the side effect of complicating Ivy's
runtime code as these extra generic type parameters had to be specified
as <any> throughout the codebase. *DefInternal types were introduced
previously to mitigate this issue, but that's the wrong way to solve
the problem.
This commit returns *Def types to their original form, with no metadata
attached. Instead, new *DefWithMeta types are introduced that alias the
plain definition types and add extra generic parameters. This way the
only code that needs to deal with the extra metadata parameters is the
compiler code that reads and writes them - the existence of this metadata
is transparent to the runtime, as it should be.
PR Close#26203
Properties are not allowed usage notes, and in this case the example
is so simple it didn't warrant moving it to the overall class documentation.
PR Close#26039
Create getter methods `getXXXDef` for each definition which
uses `hasOwnProperty` to verify that we don't accidently read form the
parent class.
Fixes: #24011Fixes: #25026
PR Close#25736
Various user code uses 'instanceof' to check whether a particular instance
is a TemplateRef, ElementRef, etc. Ivy needs to work with these checks.
PR Close#25775
The bootstrap property of @NgModule was not previously compiled by
the compiler in AOT or JIT modes (in Ivy). This commit adds support
for bootstrap.
PR Close#25775
defineComponent() and friends can return a flyweight EMPTY object for
specific fields when they contain no data. InheritDefinitionFeature
was attempting to write into these flyweight objects, which have been
protected with Object.freeze().
This commit adds detection to InheritDefinitionFeature to identify the
frozen objects.
PR Close#25755
While creating FESM files, rollup usually drops all unused symbols.
All *__POST_NGCC__ are unused unless ngcc rewires stuff. To prevent this DCE
we reexport them as private symbols. If ngcc is not used, these symbols will
be dropped when we optimize an application bundle.
We don't have an infrastructure to test this fix, so I just manually inspected
the bundles before and after to verify that the fix works.
PR Close#25780
Closure compiler requires that the i18n message constants of the form
const MSG_XYZ = goog.getMessage('...');
have names that are unique across an entire compilation, even if the
variables themselves are local to a given module. This means that in
practice these names must be unique in a codebase.
The best way to guarantee this requirement is met is to encode the
relative file name of the file into which the constant is being written
into the constant name itself. This commit implements that solution.
PR Close#25689
When using ViewEncapsulation.ShadowDom, Angular will not remove the child nodes of the DOM node a root Component is bootstrapped into. This enables developers building Angular Elements to use the `<slot>` element to do native content projection.
PR Close#24861
By pulling in `compiler` into `core` the `compiler` was not
100% tree-shakable and about 8KB of code was retained
when tree-shaken with closure.
PR Close#25531
Provides a runtime and compile time switch for ivy including
`ApplicationRef.bootstrapModule`.
This is done by naming the symbols such that `ngcc` (angular
Compatibility compiler) can rename symbols in such a way that running
`ngcc` command will switch the `@angular/core` module from `legacy` to
`ivy` mode.
This is done as follows:
```
const someToken__PRE_NGCC__ = ‘legacy mode’;
const someToken__POST_NGCC__ = ‘ivy mode’;
export someSymbol = someToken__PRE_NGCC__;
```
The `ngcc` will search for any token which ends with `__PRE_NGCC__`
and replace it with `__POST_NGCC__`. This allows the `@angular/core`
package to be rewritten to ivy mode post `ngcc` execution.
PR Close#25238
When an Angular decorated class is inherited, it might be the case that
the entire inheritance chain actually has no constructor defined. In
that event, a factory which simply instantiates the type without any
arguments should be used.
PR Close#25425
When @angular/core is compiled by ngtsc, a factory file is generated
for ApplicationModule, that is currently invalid because r3_symbols
does not export NgModuleFactory. This change fixes that issue and
ensures the generated ngfactory file for @angular/core is valid.
PR Close#25392
When generating the 'directives:' property of ngComponentDef, ngtsc
needs to be conscious of declaration order. If a directive being
written into the array is declarated after the component currently
being compiled, then the entire directives array needs to be wrapped
in a closure.
This commit fixes ngtsc to pay attention to such ordering issues
within directives arrays.
PR Close#25392
This commit creates an API for factory functions which allows them
to be inherited from one another. To do so, it differentiates between
the factory function as a wrapper for a constructor and the factory
function in ngInjectableDefs which is determined by a default
provider.
The new form is:
factory: (t?) => new (t || SomeType)(inject(Dep1), inject(Dep2))
The 't' parameter allows for constructor inheritance. A subclass with
no declared constructor inherits its constructor from the superclass.
With the 't' parameter, a subclass can call the superclass' factory
function and use it to create an instance of the subclass.
For @Injectables with configured providers, the factory function is
of the form:
factory: (t?) => t ? constructorInject(t) : provider();
where constructorInject(t) creates an instance of 't' using the
naturally declared constructor of the type, and where provider()
creates an instance of the base type using the special declared
provider on @Injectable.
PR Close#25392
Pawel Kozlowski
Alan Agius
Marc Laval
Matias Niemelä
George Kalpakas
Kara Erickson
Andrew Kushnir
Misko Hevery
Michael De Wree
Kristiyan Kostadinov
Alex Eagle
Olivier Combe
JoostK
Alex Eagle
Igor Minar
Sander Elias
Ben Lesh
Alex Rickabaugh
Judy Bogart
Pete Bacon Darwin
Trotyl
Shino Kurian
Anthony Ciccarello
Greg Magolan
Manduro
Adam Plumer
cexbrayat
Rob Wormald
Victor Berchet
Kieran Whiteman
JiaLi.Passion
Roope Hakulinen