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

ngAnimate with ngRepeat in directive using templateUrl issue #14124

Closed
xavadu opened this issue Feb 24, 2016 · 13 comments
Closed

ngAnimate with ngRepeat in directive using templateUrl issue #14124

xavadu opened this issue Feb 24, 2016 · 13 comments

Comments

@xavadu
Copy link

xavadu commented Feb 24, 2016

Hello,

Sorry but i can't reproduce this error on plunkr yet.

The issue is that ngRepeat animation fail for the first time when is applied on a directive that use a templateUrl, it start to happen in 1.5.0 upgrade, on 1.4.1 it was working fine.

The css animation never get the state of .ng-enter-active and it keep on the .ng-enter state.

some PoC:

.animate-repeat.ng-enter,
.animate-repeat.ng-move {
    transition: 0.5s ease-out all;  
    animation-fill-mode: both;
}

.animate-repeat.ng-enter {
  background-color: red;
  transform: translate3d(0, -5%, 0);
}

.animate-repeat.ng-enter.ng-enter-active {
  background-color: blue;
  transform: none;
}

.animate-repeat.ng-enter-stagger {
  transition-delay: 0.1s;
  animation-delay: 0.1s;
  transition-duration: 0s;
}

<my-directive ng-repeat="colors in sky" class="animate-repeat"><my-directive>

if sky is equal to null, not defined or empty array, etc.. it happen, if sky is previously populate it doesn't happen. On our case sky is populate by an $http request after some user interaction in a form.

The situation is that myDirective keep with background red and never get the background blue. Later a re-submit, it works, because sky had data previously and wasn't null or empty.

The interesting is that it occur only if my-directive use a templateUrl, if the template is inline all works fine.

Is quite complicate to explain, let me know if you need a better description of some part.

It become really annoying when instead a a background color, you are going from opacity 0 to opacity 1. So, the ngRepeat list don't appear.

@xavadu xavadu changed the title ngRepeat with templateUrl directive on ngAnimate issue ngAnimate with ngRepeat in directive using templateUrl issue Feb 24, 2016
@dcherman
Copy link
Contributor

In all likelihood, this is a duplicate of #14074

@Narretz
Copy link
Contributor

Narretz commented Feb 25, 2016

It does sound a bit different than the other issue, so a plnkr would really help. Especially the part where it works the second time.

@dcherman
Copy link
Contributor

@Narretz Yup, would definitely help. The reason it might work (and be the same issue) is that once transclusion occurs, the original async directive is replaced with a derived sync one, so the second time the ngRepeat unrolls after the $templateRequest completes, it wouldn't exhibit the bug.

@xavadu
Copy link
Author

xavadu commented Mar 29, 2016

Hello,

I can re create the situation in a plunkr, for a practice propuse i defined the ng-repeat animation ng-enter class with opacity 0.3, so we can appreciate that the element was inserted in the DOM but the animation state doesn't change to ng-enter.ng-enter-active which define the opacity to 1 (only for the first populate of the objects array, in the example called $scope.food, later it works fine).

You can notice that if the template is inline it works as expected but if the template is external few issues are happening:

On first click 'load items' not all the items reach the ng-enter.ng-enter-active state and they keep with 0.3 of opacity,

On a second click in 'load items' the way that the items disappear is weird.. the new items are added to the DOM and after the previously items are removed (i thought that it is related to the first problem)

If the 'load items' button is clicked for a third time, both directives are working fine as expected.

http://plnkr.co/edit/1lh5mN83ipAlKek4vUqz?p=preview

Any ideas about the cause of the issue? Remember that it start to happen in 1.5.0 upgrade, on 1.4.1 it was working fine

@poacher2k
Copy link

We're also experiencing this exact issue on a project using angular and angular-animate version 1.5.3.

@Narretz
Copy link
Contributor

Narretz commented May 19, 2016

Sorry for the late response. This also looks like a problem with lazy transclusion, introduced in 1.5.0-beta.0. We'll investigate what we can do about this.

@lishner
Copy link

lishner commented Aug 10, 2016

Having the same issue here, it seems that the classes "ng-animate ng-enter ng-enter-active" wasn't removed from the elements.
If the problem is only with the element that doesn't exist because of the templateUrl I would still expect it will remove those classes when it "finish" the animation.

What more interesting is that when I'm using "keyframes" for animation it works.
https://plnkr.co/edit/WTBVrcOmKotG7PNMk2A7?p=preview -> Angular 1.5 not working
https://plnkr.co/edit/GSBQwIlgHpRzxSRDKBE4?p=preview -> Angular 1.5 works with keyframes.

If you like you can change the test to use 1.4.9 in the index.html and see that the first example works as well.

But even when it works using keyframes the unwanted classes ("ng-animate", etc..) still there.

BTW - Since it works as it should in 1.4.9 can we say it's regression?

@xavadu
Copy link
Author

xavadu commented Dec 20, 2016

@Narretz. any update about it? or how I can help to solve it faster?
Thanks

@gkalpak
Copy link
Member

gkalpak commented Dec 20, 2016

This is loosely related to #15510. Actually, I think it is a combination of #15510 and some other issue (yet to be determined).

@gkalpak
Copy link
Member

gkalpak commented Dec 20, 2016

You can grab the angular-animate.min.js from this plnkr to try out #15514 (which fixes #15510). It improves the situation (especially if you pre-cache your templates), but does not solve the problem(s) entirely.

Also, note that if you are using a non-cached templateUrl your animations might not look the way you expect them and that is...expected behavior (see the discussion around #15510 (comment) for more info).

Yet, I suspect there is still some other issue that we need to track down (and fix).

@gkalpak
Copy link
Member

gkalpak commented Dec 20, 2016

BTW, @lishner's example is the exact same as #15510 (and thus fixed by #15514 to the extend permitted given #15510 (comment)).

@xavadu
Copy link
Author

xavadu commented Dec 20, 2016

@gkalpak yes, at the moment to solve the problem I embed the template in the directive using template instead of templateUrl, I wil ltake a look tot he plnkr and related issues

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
Copy link
Member

gkalpak commented Dec 31, 2016

I am going to close this since this is partly solved by #15514 and partly a duplicate of #14074 (see also #14074 (comment)).

@gkalpak gkalpak closed this as completed Dec 31, 2016
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
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.
Projects
None yet
Development

No branches or pull requests

6 participants