There's been a few React animation experiments (including my own: 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.
Point #2 is especially spot on. Right now TransitionGroup clones every child [1] to preserve children for unmounting, but it's incredibly inefficient, especially if you have thousands of elements. Not to mention, as a side-effect, it requires wrappers to preserve refs. [2]
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?)...
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?
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 - 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!
[+] [-] chenglou|11 years ago|reply
- 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).
[+] [-] jefftchan|11 years ago|reply
[1] https://github.com/facebook/react/blob/master/src/addons/tra... [2] https://github.com/facebook/react/issues/1950
[+] [-] tomaskafka|11 years ago|reply
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?)...
[+] [-] colinramsay|11 years ago|reply
[+] [-] tomaskafka|11 years ago|reply
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 - 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!
[+] [-] kylemathews|11 years ago|reply