-
Notifications
You must be signed in to change notification settings - Fork 27.4k
Enter/leave animation not working for for first item in ng-repeat #15510
Comments
This is loosely-related to the lazy compilation of transcluded elements (or rather the fact that |
@gkalpak, I tested the demo, and with a warm cache, the animations are working. Great! But with a cold cache, the enter and leave animations still aren't working. |
Previously, `$animate` would decide whether an animation should be cancelled based on some assumption that didn't hold in specific cases (e.g. when animating transcluded clones with `templateUrl` directives on them for the first time). As a result, the entering elements would not be animated. This affected commonly used, structural built-in directives (`ngIf`, `ngRepeat`, `ngSwitch` etc). This commit fixes it by avoiding invalid assumptions (i.e. by taking into account the transformations that take place while compiling such elements). Fixes angular#15510
Previously, `$animate` would decide whether an animation should be cancelled based on some assumption that didn't hold in specific cases (e.g. when animating transcluded clones with `templateUrl` directives on them for the first time). As a result, the entering elements would not be animated in such cases. This affected commonly used, structural built-in directives (`ngIf`, `ngRepeat`, `ngSwitch` etc). This commit fixes it by avoiding invalid assumptions (i.e. by taking into account the transformations that take place while compiling such elements). Fixes angular#15510
@cvn, that is a different issue and is unavoidable I am afraid (note that the same happens if you put the directive on a child element). The problem is that the structural directive is (e.g. Previously, even if the template was in the cache (so it was loaded by the time the animation was about to start), |
For me, when the directive is on a child element, the enter and leave animations both work from a cold cache. The enter animation sometimes fails if it takes too long to fetch the template, but it works when the latency is low. Unless I'm misunderstanding what you're saying. |
Yes, this pretty much describes the situation. What I am saying is that we can't (or won't 😛) change/"fix" that. This is expected bahavior. If the template is in the |
Cool. I'm happy with how it works now. Thanks for taking the time. |
Previously, `$animate` would decide whether an animation should be cancelled based on some assumption that didn't hold in specific cases (e.g. when animating transcluded clones with `templateUrl` directives on them for the first time). As a result, the entering elements would not be animated in such cases. This affected commonly used, structural built-in directives (`ngIf`, `ngRepeat`, `ngSwitch` etc). This commit fixes it by avoiding invalid assumptions (i.e. by taking into account the transformations that take place while compiling such elements). Partly addresses angular#14074 and angular#14124. Fixes angular#15510
Previously, `$animate` would decide whether an animation should be cancelled based on some assumption that didn't hold in specific cases (e.g. when animating transcluded clones with `templateUrl` directives on them for the first time). As a result, the entering elements would not be animated in such cases. This affected commonly used, structural built-in directives (`ngIf`, `ngRepeat`, `ngSwitch` etc). This commit fixes it by avoiding invalid assumptions (i.e. by taking into account the transformations that take place while compiling such elements). Partly addresses angular#14074 and angular#14124. Fixes angular#15510
Previously, `$animate` would decide whether an animation should be cancelled based on some assumption that didn't hold in specific cases (e.g. when animating transcluded clones with `templateUrl` directives on them for the first time). As a result, the entering elements would not be animated in such cases. This affected commonly used, structural built-in directives (`ngIf`, `ngRepeat`, `ngSwitch` etc). This commit fixes it by avoiding invalid assumptions (i.e. by taking into account the transformations that take place while compiling such elements). Partly addresses angular#14074 and angular#14124. Fixes angular#15510
Previously, `$animate` would decide whether an animation should be cancelled based on some assumption that didn't hold in specific cases (e.g. when animating transcluded clones with `templateUrl` directives on them for the first time). As a result, the entering elements would not be animated in such cases. This affected commonly used, structural built-in directives (`ngIf`, `ngRepeat`, `ngSwitch` etc). This commit fixes it by avoiding invalid assumptions (i.e. by taking into account the transformations that take place while compiling such elements). Partly addresses angular#14074 and angular#14124. Fixes angular#15510
Previously, `$animate` would decide whether an animation should be cancelled based on some assumption that didn't hold in specific cases (e.g. when animating transcluded clones with `templateUrl` directives on them for the first time). As a result, the entering elements would not be animated in such cases. This affected commonly used, structural built-in directives (`ngIf`, `ngRepeat`, `ngSwitch` etc). This commit fixes it by avoiding invalid assumptions (i.e. by taking into account the transformations that take place while compiling such elements). Partly addresses #14074 and #14124. Fixes #15510 Closes #15514
Previously, `$animate` would decide whether an animation should be cancelled based on some assumption that didn't hold in specific cases (e.g. when animating transcluded clones with `templateUrl` directives on them for the first time). As a result, the entering elements would not be animated in such cases. This affected commonly used, structural built-in directives (`ngIf`, `ngRepeat`, `ngSwitch` etc). This commit fixes it by avoiding invalid assumptions (i.e. by taking into account the transformations that take place while compiling such elements). Partly addresses angular#14074 and angular#14124. Fixes angular#15510 Closes angular#15514
If an element has both ng-repeat and a directive that uses templateUrl
<div my-dir ng-repeat="...">
, the enter animation doesn't work for the first item, even if the template is in $templateCache.Demo
If you don't pre-warm the $templateCache, the leave animation doesn't work either. You can comment out the run block in the demo to see this.
If the directive is on a child element, the problem goes away, and all animations work. And if fetching the template is fast enough, enter and leave animations both work from a cold cache.
I tested this in Angular 1.5.8 and 1.6.0, with Chrome 54, Safari 10, and Firefox 50.
@gkalpak suggested I make this ticket in #12612.
The text was updated successfully, but these errors were encountered: