-
Notifications
You must be signed in to change notification settings - Fork 27.4k
ngAnimate with ngRepeat in directive using templateUrl issue #14124
Comments
In all likelihood, this is a duplicate of #14074 |
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. |
@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 |
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 |
We're also experiencing this exact issue on a project using angular and angular-animate version 1.5.3. |
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. |
Having the same issue here, it seems that the classes "ng-animate ng-enter ng-enter-active" wasn't removed from the elements. What more interesting is that when I'm using "keyframes" for animation it works. 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? |
@Narretz. any update about it? or how I can help to solve it faster? |
You can grab the Also, note that if you are using a non-cached Yet, I suspect there is still some other issue that we need to track down (and fix). |
BTW, @lishner's example is the exact same as #15510 (and thus fixed by #15514 to the extend permitted given #15510 (comment)). |
@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 |
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
I am going to close this since this is partly solved by #15514 and partly a duplicate of #14074 (see also #14074 (comment)). |
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 #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
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:
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.
The text was updated successfully, but these errors were encountered: