Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

Enter/leave animation not working for for first item in ng-repeat #15510

Closed
cvn opened this issue Dec 14, 2016 · 6 comments
Closed

Enter/leave animation not working for for first item in ng-repeat #15510

cvn opened this issue Dec 14, 2016 · 6 comments

Comments

@cvn
Copy link

cvn commented Dec 14, 2016

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.

<div ng-repeat="x in y"> <div my-dir></div> </div>

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.

@gkalpak
Copy link
Member

gkalpak commented Dec 15, 2016

This is loosely-related to the lazy compilation of transcluded elements (or rather the fact that ngAnimate does not handle that correctly). I have a fix for it (see demo), which I am having a hard time writing a test for 😃

@cvn
Copy link
Author

cvn commented Dec 16, 2016

@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.

gkalpak added a commit to gkalpak/angular.js that referenced this issue Dec 16, 2016
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
gkalpak added a commit to gkalpak/angular.js that referenced this issue Dec 16, 2016
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
@gkalpak
Copy link
Member

gkalpak commented Dec 16, 2016

@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. ngRepeat) is animating in a plain DOM element (e.g. <my-dir-a></my-dir-a>). It is not its job to know what is going on on that element (e.g. that it matches a myDirA directive or that myDirA has loads its template asynchronously). It just animates the element in.

Previously, even if the template was in the cache (so it was loaded by the time the animation was about to start), $animate would fail to properly perform the animation due to a bug. With #15514 the animation is correctly executed, but the developer still has to ensure that the template will be available by the time the animation starts (either by inlining it with template or by pre-caching it).

@cvn
Copy link
Author

cvn commented Dec 16, 2016

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.

@gkalpak
Copy link
Member

gkalpak commented Dec 16, 2016

The enter animation sometimes fails if it takes too long to fetch the template, but it works when the latency is low.

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 $templateCache, you can be certain it will be there in time and will be visible for the animation (this is what my PR fixes). If the template is fetched from a server, it may or may not make it in time to be present when the animation happens.

@cvn
Copy link
Author

cvn commented Dec 16, 2016

Cool. I'm happy with how it works now. Thanks for taking the time.

gkalpak added a commit to gkalpak/angular.js that referenced this issue Dec 20, 2016
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
gkalpak added a commit to gkalpak/angular.js that referenced this issue Dec 31, 2016
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
gkalpak added a commit to gkalpak/angular.js that referenced this issue Dec 31, 2016
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
gkalpak added a commit to gkalpak/angular.js that referenced this issue Jan 9, 2017
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
gkalpak added a commit that referenced this issue Jan 24, 2017
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
ellimist pushed a commit to ellimist/angular.js that referenced this issue Mar 15, 2017
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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.