This commit ensures we flush animations by calling renderFactory
begin/end in cases where the ApplicationRef._tick happens in a mode that
skips straight to the render hooks.
PR Close#55564
In Angular today, a bound listener automatically marks the view for
check. When using ZoneJS, these listeners are most often executed in the
Angular Zone as well, so synchronization (`ApplicationRef.tick`) will
eventually happen. _However_, developers can opt out of zone-patching
for events in several ways, and often do this for very frequent
listeners like `mousemove`, `resize`, and `scroll`. We do not want to
break existing expectations that these are now "safe" events to have
listeners for by automatically scheduling change detection regardless of
whether the listener executed inside or outside the Angular zone.
In contrast, in order for developers to more easily transition to zoneless,
we need to be able to ensure that components which are using `OnPush`
are, for the most part, compatible with zoneless as well. Because listeners
automatically mark the component for check, developers using `OnPush`
did not/do not need to also call `ChangeDetectorRef.markForCheck` or a
similar API. Unfortunately, this means that we need to consider the
listener callbacks as a notification to schedule a `tick` when Zoneless
is enabled. In the future, we would like to have an opt-out for this
(i.e. signal components) since it's not really how we _want_ things to work.
Also includes the fix for #54919 that got reverted only because it was
easier to revert the set of conflicting commits
PR Close#55525
This change ensures that `ApplicationRef.tick` flushes animations by
calling `rendererFactory2.end`. This might not have happened before if
there were no views that needed to be refreshed.
This is also likely to fix a potential regression caused by #53718 even
in zone apps where animations don't get flushed when no views attached
to ApplicationRef are dirty.
PR Close#55132
Node removal is immediate and does not require change detection to run
when animations are not provided. This refactor makes the animation
engine notify the scheduler rather than doing it on all node removals.
PR Close#53857
This commit removes the `finish` listener from the Animation object once
the animation is finished, effectively resolving a memory leak. Previously,
the `finish` listener captured `this`, which prevented `this` from being garbage collected.
PR Close#51136
Animations events registered against the default renderer weren't registered against the animation renderer once it was loaded. This commit fixes this.
fixes#52076
PR Close#52087
`provideLazyLoadedAnimations()` returns providers which allow the lazy loading of the animation module.
Lazy loading of the animation code can shave off up to 16KB gzipped of the main bundle.
PR Close#50738
The `NoopAnimationDriver` as static property of `AnimationDriver` prevents it from being removed by tree shaking. This commit deprecates it and exposes the `NoopAnimationDriver` on the public API to replace its usage.
DEPRECATED:
The `AnimationDriver.NOOP` symbol is deprecated, use `NoopAnimationDriver` instead.
PR Close#51843
The `Writable` type is usefull when we want overwrite readonly properties and we still want to maintain code navigation/reference. It should be use instead of type assertions.
PR Close#49754
Currently internally Angular has some customized tsconfig files, because we don't align with the tsconfig of the rest of g3. These changes enable `noImplicitReturns` and `noPropertyAccessFromIndexSignature` to align better with the internal config.
PR Close#51728
The animations packages were duplicating a little bit of code due
to relative imports between entry-points. This caused bundlers to
inline shared functions twice in both FESM outputs.
PR Close#51500
This commit fixes a memory leak.
`_namespaceLookup` was cleared before the call to `processLeaveNode()` which was using the lookup.
Without that lookup `clearElementCache()` wasn't called thus keeping a reference to the element.
Fixes#24197 & #50533
PR Close#50929
Prior to this commit, the renderer destroy method was being called before the animation complete. This is problematic when using `REMOVE_STYLES_ON_COMPONENT_DESTROY` as it causes the styles to be removed too early.
This commit, updates this destroy logic to be call the render destroy once the animations complete.
This has been reported internally in:
- http://b/271251353#comment12
- http://b/282004950#comment5
PR Close#50860
Prior to this commit, the renderer destroy method was being called before the animation complete. This is problematic when using `REMOVE_STYLES_ON_COMPONENT_DESTROY` as it causes the styles to be removed too early.
This commit, updates this destroy logic to be call the render destroy once the animations complete.
This has been reported internally in:
- http://b/271251353#comment12
- http://b/282004950#comment5
PR Close#50677
Injecting `ViewContainerRef` into a component makes it effectively a container. The leave animation wasn't triggered on containers before this fix.
fixes angular#48667
PR Close#48705
Hydration relies on a signal from ZoneJS when it becomes stable inside an application, so that Angular can start serialization process on the server or post-hydration cleanup on the client (to remove DOM nodes that remained unclaimed).
Providing a custom or a "noop" ZoneJS implementation may lead to a different timing of the "stable" event, thus triggering the serialization or the cleanup too early or too late. This is not yet a fully supported configuration.
This commit adds a warning (non-blocking) for those cases.
PR Close#49944
the easing "prop" used to specify the easing function to
apply to animations isn't a valid css property, it is thus
considered not animatable but different values for such
property shouldn't cause non-animatable warnings
resolves#48571
PR Close#48583
fix the issue of camel-case properties not being handled correctly in
state transition causing them not to be applied to the element
resolves#48246
PR Close#48436
make sure that when an animation is used via the `useAnimation` function
and a delay has been provided then that delay gets correctly applied
(this PR is a follow up for #47285)
PR Close#47468
make sure that when an animation is defined via the `animation` function
(and used via `useAnimation`) and a delay has been provided then that
delay gets correctly applied
resolves#47283
PR Close#47285
prior to this change the stagger timing was being built during the
ast building instead of dynamically when visiting the stagger animation,
thus it could not handle params correctly, this change makes it so that
during ast building a timing ast is built instead and that ast is used
dynammically to build animations which can handle params correctly
resolves#19786
PR Close#47208
style values get added to the `_globalTimelineStyles` map in order to keep
them so that they can be used across different timelines
`_globalTimelineStyles` was previously a plain object but has been
refactored to a map in #44482, as part of the update a check has been
changed from a ternary operation to an or (||), causing falsy values (as 0)
not to be added to the map anymore, apply the nullish coalescing operator (??)
instead to make sure only `undefined` and `null` are filtered out
also since this aspect was clearly not covered by tests, add a new test
to ensure that such regression doesn't happen in the future
resolves#46833
PR Close#46863
move the check for non-animatable properties from the animation building
phase to the application of the animation's transition instead, in such
a way we can check it against the keyframes of the transition's timeline
in order to only provide warnings for properties which are being
animated, thus not providing any warning for non-animatable properties
being applied to elements via the style function
this change has the benfit just mentioned above but it comes with two
drawbacks:
- the warning handling is not done in the building time so it is a bit
inconsistent with other type of validations (such as the unsupported css
properties one for example)
- before the warning was being applied only when the animation's data
was being parsed, so it happed only once but now since it is applied
when the animation is actually being prepared to be played, it happens
each time the animation runs
resolves#46602
PR Close#46666