It might happen that the lifecycle scope represented by DestroyRef becomes
invalid before an onDestroy hook is registered (ex. injector or component
instance got destroyed). In such cases registration of the onDestroy hooks
should no longer be possible.
Fixes#49658
PR Close#49804
The new asReadonly method on the WritableSignal interface makes
it possible to create readonly instance of a writable signal.
Readonly signals can be accessed to read their value,
but can't be changed using set, update or mutate methods.
PR Close#49802
This commit fixes an issue were on the server the HTTP cache was being disabled prematurely which caused HTTP calls performed in `ngOnInit` life cycle hooks not to be cached.
PR Close#49826
This commit updates the code to avoid deep links into the `@angular/core`, which triggers a build issue in apps when a code is referenced.
PR Close#49823
This commit renames an internal token to better align it with the naming of the function (to highlight the fact that it's responsible for DOM part of the hydration).
PR Close#49800
Angular doesn't support IE anymore. We can remove the workarounds related to IE.
Some workarounds are keep because of the support of domino but the comments related to IE are removed.
PR Close#49763
Some libraries could use numbers in headers. this fix prevents Angular from
throwing an error by casting those numerical values into strings.
Fixes#49353
PR Close#49379
This commit improves the HTTP transfer state integration test by using `provideClientHydration` method and validates that no HTTP calls are performed during the client bootstrapping.
PR Close#49810
`toObservable` creates an `effect` that watches for updates to the
source signal. We should allow writes to signals in this effect, which
would be consumed by downstream observers.
PR Close#49769
From Ben:
> When dealing with any reactive function call you don't control
> like `observer.next()` (or anything similar), you want to catch the error
> in the producer call, in this case `signal()`. You don't want to catch errors
> in the `observer.next` call itself.
PR Close#49769
The initial value used for signals by default is now `undefined`. In
addition, there is a new option to express that the signal should emit a
value synchronously (`requireSync: true`). When this value is specified,
the function will throw _on creation_ if the subscribing to the
`Observable` does not result in a synchronous emit.
PR Close#49769
`RouterOutlet` components can initialize _during_ change detection (for
example, if they exist in an embedded view). When this happens, data
from the router should be bound immediately to the routed components
rather than not being available until the next round of change
detection. This is mostly just a problem for testing because change
detection is triggered manually. It would be surprising to have to
detect changes _twice_ on the fixture in order to get data bound to the
routed component.
PR Close#49741
The `ActivatedRoute` exposes several `Observable` members that are
`BehaviorSubject` under the hood. In order to update the values of those
subjects, we cast the `Observable` type internally. Instead, the
`BehaviorSubject` should be kept and re-exposed as public API
separately.
PR Close#49741
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
Jessica Janiuk