

React.js: VelocityTransitionGroup, a replacement for ReactCSSTransitionGroup - tomaskafka
https://gist.github.com/tkafka/0d94c6ec94297bb67091

======
chenglou
There's been a few React animation experiments (including my own:
[https://github.com/chenglou/react-tween-
state](https://github.com/chenglou/react-tween-state)), but I think there are
two main problems here and this library, albeit nice, is mingling the two:

\- Actual transition API (e.g. fade in over a period of 1s while moving in
from left). Interruptible and composable. My lib and most libs I've seen are
geared toward this.

\- API for transitioning in/out and moving around. This is the actual hard
part that TransitionGroup is trying to tackle. How do you express an
"animating out" API (that's also interruptible?) when the item doesn't exist
anymore at the next render? Can you stop the component from unmounting midway,
and potentially bring it back through an "un-unmounting" API? I haven't seen a
library that actually tackles this problem. We can debate about a good API all
we want for animation but as long as this problem isn't solved, the whole
animation problem isn't imo.

These two are separate issues. Ideally I think you should pull out the
velocity part and create a wrapper API around it, and solve transitioning
in/out independently.

(I'm actively searching for solutions, so please ping me in #reactjs if you
have good ideas. Here are a few messy ones to begin with:
[https://gist.github.com/chenglou/40b75d820123a9ed53d8](https://gist.github.com/chenglou/40b75d820123a9ed53d8)).

~~~
tomaskafka
Thanks, this is important, but definitely out of scope of my tiny component.

Stoppable and revertable transitions - does it really need to be a same
component (A:child -> B:parent -> A:child)? Wouldn't adding another component
instance with a same props suffice (A:child -> B:parent -> C:child)? Then I
guess it could be hacked with transitions, but if you require (A -> B -> A),
then it seems to me like something that would need some support from higher
layers (router?)...

~~~
chenglou
I don't think it has to do with router; just pure, simple state (router is
just another part of a component state anyways).

For your example, I think it should support both. You can distinguish an A
from another A through a different key or something. If it's the same key,
you'd want it to "unmount back".

------
colinramsay
Excellent. I was looking at CSSTransitionGroup a few days ago and would have
definitely have used this if it was available. Baking in a couple of default
transitions is a great idea. Are you planning on creating an npm package?

~~~
tomaskafka
Thanks, guess I could, this is just a result of 2 hours fighting with bugs in
iOS Safari's CSS transitions. Compared to that, velocity JustWorks™.

However, I'm not sure about how to let user provide his own transitions,
especially in cases where they'd like to use this in multiple controls - would
something like require('velocity-transition-group')({ myTransition: {...} });
work for you (so that we wouldn't be passing transitions to each instance)?

Plus, there is this issue I found:
[https://github.com/facebook/react/issues/2456](https://github.com/facebook/react/issues/2456)
\- it seems that if eg. you use require('react') while a component uses
require('react/addons'), they both seem to get 2 different instances of React,
and the events don't propagate from one to another. I'd like that to be
resolved before packaging this into module people will use without reading the
manual :).

Edit: Thinking over it, I also need to read about how does browserify + react
+ components as standalone modules work out: Can it happen, that if a
component specifies 'react' dependency in package.json, and containing project
uses different version of React, that browserify would actually package 2
versions of React into a resulting file? That would really really suck!

~~~
colinramsay
Not to mention that if you want cross-browser animation then you'll be using
vendor prefixes with CSSTransitionGroup.

