animation bugs / unexpected behaviours

[fxck]

need of ng-leave on state transition animations

The effect itself doesn't need any manipulation with the state that is being removed, it just needs to stay where it was until the new state is on position, but if I don't specifiy ng-leave, it's gonna disappear right away, so I have to specify it

So I thought no problem, I'll specify it, but with the same property on both ng-leave and ng-leave-active(like opacity: 1), so it visually stays the same, see http://plnkr.co/edit/QsUxRYCH1lpXhywPCNLg?p=preview so the element that was being removed stayed on the place just fine, but didn't get removed at the correct time(I assume) so both enter and leave elements are at one point visible at the same time!

The only way to make it working was to actually set different opacity on ng-leave-active see http://plnkr.co/edit/6VRykxIOBr3Tz6FWxViM?p=preview old state still seems to flash there, but only very briefly. But it still sucks having to change that opacity.

ng-repeat animation not working on initial load

From this(http://plnkr.co/edit/jtXu7ZioEdA4yYxPSSFB?p=preview) example from @matsko I got the impression repeater animation would work on init, but when using it along ui-router, it just does not http://plnkr.co/edit/WHicNh8m22HArcfogbBC?p=preview .. I could make it work by adding a $timeout before setting the object.. which kind of sucks

ng-repeat animation not working after state change

See http://plnkr.co/edit/49WX9PsGbHmGTkQYfHOd?p=preview click on page b and the back to page a.. I have encoutered this quite a few times, it doesn't seem to be able to perform two different animation at the same time..

These angular animation are pretty damn useful.. if only I did not encounter a problem everytime I try to do like anything..

cc @matsko

[matsko]

Thanks for the detailed overview. I'll reply once I've looked into each bug in more detail.

[matsko]

BTW @fxck you didn't happen to chat with @IgorMinar beforehand about these issues? He mentioned to me that someone was experiencing something similar to what you've outlined here.

[fxck]

nope

[matsko]

OK. Looks like the initial-load guard should be removed since it can cause an undesired effect.

[fxck]

all three of them are caused by the initial load guard?

[matsko]

Kinda. 2) and 3) are there because of the guard in general.

[fxck]

Alright and is it possible to disable it just by commenting something out, or it's gonna require some bigger intervention?

[matsko]

@fxck making the load guard / child guard optional in 1.3 opens up a lot of flexibility for animations and I think it is a good idea to make use of this. The only problem is how to express that certain animations are blocking and others not.

Perhaps we could use a special CSS naming convention:

<!-- standard "blocking" ng-animate animation -->
<div class="slide-animation"> ... ... </div>

<!-- inherited "non-blocking" ng-animate animation -->
<div class="slide-animation ng-animate-no-block"> ... ... </div>

As much as I've thought about it, I think it's best to place the blocking flag in the template since it's too late to set the flag in the CSS code (and in CSS code it wouldn't be very relevant to apply it to JS animations).

I think it's a good idea to do this for now and then come up with a better API down the road. Did you have any idea in mind for this?