Animations before unmounting (and in general)

[chenglou]

(Context: my pull request for fixing the bootstrap modal example: #160).
Animation in componentDidMount works, but doesn't in componentWillUnmount for obvious reason.

Let's say I have three divs side by side. When the middle one closes, it does a shrinking animation and disappears, and the one on the right moves left to take its place. Currently it takes a bit of circumventing to make this work (and kills the nice structure and semantic react's aiming for), and at the end it kind of defeats the purpose of the diff rendering technique.

I was wondering if there'd be a clean way, maybe even a new api, to make this work well.

[jordwalke]

This is a really great question. We've discussed and heard several very interesting proposals for new APsI that allow us to express animations. We'll definitely be working on this going forward. My current belief is that it would be best to form an API that is layered on top of the declarative API that is at the heart of React. Currently, some animations are very functional, and those are very well suited to React's current API. Many animations can be elegantly expressed using CSS rules - React's current API is also is very well suited to those. Other types of animations that are more difficult to express functionally, take more effort and may require that you implement componentDidUpdate or componentWillUpdate. I'd love to see an API that allows us to express what happens in these "less functional" animations in a functional/declarative way. Feel free to send out gists of the simplest cases if you have any ideas.

Here's one proposal that may be worth considering: Imagine if upon transitioning states, all DOM mutations that occur as a result may be passed through a separate declarative animation configuration:

this.setState({newState: 'xyz'}).animate(animationConfig);

animationConfig could instruct the DOM reconciler how to update different classes of DOM attributes/styles. For example, You could do:

 var animationConfig = {
     // Any style property effecting dimensions (width/height/padding)
     dimensions: {  function: 'ease-in', durationMS: 500 },
     childAdded: {  function: 'linear', animateType: 'fade-in makeRoom' }
 };

Because we have a central place in the framework where we intercept all DOM mutations, we can make this work fairly easily.

One nice thing about this proposed API, is that it might give us the power to pierce through the encapsulation boundary of sub-components, without ever leaking implementation details. We're able to "animate the implementation details" of sub-components, but without ever assuming anything about their nature.

One tradeoff with this API is that I anticipate being able to perform animations very easily, but anticipate difficulty in getting animations to do exactly what we want with millisecond precision.

There's also other types of animation APIs that we can provide for situations where the animated properties don't pierce through the encapsulation boundary:

this.animateToState({chartSize: 500}, {durationMS: 900});

That would simply invoke state transitions within a requestAnimationFrame, and let the reconciler do the rest of the work (what it always does). There may be performance issues with this, but with the proper throttling, it may also be useful.

[chenglou]

This sounds like good news. I definitely think webapps is/should be moving toward animated interactions not just of individual components, but as a coherent unit. What worries me in this situation is how the DOM will be reconciliated and how it'll affect the rest of the flow.

Take todomvc for example. Ignoring the design of react's animation API, how would it achieve the followings?

• when a task is dragged around, the other tasks move accordingly to temporarily fill the spot previously occupied by the dragged task.
• when a task is completed and removed, it falls off and the tasks below move up (hell, maybe even one after another like people moving forward in a queue).

I'm really buying the idea of react, and I think it's a just natural progression to express HTML, then potentially CSS, and then animation all in javascript. I love the smoothness of CSS animation, but as todomvc showed, these kind of animated elements in normal js/CSS frameworks are still constrained to minimal eye candies such as color transition when applying a checkmark, or the x button growing bigger on hover. They're very bland and frankly, feel like web-grade apps (as much as I love the web).

To reiterate, I'm just worried that given react's (albeit extremely clever) diff rendering technique, the framework gets constrained in this aspect of UI. You know what would be a sick API? If we can somehow achieve the above two kind of animated interactions directly on top of the existing todomvc, without altering the structure of the app. Animations will only get ubiquitous if it doesn't interfere with the actual sketching of the app.

[jordwalke]

I totally agree!

[petehunt]

As far as "animations on unmounting" goes, I usually just toggle a "shown" or "visible" prop on an owner component instead of unmounting directly, since then you can do the transition first and then finally unmount. But YMMV.

As far as "animations in general" goes, I've prepared this example for you: https://github.com/petehunt/react-animations. It's a pretty performant way to tween your state, interpret touch gestures, and animate in a performant way. Let me know if this is helpful!

[WickyNilliams]

@petehunt i know it's an old comment, but your react-animations repo is 404ing

[chenglou]

@WickyNilliams pete removed it. You can still find the commits here

[WickyNilliams]

@chenglou thanks!