This commit implements the first phase of standalone components in the Angular
compiler. This mainly includes the scoping rules for standalone components
(`@Component({imports})`).
Significant functionality from the design is _not_ implemented by this PR,
including:
* imports of standalone components into NgModules.
* the provider aspect of standalone components
Future commits will address these issues, as we proceed with the design of
this feature.
PR Close#44812
Refs http://b/214103351.
This happens if a user writes `<span i18n>Message</span>`. This is accepted as an internationalized message, but without a description. JSCompiler will throw an error in this situation because descriptions are generally required. Now, the Angular compiler will generate a suppression annotation so JSCompiler allows the syntax. This will ease an internal migration to JSCompiler-based i18n.
PR Close#44787
This commit removes the leftover `Identifiers` class that was used in the
ViewEngine compiler. The remaining usages of the `inlineInterpolate` and
`interpolate` instructions were refactored to make use of an
`InterpolationExpression` output expression to capture the argument list of an
interpolation expression. An attempt was made to refactor this further by
converting to the desired interpolation instruction immediately, but some
downstream consumers are designed in a way where the argument list itself is
needed, e.g. as other arguments need to be prepended/appended.
PR Close#44676
An `ng-template` with an inline template (i.e. has a structural
directive) would previously not get an `undefined` `tagName` because the
logic assumed the element would be `t.Element` or `t.Content` and read
the tag name from the `name` property. For a `t.Template`, this exists
instead on the `t.tagName`. The final result would be an `tagName` of `undefined`
for the parent `t.Template`, causing failures in the indexer downstream.
This `undefined` value is actually expected in the renderer code, even
though the type does not specify this possibility. This change updates
the type of `tagName` to be `string|null` and explicitly handles the
case where there is a structural directive on an `ng-template`. You can
see how the two are differentiated in the compliance code that was
modified in this commit.
PR Close#44788
The directive matching pass that happens during template compilation is
redundant, since directive matching has already happened during the resolution
phase of ngtsc and only matching declarables are provided to the template
compiler. In JIT mode the declarables only become available after the primary
template compilation has completed, so there is no need to perform directive
matching in both JIT and AOT mode.
PR Close#44731
In `language-service`, the `checker.getDirectiveMetadata` doesn't return the animations meta of the `Component`.
but it's useful for animation completion.
PR Close#44630
This commit improves the null-safety of the ng-content selector and
updates a comment that turned out to be slightly inaccurate.
Closes#38407
PR Close#44411
This commit finishes the removal of View Engine from the codebase, deleting
those pieces of @angular/compiler which were only used for VE.
Co-Authored-By: JoostK <joost.koehoorn@gmail.com>
PR Close#44368
This commit removes the View Engine runtime. Itself, this change is
relatively straightforward, but it represents the final step in a multi-year
journey. It's only possible due to the hard work of many current and former
team members and collaborators, who are too numerous to list here.
Co-authored-by: Alan Agius <alan.agius4@gmail.com>
Co-authored-by: Andrew Kushnir <akushnir@google.com>
Co-authored-by: Andrew Scott <atscott01@gmail.com>
Co-authored-by: Andrew Seguin <andrewjs@google.com>
Co-authored-by: Cédric Exbrayat <cedric@ninja-squad.com>
Co-authored-by: Charles Lyding <19598772+clydin@users.noreply.github.com>
Co-authored-by: Dave Shevitz <dshevitz@google.com>
Co-authored-by: Doug Parker <dgp1130@users.noreply.github.com>
Co-authored-by: Dylan Hunn <dylhunn@gmail.com>
Co-authored-by: Emma Twersky <emmatwersky@google.com>
Co-authored-by: George Kalpakas <kalpakas.g@gmail.com>
Co-authored-by: Igor Minar <iminar@google.com>
Co-authored-by: Jeremy Elbourn <jelbourn@google.com>
Co-authored-by: Jessica Janiuk <jessicajaniuk@google.com>
Co-authored-by: JiaLiPassion <JiaLi.Passion@gmail.com>
Co-authored-by: Joey Perrott <josephperrott@gmail.com>
Co-authored-by: Joost Koehoorn <joost.koehoorn@gmail.com>
Co-authored-by: Kristiyan Kostadinov <crisbeto@abv.bg>
Co-authored-by: Madleina Scheidegger <mscheid@google.com>
Co-authored-by: Mark Thompson <2554588+MarkTechson@users.noreply.github.com>
Co-authored-by: Minko Gechev <mgechev@gmail.com>
Co-authored-by: Paul Gschwendtner <paulgschwendtner@gmail.com>
Co-authored-by: Pawel Kozlowski <pkozlowski.opensource@gmail.com>
Co-authored-by: Pete Bacon Darwin <pete@bacondarwin.com>
Co-authored-by: Wagner Maciel <wagnermaciel@google.com>
Co-authored-by: Zach Arend <zachzach@google.com>
PR Close#43884
When a partially compiled component or directive is "linked" in JIT mode, the body
of its declaration is evaluated by the JavaScript runtime. If a class is referenced
in a query (e.g. `ViewQuery` or `ContentQuery`) but its definition is later in the
file, then the reference must be wrapped in a `forwardRef()` call.
Previously, query predicates were not wrapped correctly in partial declarations
causing the code to crash at runtime. In AOT mode, this code is never evaluated
but instead transformed as part of the build, so this bug did not become apparent
until Angular Material started running JIT mode tests on its distributable output.
This change fixes this problem by noting when queries are wrapped in `forwardRef()`
calls and ensuring that this gets passed through to partial compilation declarations
and then suitably stripped during linking.
See https://github.com/angular/components/pull/23882 and https://github.com/angular/components/issues/23907
PR Close#44113
This reverts commit bba0a87055.
The reason for rollback: this change is breaking some targets in Google's codebase when there is no attribute value is displayed (attr.aria-label) when translated.
PR Close#43882
While fully dynamic bound properties (and attributes) cannot be marked for localization, properties that only contain interpolation can.
This commit ensure that attribute bindings that only contain interpolation can also be marked for localization.
Closes#43260
PR Close#43815
When extracting i18n messages from templates, ICU messages are split out from the
message that contains them. This can make it difficult in the translation files to match up
the two messages, especially if the ICU is reused in multiple placeholders.
This commit builds on top of the previous one to expose the message ID of ICU messages
from the ICU placeholders as additional metadata in the `$localize` tagged strings.
Now the metablock following any placeholder can also contain the associated ID
delimited from the placeholder name by `@@`.
Fixes#17506
PR Close#43534
Currently the compiler has three different classes to represent a "call to something":
1. `MethodCall` - `foo.bar()`
2. `SafeMethodCall` - `foo?.bar()`.
3. `FunctionCall` - Any calls that don't fit into the first two classes. E.g. `foo.bar()()`.
There are a few problems with this approach:
1. It is inconistent with the TypeScript AST which only has one node: `CallExpression`.
2. It means that we have to maintain more code, because the various parts of the compiler need to know about three node types.
3. It doesn't allow us to easily implement some new JS features like safe calls (e.g. `foo.bar?.())`).
These changes rework the compiler so that it produces only one node: `Call`. The new node behaves similarly to the TypeScript `CallExpression` whose `receiver` can be any expression.
There was a similar situation in the output AST where we had an `InvokeMethodExpression` and `InvokeFunctionExpression`. I've combined both of them into `InvokeFunctionExpression`.
PR Close#42882
Previously, the way templates were tokenized meant that we lost information
about the location of interpolations if the template contained encoded HTML
entities. This meant that the mapping back to the source interpolated strings
could be offset incorrectly.
Also, the source-span assigned to an i18n message did not include leading
whitespace. This confused the output source-mappings so that the first text
nodes of the message stopped at the first non-whitespace character.
This commit makes use of the previous refactorings, where more fine grain
information was provided in text tokens, to enable the parser to identify
the location of the interpolations in the original source more accurately.
Fixes#41034
PR Close#43132
Previously, the way templates were tokenized meant that we lost information
about the location of interpolations if the template contained encoded HTML
entities. This meant that the mapping back to the source interpolated strings
could be offset incorrectly.
Also, the source-span assigned to an i18n message did not include leading
whitespace. This confused the output source-mappings so that the first text
nodes of the message stopped at the first non-whitespace character.
This commit makes use of the previous refactorings, where more fine grain
information was provided in text tokens, to enable the parser to identify
the location of the interpolations in the original source more accurately.
Fixes#41034
PR Close#42062
Currently unless a listener inside of an embedded view tries to reference something from the parent view, or if the reference is a local ref, we don't generate the view restoration instructions and we allow for the value to be picked up from the context object in the function parameters. The problem is that the listener is only run during creation mode and the context object may have been swapped out afterwards.
These changes fix the issue by always generating the view restoration instructions for listeners inside templates.
Fixes#42698.
PR Close#42755
If an implcit receiver is accessed in a listener inside of an `ng-template`, we generate some extra code in order to ensure that we're assigning to the correct object. The problem is that the logic wasn't covering keyed writes which caused it to write to the wrong object and throw an assertion error at runtime.
These changes expand the logic to cover keyed writes.
Fixes#41267.
PR Close#42603
We have a check that determines whether to generate property binding instructions for an `ng-template`. The check looks at whether the tag name is exactly `ng-template`, but the problem is that if the tag is placed in a non-HTML namespace (e.g. `svg`), the tag name will actually be `:namespace:ng-template` and the check will fail.
These changes resolve the issue by looking at the tag name without the namespace.
Fixes#41308.
PR Close#41669
Currently if a component defines a template inline, but not through a
string literal, the partial compilation references the template expression
as is. This is problematic because the component declaration can no longer
be processed by the linker later as there is no static interpretation. e.g.
```js
const myTemplate = `...`;
TestCmp.ɵcmp = i0.ɵɵngDeclareComponent({
version: "0.0.0-PLACEHOLDER",
type: TestCmp,
selector: "test-cmp",
ngImport: i0,
template: myTemplate,
isInline: true
});
```
To fix this, we use the the resolved template in such cases so that
the linker can process the template/component declaration as expected.
PR Close#41583
With the introduction of the partial compilation, the Angular compiler's
existing `parseTemplate` method has been extended to pass through multiple
properties purely in favor of the partial compilation.
e.g. the `parseTemplate` function now accepts an "option" called `isInline`.
This option is just passed through and returned as part of the `ParsedTemplate`.
This is not ideal because the `parseTemplate` function doesn't care
whether the specified template was inline or not. This commit cleans
up the `parseTemplate` compiler function so that nothing needed only
for the partial compilation is added to it.
We introduce a new struct for additional template information that
is specific to the generation of the `declareComponent` function. With
that change, we can simplify the component decorator handler and keep
logic more local.
PR Close#41583
Previously, it was not possible to block a partial-linker from trying to
process a declaration that was defined in a newer version of Angular than
that of the partial-linker. For example, if a partial-linker was published as
part of version 12.0.0, there was no way for a partially-compiled declaration
compiled via version 13.0.0 to tell the 12.0.0 linker that it would be invalid
to attempt to process it.
This commit adds a new `minVersion` property to partial-declarations, which is
interpreted as the "minimum partial-linker version" that can process this
declaration. When selecting a partial-linker for such a declaration, the known
linker version ranges are checked to find the most recent linker whose version
range has an overlap with the interpreted declaration range.
This approach allows us to set a minimum version for a declaration, which
can inform an old partial-linker that will it not be able to accurately
process the declaration.
Note that any pre-release part to versions are ignored in this selection
process.
The file-linker can be configured, via the `unknownDeclarationVersionHandling`
property of `LinkerOptions`, to handle such a situation in one of three ways:
- `error` - the version mismatch is a fatal error
- `warn` - a warning is sent to the logger but the most recent partial-linker
will attempt to process the declaration anyway.
- `ignore` - the most recent partial-linker will, silently, attempt to process
the declaration.
The default is to throw an error.
Closes#41497
PR Close#41578
This commit refactors the generated code for class metadata in partial
compilation mode. Instead of emitting class metadata into a top-level
`ɵsetClassMetadata` call guarded by `ngDevMode` flags, the class
metadata is now declared using a top-level `ɵɵngDeclareClassMetadata`
call.
PR Close#41200
This commit changes the partial compilation so that it outputs declarations
rather than definitions for injectables.
The JIT compiler and the linker are updated to be able to handle these
new declarations.
PR Close#41316
Currently we normalize all CSS property names in the `StylingBuilder` which breaks custom properties, because they're case-sensitive. These changes add a check so that custom properties aren't normalized.
Fixes#41364.
PR Close#41380
This enumeration will now start to appear in publicly facing code,
as part of declarations, so we remove the R3 to make it less specific
to the internal name for the Ivy renderer/compiler.
PR Close#41231
Now that other values were removed from `R3ResolvedDependencyType`,
its meaning can now be inferred from the other properties in the
`R3DeclareDependencyMetadata` type. This commit removes this enum
and updates the code to work without it.
PR Close#41231
This instruction was created to work around a problem with injecting a
`ChangeDetectorRef` into a pipe. See #31438. This fix required special
metadata for when the thing being injected was a `ChangeDetectorRef`.
Now this is handled by adding a flag `InjectorFlags.ForPipe` to the
`ɵɵdirectiveInject()` call, which avoids the need to special test_cases
`ChangeDetectorRef` in the generated code.
PR Close#41231
This commit changes the partial compilation so that it outputs declaration
calls rather than compiled factory functions.
The JIT compiler and the linker are updated to be able to handle these
new declarations.
PR Close#41231
Adds a `collectCommentNodes` option on `ParseTemplateOptions` which will cause the returned `ParsedTemplate` to include an array of all html comments found in the template.
PR Close#41251
The `ɵɵInjectorDef` interface is internal and should not be published publicly
as part of libraries. This commit updates the compiler to render an opaque
type, `ɵɵInjectorDeclaration`, for this instead, which appears in the typings
for compiled libraries.
PR Close#41119
Th `ɵɵFactoryDef` type will appear in published libraries, via their typings
files, to describe what type dependencies a DI factory has. The parameters
on this type are used by tooling such as the Language Service to understand
the DI dependencies of the class being created by the factory.
This commit moves the type to the `public_definitions.ts` file alongside
the other types that have a similar role, and it renames it to `ɵɵFactoryDeclaration`
to align it with the other declaration types such as `ɵɵDirectiveDeclaration`
and so on.
PR Close#41119
These types are only used in the generated typings files to provide
information to the Angular compiler in order that it can compile code
in downstream libraries and applications.
This commit aliases these types to `unknown` to avoid exposing the
previous alias types such as `ɵɵDirectiveDef`, which are internal to
the compiler.
PR Close#41119
Previously presence of both [class] and [className] bindings on an element was treated as compiler error (implemented in 6f203c9575). Later, the situation was improved to actually allow both bindings to co-exist (see a153b61098), however the compiler check was not removed completely. The only situation where the error is thrown at this moment is when static (but with interpolation) and bound `class` attributes are present on an element, for ex.:
```
<div class="{{ one }}" [class]="'two'"></div>
```
In the current situation the error is acually misleading (as it refers to `[className]`).
This commit removes the mentioned compiler check as obsolete and makes the `class` and `style` attribute processing logically the same (the last occurrence is used to compute the value).
PR Close#41254
The partial declaration of a component includes the list of directives
that are used in its template, including some metadata of the directive
which can be used during actual compilation of the component. Used
components are currently part of this list, as components are also
directives. This commit splits the used components into a dedicate
property in the partial declaration, which allows for template
compilation to optimize the generated code for components.
PR Close#41104
