ngAnimate on ngView duplicates the ngRepeat in the view template

[alexeygolev]

It might be that I'm using the animator incorrectly, but this is the behaviour

http://beta.plnkr.co/edit/whIMmE9eScbWMcd475ul?p=preview

I used both scenarios — getting data using resolve and getting it in controller.
Before destroying the scope ng-repeat "goes mad".

Update:
Another weird behaviour can be seen here:
http://beta.plnkr.co/edit/eFQ31X2er0ePIhEnZsjs?p=preview
I added the third view with a directive that uses Isotope. Isotope disappears as soon as you change a path, while the rest of the view fades out as expected.
Seems like ngAnimate messes up the behaviour of directives inside ngView.

[alexeygolev]

It seems like the duplication in ngRepeat is a result of switching two scopes with '$scope.test' models in both of them. I updated the plunk — switching from view2 to view5 doesn't lead to a duplication. However, now view2 is not being animated on leave. The list just disappears before any animation begin.

[jeme]

I am experiencing allot of duplicates as well, and items doesn't seem to get the right layout applied until they are in place. And sometimes in complex scenarios not at all. I even think I have managed to crash chrome on occasions.

So I guess that ng-animate isn't quite mature yet, hope they work through the bugs so we can begin to use it.

[alexeygolev]

@jeme It will be nice to have plunks of your issues.

[jeme]

@alexeygolev your plunk actually already shows that the layout gets mangled, (tests are under bullets) at least for me.

Sorry, strike that... It was actually in the sample app from: https://github.com/angular-ui/ui-router/tree/issue-22

To get into something that breaks as severely as my current app does if I introduce requires quite a bit, as I think the failures comes with the complexity...

All these cases happen under views though, And I think that for the layout stuff... This could be related to that the Controller is run while the transition takes place, this means that we begin to change the view midway transition as it gets populated with elements...

---

I can't seem to fork your plunk, changing the first one to use wave actually introduces the issue. (need to copy the CSS from their examples as well), but it a REALLY light case compared to what I am seeing.

[jeme]

http://dotjem.github.io/angular-routing/samples/substates/#/

So far it seems that there is going to be a massive need to adjust things hosted in ng-view etc...
What I have had to do in the example is to wrap the animations in javascript so I could adjust the height of the parent container (the view) in order to fit the new content, obviously updating for each digest... This is super ugly as is right now...

app.animation('wave-enter', function ($rootScope, $timeout) {
    return {
        setup: function (element) {
            var elm = $(element);
            var parent = elm.parent();
            elm.addClass('wave-enter-setup');
            parent.css({ 'height': elm.height() });
            parent.addClass('stage');

            return $rootScope.$watch(function () {
                parent.css({ 'height': elm.height() });
            });

        },
        start: function (element, done, memo) {
            var elm = $(element);
            var parent = elm.parent();
            elm.addClass('wave-enter-start');

            $timeout(function () {
                memo();

                elm.removeClass('wave-enter-setup');
                elm.removeClass('wave-enter-start');

                parent.removeClass('stage');
                parent.css('height', null);

                done();
            }, 2000);
        }
    };
});

And there is still loads of stuff to figure out here... not to mention that this again ends up having the "you need to sync timers between the CSS and JavaScript"... I tried to see if I could get a pure javascript animation to work as well, but ran into other issues... Anyways... the above "almost works" until animations are triggered rapidly (so that they can't complete before the next begins to screw up the elements)

I think this could advocate for some improvements from the animation/animator framework, where you could hook in on when the animation is suppose to be done, queuing, canceling and so forth... (If that isn't already possible somehow?)...

The final thing is that in some cases, the layout is still buggy, that last part I can't figure out.

[matsko]

@alexeygolev Can you double check if this is fixed with 1.1.5?