RC2 does not animate nested elements correctly when using AUTO STYLE feature

[mlc-mlapis]

I'm submitting a problem with animations of nested elements in RC2

[x] bug report
[ ] feature request

! First of all thanks a lot for AUTO STYLE. It is just an excellent feature that brings great opportunities and save a lot of code and time !

Current behavior
Plunker demo: There is an outer DIV that contains another inner DIV. Buttons allow to expand and collapse them individually.

• Expand the outer and then inner.
• Continue with collapsing the outer.
• Finally expand the outer again.

It is possible to see that height animation using auto style "*" works correctly only partly - it does not respect the height of previously expanded content of inner DIV. It looks like that the hidden evaluation of the outer DIV height does not see the inner expanded DIV. Probably something is wrong with evaluation of the template where *ngIf directives are used.

Expected/desired behavior
Animation of the outer DIV should respect its full content which is available in the actual moment.

Reproduction of the problem
(Example: http://plnkr.co/edit/QXiq9bYcCAcRRmxx04BS?p=preview)

Please tell us about your environment:

• Angular version: 2.0.0-RC.2
• Browser: [Chrome]
• Language: [TypeScript]

[matsko]

This looks like just a tiny race condition since the outermost parent is evaluated (animated) first and by the time is starts to calculate its AUTO values the inner div hasn't set itself to true just yet.

[mlc-mlapis]

Yes, that is maybe rigth but imagine a situation when you want to do it by your own script. First of all you need to evaluate the height to which animate. Now when you know the right height you need to set a correct value for target 'height' style. How to do it? A construction using a class variable like this.elementHeight is not supported. Is there any other way how to use a variable value in 'trigger' definition?

Do you think that there is no way how to calculate an outermost height without animation of inner elements to get the correct value?

trigger('animateInner', [
    transition('* => void', [
        style({ height: '*' }),
        animate('3000ms', style({ 'height': 0 }))
    ]),
    transition('void => *', [
        style({ height: 0 }),
        animate('3000ms', style({ 'height': this.elementHeight }))
    ])
])

[mlc-mlapis]

It would be really great if there is a solution. The 'magic' of AUTO STYLE feature would be much more sparkling then. There are many situations like hierarchical menu where nested elements are necessary.

[mlc-mlapis]

I was trying to solve the problem with the style "display" property on the inner DIV (to eliminate *ngIf evaluation) - see the plunker http://plnkr.co/edit/oQYU69IyYx0dna2G6G0a?p=preview but the problem is the same.

If the inner DIV is expanded and then the outermost DIV is collapsed and then expanded again, animation is beeing done only partly. I supposed that this solution should work.

The only part which can affect the hidden calculation of the outer DIV content height is @animateInner="showInner?'expand':'collapse'" on the inner DIV. Is this the reason why the calculated height is wrong? Why? Even if "showInner" does not exist in that moment, the expression evaluates to "collapse" state.

From another point of view the reason could be that the inner DIV does not have a state but already exists in DOM (it is created as a part of outermost DIV). Is there a way how to set it to?

[matsko]

No the issue isn't a visual CSS issue, it's just that the inner DIV doesn't exist at all when the outer div starts to animate. It doesn't matter what order the buttons are pressed; the end result is the same. This is because the animation starts immediately after the outer ngIf becomes true and the inner div hasn't been placed into the DOM yet (because even if the inner ngIf is already true it will still be evaluated and printed on screen after the outer parent becomes true). So when the animation kicks in then it calculates the final height before animating things on screen (and at that point it's too early in the process since the child isn't present).

The solution is to execute the animation once the current zone flushes. @tbosch and @mhevery I know we decided to work around this but I think this is the only way to do it. Doing so would also allow for more features down the road (group staggering and testing) to work as well.

[mlc-mlapis]

Oh, you are right, it's clear. I agree with you. We need a way how to control timeline to allow doing more things in one moment. Especially from an animation point of view.

[tbosch]

@matsko I don't like using zones for animations as it makes it hard to debug.
Eventually, we will need coordination between animations any ways, so once we have that this issue should be solvable.

[tbosch]

Agreed on the following:

1. change animation player to not read css styles until the first call to play
2. change AppView.registerAndStartAnimations to only register the animation and put the player into a new toBeStarted array
3. add a new method AppView.playAnimations which loops over these players and calls play on them
4. once a view has at least one animation, add a call to AppView.playAnimations and call it at the same time as the ngAfterViewChecked lifecycle callback. I.e. when all child elements have been dirty checked.

[mlc-mlapis]

Tobias, thanks for your input and coordination. Till now I did not have enough time and opportunities to go through this part of code to understand exactly what each point means right now but they sound logically.

If there is a way how to do these type of things without touching and changing zones engine then better.