We were clearing duplicate nodes when `animate.enter` fired fast, but not when solely `animate.leave` is fired and rapid toggles occur. This ensures that the `cancelLeavingNodes` function is called in all cases instead of just enter animations.
fixes: #64581
PR Close#64592
In some rare cases, it seems the animation queue disappears despite being afterEveryRender. This updates the animation scheduler to be afterNextRender instead and only schedules it when we need to.
fixes: #64423
PR Close#64441
When adding and removing items in a `@for` loop, the `animate.leave` event binding instruction was not updated to use the same logic as the class function when the animation queue was added. We were not returning the correct signature for the `animate.leave` function, which caused the animation to not trigger correctly. This updates the event binding instruction to use the same logic as the class function when adding the animation to the queue.
fixes: #64336
PR Close#64413
This replaces the error we were throwing before the change. This allows component with defer triggerrs to be used on both SSR'd and CSR.
fixes#64184
PR Close#64185
In some cases, the leave animation stylesheets were getting pruned too early due to the renderer removal happening before the animation function was run. This ensures that while queuing a leave animation, we guarantee the lView is referenced in the leaving animations set. This guarantees the style sheet pruning knows about the animations existing and skips the prune step.
fixes: #64326
PR Close#64335
Our code ensuring host binding composition for animations was causing the early exit and removal of
elements when multiple transitions were present on the same element. This commit fixes the issue by
ensuring that we properly keep track of all the promise resolvers on the LView and then only
call them once we've properly waited for the longest animation to finish.
fixes: #64209
PR Close#64225
There may be cases where the longest animation info has been cleaned up before the end animation fires. We should still do the end processing in that case.
PR Close#64225
These tests were not properly validating against the host binding changes due to the fact that the styles were on the wrong components in some of the host binding cases.
PR Close#64225
There was a bug in the logic for checking if a leave animation exists for a node. This was affecting timing of nodes with enter animations.
PR Close#64226
Content Projected nodes are not destroyed and recreated, like every other
situation. Enter and Leave animations were ephemeral and are
expected to run once, and then be cleared. This means that for content projection
cases, the animations would only ever work the first time they were shown / hid.
In order to resolve this, we move to an animation queue that re-runs the animation
functions stored in the LView. In most cases, this animation will run once on creation.
For content projection, the enter and leave animations will fire more than once. Animations
are stored on the LView, but indexed and scheduled by whichever RNode needs to be animated.
So we only run animations for an affected RNode, rather than potentially all in the LView.
This also moves the queue to afterRender, which is safer than right after template
execution in refreshView.
fixes: #63418fixes: #64065fixes: #63901
PR Close#63776
Improve error handling when `rawDelays` contains fewer items than `transitionedProperties`, preventing a toLowerCase of undefined error in `parseCssTimeUnitsToMs`.
PR Close#64181
Content Projected nodes are not destroyed and recreated, like every other
situation. Enter and Leave animations were ephemeral and are
expected to run once, and then be cleared. This means that for content projection
cases, the animations would only ever work the first time they were shown / hid.
In order to resolve this, we move to an animation queue that re-runs the animation
functions stored in the LView. In most cases, this animation will run once on creation.
For content projection, the enter and leave animations will fire more than once. Animations
are stored on the LView, but indexed and scheduled by whichever RNode needs to be animated.
So we only run animations for an affected RNode, rather than potentially all in the LView.
This also moves the queue to afterRender, which is safer than right after template
execution in refreshView.
fixes: #63418fixes: #64065fixes: #63901
PR Close#63776
The event listeners for animationstart and animationend weren't properly checking whether the animation event fired matched the node we're bound to, since animation events bubble. This resulted in child node animation events bubbling up and causing elements to get prematurely removed.
fixes: #64084
PR Close#64088
angular#62630 made it so that all ARIA
property bindings would write to their corresponding attribute instead.
The primary motivation for this change was to ensure that ARIA
attributes were always rendered correctly on the server, where the
emulated DOM may not correctly reflect ARIA properties as attributes.
Furthermore, this change added support for binding to ARIA attributes
using the property binding syntax (e.g. `[aria-label]`).
Unfortunately, angular#62630 relied on
the incorrect assumptions that an ARIA property name could be converted
to its attribute name (without hardcoding the conversion), and that the
value of an ARIA property matched its corresponding attribute. For
example, the `ariaLabelledByElements` property's value is an array of
DOM elements, while the corresponding `aria-labelledby` attribute's
value is a string containing the IDs of the DOM elements.
This partially reverts angular#62630 so
that only property bindings with ARIA attribute names (begin with
`aria-`) are converted to attribute bindings.
* `[ariaLabel]` will revert to binding to the `ariaLabel` property.
* `[aria-label]` will continue binding to the `aria-label` attribute.
Note the only difference between `[aria-label]` and `[attr.aria-label]`
is that the former will attempt to bind to inputs of the same name while
the latter will not.
PR Close#64089
This commit changes `Resource.hasValue()` and its derived types to improve narrowing
of resources whose generic type either does not include `undefined` (i.e. when a default
value has been provided) or when the generic type is `unknown`. This fixes the undesirable
behavior where `hasValue()` would cause the `else` branch of an `hasValue()` conditional
to have a narrowed type of `never`, given that the `hasValue()`'s type guard covers the
entire type range already (meaning that the type in the else-branch cannot be inhabited
in the type system, yielding the `never` type).
By making the `hasValue()` method only a type guard when the generic type includes `undefined`
these problems are avoided.
Fixes#60766Fixes#63545Fixes#63982
PR Close#63994
This adds an optional flag to the renderer on `removeChild` called `requireSynchronousElementRemoval`, which can tell any downstream renderer that elements need to be removed synchronously. This gets passed down to the legacy animation renderer to ensure that any elements that set this flag aren't impacted by that renderers changes to timing.
fixes: #63893
PR Close#63921
In production builds, `ngDevMode` is replaced with `false`, so the guard compiles to `return;`. However, bundlers like ESBuild still keep the remaining statements after the return as unreachable code instead of removing them. This leaves behind unnecessary dead code in the output.
Technically, the body is unreachable. But to prove that, the bundler must be 100% certain that:
- `return` cannot be removed by some transform
- there's no later transformation that changes control flow
As thus, it's always conservative.
This also allows dropping `assertDefined`, which was previously
referenced only inside `prependTokenToDependencyPath`. With the
function now fully inlined and dev-only, `assertDefined` is also
eliminated from production builds, further reducing bundle size.
PR Close#63354
The `checkNoChanges` method previously used an early-return guard:
if (!ngDevMode) return;
// dev-only code ...
In production builds, `ngDevMode` is replaced with `false`, so the
guard compiles to `return;`. However, bundlers like ESBuild
still keep the remaining statements after the return as unreachable
code instead of removing them. This leaves behind unnecessary dead
code in the output.
This commit updates the method to instead wrap the full body:
if (ngDevMode) {
// dev-only code ...
}
With this change, the method collapses to an empty function in
production builds:
checkNoChanges() {}
This ensures that the dev-only logic and its dependencies
(e.g. `checkNoChangesInternal`, `UseExhaustiveCheckNoChanges`) can be
fully tree-shaken, reducing bundle size.
PR Close#63387
This is a pure re-organization of the animations code. No functionality changes, but it should be easier to navigate now. Utility classes have been moved to a `utils.ts` file. The related functions in the instructions have been grouped closer together.
PR Close#63775
When a user has `animate.leave` on a list of items in a `@for`, but are only showing a subset using a computed, removing the second to last item results in a move operation on the last item. There's no native atomic move API in the browser. So this results in the element being detached and attached at its new index. The detaching of the node resulted in leave animations firing.
This fix addresses this by adding a flag in the `LView[ANIMATIONS]` `AnimationLViewData` interface to allow for skipping animations. During list reconciliation, we set this flag so that the animations are skipped over. The flag is flipped back after the move operation is complete.
There is one complication that results from this. The index adjustment of elements in the list happens synchronously while the leave animation is asynchronous. This results in the leaving item getting shifted to the end of the list. This is not ideal but likely can be addressed in a future refactor.
fixes: #63544
PR Close#63745
This updates the enter and leave logic to use the stored LView data to dispatch the enter and leave animations at the right points in the lifecycle. This should fix issues with signals not being available yet, parallel animations, and also eliminate the need for the element registry.
fixes: #63391fixes: #63388fixes: #63369
PR Close#63710
In order to point the right context, links in error messages will target the archived version of the online doc site (v*.angular.io).
See #44650
PR Close#63512
This will allow manually subscribed animation events to still fire when using `animate.leave`. Otherwise they were being cleaned up before the animations happened.
fixes: #63391
PR Close#63414
This commit introduces a number of changes to the server bootstrapping process to make it more robust and less error-prone, especially for concurrent requests.
Previously, the server rendering process relied on a module-level global platform injector. This could lead to issues in server-side rendering environments where multiple requests are processed concurrently, as they could inadvertently share or overwrite the global injector state.
The new approach introduces a `BootstrapContext` that is passed to the `bootstrapApplication` function. This context provides a platform reference that is scoped to the individual request, ensuring that each server-side render has an isolated platform injector. This prevents state leakage between concurrent requests and makes the overall process more reliable.
BREAKING CHANGE:
The server-side bootstrapping process has been changed to eliminate the reliance on a global platform injector.
Before:
```ts
const bootstrap = () => bootstrapApplication(AppComponent, config);
```
After:
```ts
const bootstrap = (context: BootstrapContext) =>
bootstrapApplication(AppComponent, config, context);
```
A schematic is provided to automatically update `main.server.ts` files to pass the `BootstrapContext` to the `bootstrapApplication` call.
In addition, `getPlatform()` and `destroyPlatform()` will now return `null` and be a no-op respectively when running in a server environment.
(cherry picked from commit 8bf80c9d2314b4f2bcf3df83ae01552a6fc49834)
PR Close#63636
This commit updates provider definitions that relied on the `deps` array
with `new Optional()` and `new SkipSelf()` to instead use the modern
`inject(..., { optional: true, skipSelf: true })` API.
Previously:
deps: [[KeyValueDiffers, new SkipSelf(), new Optional()]]
Now:
const parent = inject(KeyValueDiffers, { optional: true, skipSelf: true });
**Bundle size reduction**: `Optional` and `SkipSelf` are runtime values
created by `makeParamDecorator()`. Even in production builds, esbuild
and other bundlers must keep their factory code because they are
referenced with `new Optional()` / `new SkipSelf()`. With `inject()`,
those classes are no longer referenced, allowing them and the
`makeParamDecorator` scaffolding to be tree-shaken when unused.
As a result, production bundles can drop both `Optional`, `SkipSelf`, and
their supporting factory code when not used elsewhere, reducing code size
while keeping the same behavior.
PR Close#63386
