Angular 16.1 introduced the input transform feature, requiring the partial compilation output to be extended
with a reference to the input transform function. This has resulted in a subtle breaking change, where older
versions of the Angular linker can no longer consume libraries that have started to use this feature.
We do try to support using a 16.1 library from an Angular 16.0 application, but if a library actually
adopts a new feature then this is no longer possible. In such cases, it is desirable to report a message
telling the user that their version of the Angular compiler is too old, as determined by the `"minVersion"`
property that is present in each partial declaration. This version would still indicate that the declaration
required at least Angular 14.0 to be compiled, but this is not accurate once input transforms are being
used. Consequently, this error would not be reported, causing a less informative error once the input transform
was being observed.
Fixes#51411
PR Close#51413
Updates the template pipeline's temporary variables phase to reuse
temporary variables within an expression. The algorithm implemented here
reuses variables more aggressively than TemplateDefinitionBuilder. This
change in behavior is acceptable, as it is unlikely to cause any
failures, and implementing the exact behavior observed in
TemplateDefinitionBuilder would be difficult.
PR Close#51100
Updates the TemplateDefinitionBuilder class to generate the `defer` instruction for `{#defer}` blocks. Also generates dependency function that would be invoked at runtime (with dynamic imports inside).
PR Close#51162
This commit brings the logic to calculate teh set of dependencies for each defer block. For each dependency we also identify whether it can be defer-loaded or not.
PR Close#51162
This commit updates the logic of the TemplateBinder and DirectiveBinder classes to recognize defer blocks. The logic is updated to prevent Directive and Pipe matching inside the defer block. Instead, the scope for those blocks would be calculated separately.
PR Close#51162
Adds the `ɵsetEnabledBlockTypes` utility that can be used when writing JIT tests using `defer` blocks. Intended usage:
```ts
import {ɵsetEnabledBlockTypes as setEnabledBlockTypes} from '@angular/compiler/src/jit_compiler_facade';
describe('deferred tests', () => {
beforeEach(() => setEnabledBlockTypes(['defer']));
afterEach(() => setEnabledBlockTypes([]));
it('should work', () => {
// test goes here
});
});
```
PR Close#51183
Change sourceSpan for Comment nodes to cover the whole comment
instead of just the opening token.
The primary motivation for this is the interaction between ESLint and
`@angular-eslint`. ESLint can detect unused `eslint-disable` directives
in comments and automatically remove them when running with `--fix`.
This is based on ranges computed from AST spans, and as a result
does not work inside Angular templates - right now all comments
claim to be 4 characters long so only the opening `<!--` is removed.
PR Close#50855
Host property bindings beginning with `attr.` should have `Attribute` binding kind, and result in an `attribute` instruction.
This should really be handled in the parser in the future.
PR Close#51188
Templates may contain special `svg` and `math` elements, as well as logical descendants of those elements (e.g. `svg` may contain `g`). These will be parsed with a special colon-prefixed *namespace identifier*, such as `:svg:svg`, or `:svg:g`, or `:math:infinity`.
The template pipeline now considers these namespace prefixes, and stores them specially on the Element and Template data structures, ultimately generating the appropriate runtime instructions to change namespaces when needed.
PR Close#51188
When a container-like element has the `ngNonBindable` special attribute, bindings are disabled for it and its descendants. This requires emitting the `disableBindings` and `enableBindings` instructions when nested content exists.
PR Close#51188
Previously we refactored the compilation to use the concepts of "jobs" and "units." However, old type aliases were provided to avoid changing all call-sites in bulk. Here, those aliases are deleted, and call sited updated:
1. `ComponentCompilation` becomes `ComponentCompilationJob`.
2. `ViewCompilation` becomes `ViewCompilationUnit`.
PR Close#50899
Interestingly, host bindings are parsed quite differently from template functions. For example, bindings such as `[style.foo]: 3px` would be parsed into a value, unit, and type when bound to a template, but will not be parsed as such when used in a host binding.
In this commit, we remedy this shortcoming by adding support for bindings in host binding functions to the template pipeline. In particular, we create a phase to process these bindings, and transform them into the correct output binding kind.
Additionally, we fix some other minor bugs and omissions.
Finally, we enable compilation of host bindings with the template pipeline, which requires us to turn off a number of failing tests.
PR Close#50899
Alter the compiler code to ingest and process host bindings, using the newly updated compilation passes.
This is currently switched off in the outer compiler layer, but lays the foundation for actually generating the host binding functions using template pipeline.
PR Close#50899
Today, bindings on templates are ingested in highly distinct ways, depending on the parsed binding kind, as well as special cases for `style` and `class`. This makes it very difficult to also ingest them for host bindings without duplicating all this subtle logic.
To solve this, we introduce two major related refactors:
1. Move all processing of attributes into phases. This dramatically reduces the amount of code in `ingest.ts`, which is now only responsible for ingesting an abstract `BindingOp`. The later phases replace each `BindingOp` with more specific ops for each binding kind. For example, `binding_specialization.ts` transforms each abstract `BindingOp` into a concrete `PropertyOp`, `AttributeOp`, etc. Likewise, `style_binding_specialization.ts` performs special-case transformations for style and class bindings. This approach has the additional advantage of separating the creation of attribute and property bindings from other special cases.
2. Eliminate all interpolation ops. Instead, allow the expression inside of an op to be of a new `Interpolation` type. The reify code will then emit the appropriate instruction variant (interpolated or unary).
3. Separate some concerns that were previously mixed in, such as empty bindings and listeners on templates.
These refactors cause major downstream code changes across the system, especially to attribute extraction and variable counting.
PR Close#50899
Modify most of the remaining necessary phases to accept generic `CompilationJobs`. This includes `phasePureLiteralStructures`, `phaseNullishCoalescing`, `phaseExpandSafeReads`, `phaseVariableOptimization`, `phaseNaming`, and `phasePureFunctionExtraction`.
PR Close#50899
Refactor `compilation.ts` by introducing two new concepts:
1. A compilation unit, which has create and update ops. Compilations of individual views are compilation units, as are individual host bindings.
2. Aa compilation job, which has several compilation units. For example, a whole component is a compilation job, because it can have many view compilation units. A host binding compilation is a job in addition to a unit, because each host binding unit is always a singleton.
Then, we begin modifying phases to accept general compilation jobs instead of component compilations specifically, which will allow us to run them on host bindings. In particular, we update the following phases: `phaseReify`, and `phaseChaining`.
PR Close#50899
Add a compatibility setting to the component compilation. Accordingly, remove all the custom compatibility flags passed to each phase, and use the main setting instead.
PR Close#50899
Begin producing source maps for the template pipeline, for a couple fundamental kinds of instructions, including elements, templates, properties, text, and interpolations.
PR Close#50899
Previously, `$event` was interpreted as a lexical read on the enclosing context. Now, a new pass converts such reads into simple output AST reads of `$event`, so they are not processed by the context resolution or naming phases. Additionally, the same pass sets a field on the enclosing listener op, so that the reify phase does not have to search for reads of `$event`.
PR Close#50899
`$any(...)` casts should be dropped, except when they are an explicit call on `this.$any(...)`. Fix a bug in which we were transforming `ThisReceiver` into an implicit receiver.
PR Close#50899
Fixes that using braces in the block parameters would result in incorrect tokens being produced. Currently we don't have any blocks that allow object literal parameters, but it may come up in the future.
PR Close#51143
This commit updates the output AST (and related visitors) to support dynamic imports. This functionality will be used later to generate the output for defer blocks.
PR Close#51087
Adds the logic to create `defer`-specific AST nodes from the generic HTML `BlockGroup` and `Block`. The logic for parsing the triggers will be in the next commit.
PR Close#51050
Adds attribute and attribute interpolation bindings to the ordering
algorithm that decides the order of various property, style, and
attribute ops.
PR Close#50805
Ensures that all property and attribute ops are ordered consistently
regardless of the order they appear in the template. This ensures
correct precedence (e.g. `[style.color]="'#000'"` awlays wins out over
`[style]="{color: '#fff'}"`)
PR Close#50805
Single argument class and style interpolations (e.g.
`style.color="{{color}"`) should be converted to standard class and
property operations with no interpolation (e.g. `[style.color]="color")
PR Close#50805
Currently, a listener on an element containing a dash, will result in
runtime errors because the function name will be generated using a dash.
e.g.
```
function MyApp_Template_some-comp_bla_0() {}
```
throwing with a syntax error due to the dash. We fix this by re-using
the sanitize identifier function from the current template definition
builder.
PR Close#50946
⚠️Disclaimer⚠️ this PR implements syntax that is still in an open RFC. It will be adjusted once the RFC is closed.
These changes implement the `BlockGroup` and `Block` AST nodes that will then be used to generate instructions based on the new syntax. A `BlockGroup` is a container for `Block` instances. The first block of a block is always implicit and required while any subsequent blocks are optional.
PR Close#50953
⚠️Disclaimer⚠️ this PR implements syntax that is still in an open RFC. It will be adjusted once the RFC is closed.
These changes extend the lexer to recognize the concepts of a block group (`{#foo paramA; paramB}{/foo}`) and a block (`{:foo paramA; paramB;}`) which will be useful later on for the control flow and defer proposals. Block groups can be used anywhere and require a closing tag while block can only be used inside of a block.
The idea is that in the next PRs the markup AST will be expanded to have some more specialized node like `ConditionalBlock` or `DeferBlock` which will then be turned into instructions.
PR Close#50895
This commit adds the ability to generate attribute instructions as a result of property bindings such as `[attr.foo]='bar'` or `attr.foo='{{bar}}'`. "Singleton" interpolations, such as the previous example, will also be transformed into a simple `attribute` instruction.
PR Close#50818
JoostK