Closure Compiler in some configurations complains about duplicate
imports. This change replaces the export-with-import with an export of
the imported symbol.
closes#23993
PR Close#24203
This PR tackles a simple case where ViewRef definition point (<ng-template>) is the
same as the insertion point (ViewContainerRef requested on the said <ng-template>).
For this particular case we can assume that we know a container into which a given
view will be inserted when a view is created. This is not true fall all the possible
cases so follow-up PR will be needed to extend this basic implementation.
PR Close#24179
This commit builds out enough of the JIT compiler to render
//packages/core/test/bundling/todo, and allows the tests to run in
JIT mode.
To play with the app, run:
bazel run --define=compile=jit //packages/core/test/bundling/todo:prodserver
PR Close#24138
In ngIvy directives matching (determining which directives are active based
on a CSS seletor) happens at runtime. This means that runtime needs to have
enough context to match directives. This PR takes care of cases where a directive's
selector should match bindings (ex. [foo]="exp") and event handlers (ex. (out)="do()").
In the mentioned cases we need to have binding / output "attributes" for directive's
CSS selector matching purposes. At the same time those are not regular attributes and
as such should not be reflected in the DOM.
Closes#23706
PR Close#23991
Bazel has a restriction that a single output (eg. a compiled version of
//packages/common) can only be produced by a single rule. This precludes
the Angular repo from having multiple rules that build the same code. And
the complexity of having a single rule produce multiple outputs (eg. an
ngc-compiled version of //packages/common and an Ivy-enabled version) is
too high.
Additionally, the Angular repo has lots of existing tests which could be
executed as-is under Ivy. Such testing is very valuable, and it would be
nice to share not only the code, but the dependency graph / build config
as well.
Thus, this change introduces a --define flag 'compile' with three potential
values. When --define=compile=X is set, the entire build system runs in a
particular mode - the behavior of all existing targets is controlled by
the flag. This allows us to reuse our entire build structure for testing
in a variety of different manners. The flag has three possible settings:
* legacy (the default): the traditional View Engine (ngc) build
* local: runs the prototype ngtsc compiler, which does not rely on global
analysis
* jit: runs ngtsc in a mode which executes tsickle, but excludes the
Angular related transforms, which approximates the behavior of plain
tsc. This allows the main packages such as common to be tested with
the JIT compiler.
Additionally, the ivy_ng_module() rule still exists and runs ngc in a mode
where Ivy-compiled output is produced from global analysis information, as
a stopgap while ngtsc is being developed.
PR Close#24056
Short-circuitable expressions (using ternary & binary operators) could not use
the regular binding mechanism as it relies on the bindings being checked every
single time - the index is incremented as part of checking the bindings.
Then for pure function kind of bindings we use a different mechanism with a
fixed index. As such short circuiting a binding check does not mess with the
expected binding index.
Note that all pure function bindings are handled the same wether or not they
actually are short-circuitable. This allows to keep the compiler and compiled
code simple - and there is no runtime perf cost anyway.
PR Close#24039
This commit adds a mechanism by which the @angular/core annotations
for @Component, @Injectable, and @NgModule become decorators which,
when executed at runtime, trigger just-in-time compilation of their
associated types. The activation of these decorators is configured
by the ivy_switch mechanism, ensuring that the Ivy JIT engine does
not get included in Angular bundles unless specifically requested.
PR Close#23833
Previously, ngOnDestroy was only called on services which were statically
determined to have ngOnDestroy methods. In some cases, such as with services
instantiated via factory functions, it's not statically known that the service
has an ngOnDestroy method.
This commit changes the runtime to look for ngOnDestroy when instantiating
all DI tokens, and to call the method if it's present.
Fixes#22466Fixes#22240Fixes#14818
PR Close#23755
Fix a corner case where eager providers were getting constructed twice if the provider was requested before the initialization of the NgModule is complete.
PR Close#23559
The bug fixed here steams from the fact that we are traversing too far up
in the views tree hierarchy in the destroyViewTree function.
The logic in destroyViewTree is off if we start removal at an embedded view
without any child views. For such a case we should just clean up (cleanUpView)
this one view without paying attention to next / parent views.
PR Close#23482
Ivy definition looks something like this:
```
class MyService {
static ngInjectableDef = defineInjectable({
…
});
}
```
Here the argument to `defineInjectable` is well known public contract which needs
to be honored in backward compatible way between versions. The type of the
return value of `defineInjectable` on the other hand is private and can change
shape drastically between versions without effecting backwards compatibility of
libraries publish to NPM. To our users it is effectively an opaque token.
For this reson why declare the return value of `defineInjectable` as `never`.
PR Close#23383
Ivy definition looks something like this:
```
class MyService {
static ngInjectableDef = defineInjectable({
…
});
}
```
Here the argument to `defineInjectable` is well known public contract which needs
to be honored in backward compatible way between versions. The type of the
return value of `defineInjectable` on the other hand is private and can change
shape drastically between versions without effecting backwards compatibility of
libraries publish to NPM. To our users it is effectively an `OpaqueToken`.
By prefixing the type with `ɵ` we are communicating the the outside world that
the value is not public API and is subject to change without backward compatibility.
PR Close#23371
- Remove default injection value from `inject` / `directiveInject` since
it is not possible to set using annotations.
- Module `Injector` is stored on `LView` instead of `LInjector` data
structure because it can change only at `LView` level. (More efficient)
- Add `ngInjectableDef` to `IterableDiffers` so that existing tests can
pass as well as enable `IterableDiffers` to be injectable without
`Injector`
PR Close#23345
This change changes:
- compiler uses `directiveInject` instead of `inject` for `Directive`s
- unifies the flags in `di` as well as `render3`
- changes the signature of `directiveInject` to match `inject` In prep for #23330
- compiler now generates flags for injection.
Compiler portion of #23342
Prep for #23330
PR Close#23345
As we no longer create native (RNode) comment nodes for containers,
we need to execute logic for finding a next sibiling node with RNode
when inserting a view.
The mentioned logic need to be updated for the case of dynamically
created containers (LContainerNode). Indeed, we need to be able to
descend into dynamically inserted views while looking for a RNode.
To achieve this we need to have a pointer from a host LNode to a
dynamically created LContainerNode).
PR Close#23193
Currently the context for inject() is only set when the token is seen
for the first time. This has two issues:
* It should always be set when injecting from that injector, because
a constructor may wish to call inject() directly.
* If an NgModuleFactory is .create()'d twice, and an ngInjectableDef
token is requested from each of them, the second time will fail.
This is because the first injection adds the provider definition
and calls the factory, and the provider definitions are shared.
The second injector will see the provider definition and call the
factory to create an instance, but without setting the correct
context for inject().
Fixes angular/material2#10586.
PR Close#23148
Remove `containerRefreshStart` and `containerRefreshEnd` instruction
from the output.
Generate directives as a list in `componentDef` rather than inline into
instructions. This is consistent in making selector resolution runtime
so that translation of templates can follow locality.
PR Close#22921
In Ivy mode we rewrite references to Injector to INJECTOR in ngInjectableDef, to fix tree-shaking.
This changes the rewrite to happen always, even in non-Ivy mode, and makes Angular understand
INJECTOR across the board at runtime.
PR Close#23008
Previously, @Injectable() would generate an ngInjectableDef on the type it was
decorating, even if that type already had a compiled ngInjectableDef, overwriting
the compiled version.
PR Close#22943
Newer version of TS is stricter about types and flags counter-variant
types in some situations. This change inlines the DirectiveDefArgs
into the arguments which:
1) removes the inheritance which caused the issue and
2) Makes it more friendly to IDEs since they will not report comments.
Closes#22877Closes#22843
PR Close#22897
This adds compilation of @NgModule providers and imports into
ngInjectorDef statements in generated code. All @NgModule annotations
will be compiled and the @NgModule decorators removed from the
resultant js output.
All @Injectables will also be compiled in Ivy mode, and the decorator
removed.
PR Close#22458
Moves the status reporting from the issue #21706 to a file that
can be updated as changes are being made. This addresses one of the
comments on the issue and allows better tracking of updates to this
status and changes made.
PR Close#22751
BREAKING CHANGE:
The `<template>` tag was deprecated in Angular v4 to avoid collisions (i.e. when
using Web Components).
This commit removes support for `<template>`. `<ng-template>` should be used
instead.
BEFORE:
<!-- html template -->
<template>some template content</template>
# tsconfig.json
{
# ...
"angularCompilerOptions": {
# ...
# This option is no more supported and will have no effect
"enableLegacyTemplate": [true|false]
}
}
AFTER:
<!-- html template -->
<ng-template>some template content</ng-template>
PR Close#22783
Adds a stub for `elementStyle` and `elementClass` instruction
with a canonical spec for the compiler. The spec shows the the
compiler should be using `elementStyle` and `elementClass` instruction
in place of `[class]` and `[style]` bindings respectively.
PR Close#22719
Rename:
- `elementClass` (short: `k`) => `elementClassNamed` (short: `kn`)
- `elementStyle` (short: `s`) => `elementStyleNamed` (short: `sn`)
Currently `[class.name]` is `elementClass(0, ‘name’, value)`. We would
like to introduce new binding `[class]` which needs a new instruction
ideally `elementClass(0, value)`. Doing the rename creates space
to create such an instruction in subsequent change.
PR Close#22719
This patch removes the deprecated support for animation
symbol imports from @angular/core.
BREAKING CHANGE: it is no longer possible to import
animation-related functions from @angular/core. All
animation symbols must now be imported from @angular/animations.
PR Close#22692
This commit fixes a bug that would result in views insert / remove
even if a view needed only refresh operation.
The crux of the bug was that we were looking for a view to update
only in the LContainer.nextIndex position. This is incorrect as a
view with a given block id could be present later in the views
array (this happens if we about to remove a view in the middle of
the views array).
The code in this fix searches for a view to update in the views array and
can remove views in the middle of the views collection. Previously we
would remove views at the end of the collection only.
PR Close#22656
Allow passing an optional timeout to Testability's whenStable(). If
specified, if Angular is not stable before the timeout is hit, the
done callback will be invoked with a list of pending macrotasks.
Also, allows an optional update callback, which will be invoked whenever
the set of pending macrotasks changes. If this callback returns true,
the timeout will be cancelled and the done callback will not be invoked.
If the optional parameters are not passed, whenStable() will work
as it did before, whether or not the task tracking zone spec is
available.
This change also migrates the Testability unit tests off the deprecated
AsyncTestCompleter.
PR Close#16863
Rename @Injectable({scope -> providedIn}).
Instead of {providedIn: APP_ROOT_SCOPE}, accept {providedIn: 'root'}.
Also, {providedIn: null} implies the injectable should not be added
to any scope.
PR Close#22655
By providing a top level sanitization methods (rather than service) the
compiler can generate calls into the methods only when needed. This makes
the methods tree shakable.
PR Close#22540
inject() supports the ngInjectableDef-based configuration of the injector
(otherwise known as tree-shakeable services). It was missing from the
exported API of @angular/core, this PR adds it.
The test added here is correct in theory, but may pass accidentally due
to the decorator side-effect replacing the inject() call at runtime. An
upcoming compiler PR will strip reified decorators from the output
entirely.
Fixes#22388
PR Close#22389
InjectionToken can be created with an ngInjectableDef, and previously
this allowed the full expressiveness of @Injectable. However, this
requires a runtime reflection system in order to generate factories
from expressed provider declarations.
Instead, this change requires scoped InjectionTokens to provide the
factory directly (likely using inject() for the arguments), bypassing
the need for a reflection system.
Fixes#22205
PR Close#22207
@Injectable() supports a scope parameter which specifies the target module.
However, it's still difficult to specify that a particular service belongs
in the root injector. A developer attempting to ensure that must either
also provide a module intended for placement in the root injector or target
a module known to already be in the root injector (e.g. BrowserModule).
Both of these strategies are cumbersome and brittle.
Instead, this commit adds a token APP_ROOT_SCOPE which provides a
straightforward way of targeting the root injector directly, without
requiring special knowledge of modules within it.
PR Close#22185
This commit bundles 3 important changes, with the goal of enabling tree-shaking
of services which are never injected. Ordinarily, this tree-shaking is prevented
by the existence of a hard dependency on the service by the module in which it
is declared.
Firstly, @Injectable() is modified to accept a 'scope' parameter, which points
to an @NgModule(). This reverses the dependency edge, permitting the module to
not depend on the service which it "provides".
Secondly, the runtime is modified to understand the new relationship created
above. When a module receives a request to inject a token, and cannot find that
token in its list of providers, it will then look at the token for a special
ngInjectableDef field which indicates which module the token is scoped to. If
that module happens to be in the injector, it will behave as if the token
itself was in the injector to begin with.
Thirdly, the compiler is modified to read the @Injectable() metadata and to
generate the special ngInjectableDef field as part of TS compilation, using the
PartialModules system.
Additionally, this commit adds several unit and integration tests of various
flavors to test this change.
PR Close#22005
All of the providers in a module get compiled into a module definition in the
factory file. Some of these providers are for the actual module types, as those
are available for injection in Angular. For tree-shakeable tokens, the runtime
needs to be able to distinguish which modules are present in an injector.
This change adds a NodeFlag which tags those module providers for later
identification.
PR Close#22005
- Fix the case when first dynamic values are NO_CHANGE
- Do not store the static texts (even indexes) as bindings,
- Do not diff static texts (they do not change),
- Do not stringify static texts,
- Remove superfluous values walking.
PR Close#21881
By adding attributes on the <ng-content> element template authors
can decide how content should be re-projected (or, in other words:
which selectors should match re-projected content).
PR Close#21935
Implement NgOnChangesFeature, ViewContainerRef, TemplateRef,
and the renderEmbeddedTemplate instruction, and wire together the
pieces required for the ngForOf directive to work.
PR Close#21430
To prepare for pending ngForOf work, the dep from instructions -> query
should be broken. This will enable a dep from di -> instructions while
avoiding a di -> instructions -> query -> di cycle.
Analyzing this cycle also uncovered another problem: the implementation
of query() breaks tree-shaking through a hard dependency on DI concepts
of TemplateRef, ElementRef, ViewContainerRef. This is fundamentally due
to how query() can query for those values without any configuration.
Instead, this fix introduces the concept by employing the strategy
pattern, and redefining QueryReadType to pass a function which will
return one of the above values. This strategy is then used for 'read'
instead of an enum in cases where special values should be read from
the DI system.
PR Close#21430
assertLessThan() actually does the opposite of what it advertises.
It's only through luck that existing asserts have not failed
before. This changes assertLessThan to actually assert that the
value is less than something.
PR Close#21430
Adding the binding name to the error message recieved by the user gives
extra context on what exactly changed. The tests are also updated to
reflect the new error message.
PR Close#20352
- Improve `WrappedValue` by adding `unwrap` symetrical to `wrap`.
- remove dead code - `ValueUnwrapper`
The property `wrapped` is an implementation details and should never be accessed
directly - use `unwrap(wrappedValue)`. Will change to protected in Angular 7.
PR Close#20997
This change makes the code cleaner for the user. It does mean
a little bit more work for us since we have to patch the `type` back
into the `DirectiveDef`. However since the patching happens only once
on startup it should not be significant.
PR Close#21374
This separation is no longer needed since directives are now passed into the `container` as an array rather than as child functions of the `containerStart`
PR Close#21374
This change creates a spec file which contains canonical examples
of how the template compiler will translate templates into expected
output.
PR Close#21374
We used to have a separate `directive` instruction for instantiating
directives. However, such an instruction requires that directives
are created in the correct order, which would require that template
compiler would have knowledge of all dependent directives. This
would break template compilation locality principle.
This change only changes the APIs to expected form but does
not change the semantics. The semantics will need to be corrected
in subsequent commits. The semantic change needed is to
resolve the directive instantiation error at runtime based on
injection dependencies.
PR Close#21374
This PR fixes a circular dependency among those files in Renderer3:
`query` -> `di` -> `instructions` -> `query` -> ...
Looking at the above dependencies the `di` -> `instructions` import is
a problematic one. Previously `di` had an import from `instructions`
since we can known about "current node" only in `instructions`
(and we need "current node" to create node injector instances).
This commit refactors the code in the way that functions in the
`di` file don't depend on any info stored module-global variables
in `instructions`.
PR Close#20855
Structural directives can now specify a type guard that describes
what types can be inferred for an input expression inside the
directive's template.
NgIf was modified to declare an input guard on ngIf.
After this change, `fullTemplateTypeCheck` will infer that
usage of `ngIf` expression inside it's template is truthy.
For example, if a component has a property `person?: Person`
and a template of `<div *ngIf="person"> {{person.name}} </div>`
the compiler will no longer report that `person` might be null or
undefined.
The template compiler will generate code similar to,
```
if (NgIf.ngIfTypeGuard(instance.person)) {
instance.person.name
}
```
to validate the template's use of the interpolation expression.
Calling the type guard in this fashion allows TypeScript to infer
that `person` is non-null.
Fixes: #19756?
PR Close#20702
Add enough BUILD files to make it possible to
`bazel build packages/core/test`
Also re-format BUILD.bazel files with Buildifier.
Add a CI lint check that they stay formatted.
PR Close#20768
Throwing an exception in a lifecycle event will delay but not
prevent an Init method, such as `ngOnInit`, `ngAfterContentInit`,
or `ngAfterViewInit`, from being called. Also, calling `detectChanges()`
in a way that causes duplicate change detection (such as a
child component causing a parent to call `detectChanges()` on its
own `ChangeDetectorRef`, will no longer prevent change `ngOnInit`,
`ngAfterContentInit` and `ngAfterViewInit` from being called.
With this change lifecycle methods are still not guarenteed to be
called but the Init methods will be called if at least one change
detection pass on its view is completed.
Fixes: #17035
PR Close#20258
This allows to overwrite templates for JIT and AOT components alike.
In contrast to `TestBed.overrideTemplate`, the template is compiled
in the context of the testing module, allowing to use other testing
directives.
Closes#19815
Before, as soon as a user called `TestBed.overrideProvider` for a provider
of a `NgModule` that was imported via `TestBed.configureTestingModule`,
that `NgModule` became lazy.
This commit changes this behavior to keep the `NgModule` eager,
with or without a call to `TestBed.overrideProvider`.
PR Close#19624
Each node now has two index: nodeIndex and checkIndex.
nodeIndex is the index in both the view definition and the view data.
checkIndex is the index in in the update function (update directives and update
renderer).
While nodeIndex and checkIndex have the same value for now, having both of them
will allow changing the structure of view definition after compilation (ie for
runtime translations).
This is needed as:
- closure declares globals itself for minified names, which sometimes clobber our `ng` global
- we can't declare a closure extern as the namespace `ng` is already used within Google for typings for angularJS (via `goog.provide('ng....')`).
The new expression lowering lowers everything after `useValue` / `useFactory`
into a separate exported variable. If the value was a `forwardRef`, this
was passed to the runtime and resulted in errors.
This change unwraps `forwardRef`s during runtime again.
Note: we can’t unwrap the `forwardRef` into an exported variable
during compile time, as this would defeat the purpose of the
`forwardRef` in referring to something that can’t be referred to
at this position.
- optimize the way node flags are propagated in `viewDef()`,
- fix `elementDef()` signature to make `namespaceAndName` nullable,
- move render parent computation with the parent computation
PR Close#19272
Jason Aden
Kara Erickson
Marc Laval
Victor Berchet
Pawel Kozlowski
JoostK
Alec
Martin Probst
Alex Rickabaugh
Olivier Combe
Miško Hevery
Lucas Sloan
Matias Niemelä
swseverance
Vikram Subramanian
Igor Minar
Rafael
Pete Bacon Darwin
paulmojicatech
Aslan Vatsaev
Veres Lajos
Chuck Jazdzewski
Michael Giambalvo
Trotyl
Oussama Ben Brahim
Kara
Emilio
Martin Sikora
JiaLi.Passion
David-Emmanuel Divernois
harunurhan
Xander Garbett
Benjamin Ingberg
Brian Douglas
Alex Eagle
Yuan Gao
Juri Strumpflohner
George Kalpakas
Martin Hobert
Fabian Wiles
Tobias Bosch