Accessing `pendingTasks.whenAllTasksComplete` too early causes the `InitialRenderPendingTasks` to return a resolved promise too early. This commit changes the way we access `whenAllTasksComplete` to only happen when the application is stabilized.
PR Close#49784
Current in the `InitialRenderPendingTasks` when the `collection` size is 0 a new promise is created a the status is changed to completed. This causes the promise that is created during the class initialization phase to never be resolved which causes SSR to hang indefinitely.
PR Close#49784
The compiler currently does not check to make sure that directives in
the host bindings are exported. These directives are part of the public
API of the component so they do have to be.
PR Close#49527
Previously, since the `HttpXhrBackend` is a singleton, the macrotask was created and completed only for the initial request since it was stored as in property in the class instance. This commit replaces this logic to create a macro task for every XHR request.
Closes#49730
PR Close#49776
This change makes is possible to use async functions
(ones returning a promise) as effect run functions.
To make it possible, the signature of the effect function
changed: effect cleanup function is registered now
(using a dedicated callback passed to the effect creation)
instead of being returned from the effect function.
PR Close#49783
This commit updates the logic that adds the "ng-server-context" attribute to the root elements to also include information about SSR feature enabled got an application.
PR Close#49773
Fixes that the compiler was matching directives based on `attr` bindings which doesn't correspond to the runtime behavior. This wasn't a problem until now because the matched directives would basically be a noop, but they can cause issues with required inputs.
PR Close#49713
This commit adds a Bazel flag which controls a constant in the compiler code.
When this flag (`--//packages/compiler:use_template_pipeline`) is specified, the
prototype template pipeline code is enabled.
This is not used in any production workflows and only works in the local Angular
repository. It will be used to develop the template pipeline against the
existing compliance tests.
PR Close#48580
This commit adds `transformTemplate` and `emitTemplateFn()` to the template
pipeline. These operations respectively apply all template compilation phases
in the right order, and then generate a final template function AST from the
template IR.
PR Close#48580
This commit introduces `phaseReify()` which performs "reification" of IR
operations. This converts previously semantic operations (e.g. `ir.Element`)
into generated instruction calls (`element(...)`). At the end of reification,
all operations have been converted into `ir.StatementOp`s, and the IR AST should
be suitable for emitting as generated code.
Note that after reification, more transformations may still be applied. For
example, instruction chaining will be performed post-reification, since it
depends on the exact selected instructions for each operation.
PR Close#48580
This commit introduces a new pipeline phase `phaseNaming()`, which tags
operations that generate function and variable declarations with generated names
to use when emitting those operations.
Currently this phase is using placeholder names. Eventually, we will want to
align its output with the current `TemplateDefinitionBuilder` names, in order to
pass the existing tests.
PR Close#48580
When executing the template update pass, the runtime keeps an internal
declaration slot pointer for which declaration (element, template, etc) is
the current subject of any binding or interpolation instructions. In between
update operations which reference different declarations, this pointer needs to
be adjusted, which is the job of the `advance()` instruction.
This commit introduces `phaseGenerateAdvance()` which inserts `advance()`
operations wherever necessary to satisfy this runtime requirement.
PR Close#48580
Operations and expressions in component update blocks can make use of variable
slots for storing data between executions (for example, the previous values of
expressions to use in change detection comparisons). The runtime must be told
how many variable slots to allocate for each view in a component declaration.
This commit adds a `phaseVarCounting()` phase to count the number of variables
used in different operations and expressions in a view. It makes uses of a new
marker trait `ConsumesVarsTrait` to determine which operations & expressions to
consider.
PR Close#48580
Every declaration a template is stored in a data slot in the runtime. The
indices of these slots are passed to the declaration instructions in the
creation mode. In the update mode, several instructions (like `reference()` for
local references) also use the slot indices to reference declared items.
This commit introduces `phaseSlotAllocation()` to the template pipeline, which
allocates slots for declarations which need them, and propagates those slot
indices to other instructions which need to reference declared items via their
slot indices. To perform this association, the `XrefId` of the declared items
is used to link declarations with usages.
Slot allocation is abstracted from operations by the way of a new concept in the
pipeline: traits. A trait is a "mixin" on an operation, expression, or both that
allows phases to process any operation/expression which implements the trait
without needing specific logic for each concrete implementing type. Two traits
are introduced to support slot allocation: the `ConsumesSlotOpTrait` for
declarations which require a slot to be allocated, and the
`UsesSlotIndexExprTrait` for expressions which reference a declaration by its
slot index.
PR Close#48580
This commit serializes the attributes on element-like structures in the template
and converts them to constant arrays, which it lifts into the `consts` array for
the entire component compilation.
PR Close#48580
As an optimization, the runtime provides an `element()` instruction to use in
place of `elementStart()` and `elementEnd()` when there are no instructions
between them. This commit merges `ElementStart` and `ElementEnd` IR operations
into `Element` operations in that special case.
PR Close#48580
Local references declared on elements need to be represented in element/template
instructions via an index into the `consts` array. This commit adds the
`phaseLocalRefs()` phase to lift local reference declarations into the `consts`
array accordingly.
PR Close#48580
`phaseResolveContexts()` resolves `ir.ContextExpr` expressions within views.
Each `ir.ContextExpr` represents a reference to a particular view context. For
the context of the view being compiled, this is available in the view's template
function `ctx` parameter. For parent views, this is available in context
variables which were added previously.
`phaseResolveContexts()` replaces these `ir.ContextExpr` operations with
resolved references to the requested views.
PR Close#48580
This commit introduces `phaseResolveNames()` to the template pipeline. This
phase processes any `ir.LexicalReadExpr`s, which represent unresolved
identifiers from the user's expressions in the template, and attempts to match
them to concepts in the lexical scope of the template (such as local refs) or
to a property read of a component or embedded view context.
PR Close#48580
This commit implements the first "phase" of the template pipeline. Phases are
individual steps in compilation that perform a transformation of the IR in order
to move closer to generating runtime code for the template.
This first phase is `phaseGenerateVariables()`. This phase introduces variable
definition operations into the IR to define variables in each view. These
variables either represent internal operations (saving/restoring the view
context for listeners, for example) or variables created from user-defined names
such as local references or template context properties.
Every view has all possibly-referenced variables generated, regardless of
whether they're actually referenced by other operations. A future phase will
optimize the variables in each view, inlining those which are only read once and
removing those which are not referenced at all.
PR Close#48580
This commit implements `ingest()`, which converts a parsed template AST into
template pipeline IR. This is the first step of template compilation.
PR Close#48580
This commit adds the IR operations and expressions required to "ingest" a
template into the template pipeline. They form the starting point for template
compilation.
Ingestion is implemented in a following commit.
PR Close#48580
This commit adds support for custom derived `o.Expression` types in the template
pipeline. A base class is added with one current implementor
(`ir.LexicalReadExpr`). `ir.Expression`s encode semantic operations within
expression ASTs of IR operations.
PR Close#48580
This commit introduces the "template pipeline", a new compilation flow for
template compilation. This new flow is intended to eventually replace the
`TemplateDefinitionBuilder`. For now, it's being implemented in parallel with
the existing system with the goal of eventually passing all of the existing
compliance tests.
The new pipeline is based on an "intermediate representation" of a template -
operations which semantically encode what needs to happen at runtime to render
and change-detect the template. Using an IR allows for different concerns of
template compilation to be processed independently, which solves the biggest
problem with `TemplateDefinitionBuilder` today (the lack of separation of
concerns).
This commit introduces the IR concept of an operation and related typings, as
well as the structures used to represent templates and views during compilation.
Future commits will expand on this foundation as work on the pipeline proceeds.
PR Close#48580
Currently we have multiple integration apps which are instrumented with the payload size checks. In addition to that, there is a separate CI job that performs similar checks. The checks in CI job are redundant, thus this commit disables a separate CI job.
PR Close#49788
The cache state is only used only the first server request. Restarting the server uses the cache on first request.
Subsequent requests skip the cache because the value is mutated.
This change ensures a new cache state is returned on every request.
PR Close#49749
* Adds a small script to conveniently re-generate lock files for
integration tests.
* Updates the `.gitignore` for integration tests to ignore node
modules. Some tests do not have a `.gitignore` (like the CLI
boilerplate tests).
PR Close#49787
This reverts commit 2279f4d4620eba083a9832ed096890b69a25ec42.
Reverting that commit based off PR feedback that this change should only affect the parsing of sergments and node encoding of the url
PR Close#47332
fix router segment name parsing to allow segements to container an unscaped = character. Currently if you have a url like /some-site/folder=/some-file then then middle segment "folder=" will stop parsing at the = sign and register that part of the path as just "folder"
Fixes#21381
PR Close#47332
This commit updates the minimum supported Node version across packages from 16.13.0 -> 16.14.0 to ensure compatibility with dependencies.
PR Close#49771
Currently, a change in an error guide triggers a review for the `public-api` group (requests 3 reviewers and al least 2 must approve). This is overly aggressive and we can relax this by moving the guides under `fw-core` and extended diagnistics under `fw-compiler`. In this case 1 reviewer would be requested.
PR Close#49770
This commit updates the logic to avoid enabling hydration in case server response doesn't contain hydration-related info serialized. It can happen when `provideClientHydration()` call only happens on the client, but not on the server.
PR Close#49750
This commit updates the logic to detect a situation when hydration support was enabled only on the client. If that happens, Angular produces a warning in a console with a link to the error guide.
PR Close#49743
In archive mode the link to the current doc will now point to same page.
If the page doesn't exist anymore, it will show a contextualized warning message.
See #46850
PR Close#49063
New `ng new` apps no longer generate `enableProdMode` calls when an app is created. The prod mode is enabled via CLI flags (and configuration in the `angular.json` if needed).
PR Close#49723
The Domino DOM emulation library doesn't support shadow DOM. For such components we can not guarantee that client and server representations would match perfectly. To avoid hydration mismatch errors, such components are opted out of hydration.
PR Close#49722
