TransitionGroup leave animation doesn't get non-active style

[matthewwithanm]

I think I've come across a bug with TransitionGroup which basically causes properties of the "leave" styles to be ignored. Here's a fiddle demonstrating the problem.

As you can see, the "leave" animation doesn't use the correct origin or transition (in the latest Chrome or FF). If those properties are moved to an always-matching selector (".bluebox"), it works fine.

My only guess as to why this would happen is that the active leave class is being added in the same tick as the leave.

[matthewwithanm]

Alright, I dug into the source today to see what was going on. This isn't a bug with TransitionGroup (all of the classes are being applied correctly) but a bug in the CSS. (In other words, my fault!)

However, I do think it highlights a problem with the current animation approach. Let me back up a little to explain why:

The reason that my fiddle doesn't work as I (incorrectly) expected is because the starting value of my transform-origin doesn't match the default value of the element. In addition, the transition specifies that that property should be animated (since it uses "all"). So when the "-leave" class is added, the origin is animated to the "starting" value (right center).

In other words, it's not currently possible to specify a starting point for a leave animation that doesn't match the default value. Of course, I could set the transform-origin for every element that uses the transition but that's clearly brittle and difficult to maintain.

One possible solution would be for React to add an idle class when the transition is idle. Alternatively, users could put the transition property in the "-active" classes instead, but I think that has the potential to screw up switching from enter to leave before enter has completed (or vise versa). (Then again, I'm not sure that's working anyway.)

I realize that this behavior is all taken from ngAnimate, so maybe this isn't the best place to discuss the issue. On the other hand, the React project is much younger and there's probably more of an opportunity to correct it here without worrying about legacy. Let me know!

[plievone]

there's probably more of an opportunity to correct it here without worrying about legacy.

I collected a few TransitionGroup issues here #587 . There are race conditions, for example repaints due to some other component's componentDidMount on same tick can cause flash of misstyled content, so perhaps initial render should be affected via setStates in componentWillMount instead.

I guess I would not count on TransitionGroup but go for some custom solution, setting some visible/hidden props, tracking the states in some container, and triggering transitions based on comparing those props in components, notifying the container for completion.. Of course it will be a mess, but there are so many complicated interactions here...

[sophiebits]

This isn't super actionable so I'm going to close it out. Thanks for your thoughts though! CSS transitions seem to be surprisingly tricky.

[tannerlinsley]

I know this is close, but I thought I would also let people know that this problem snuck up on me to the point that I also dug through the source code only to find that I needed to move the transition property to the -active classes, instead of having it defined by default on the idle or default class of the element. This is not a bug. It will feel like one though if you have moved from angular to react. Ng-Animate goes into great detail to avoid strange edge cases like this one, and since this library is still young (and in my opinion, getting a bit neglected), so don't expect all the edge cases to be covered ;) Great addon nonetheless. Thanks React team!