React.js: VelocityTransitionGroup, a replacement for ReactCSSTransitionGroup | Hacker News Reader

React.js: VelocityTransitionGroup, a replacement for ReactCSSTransitionGroup

gist.github.com

60 pointstomaskafka9 comments

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.

(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).

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?)...

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".

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]

[1] https://github.com/facebook/react/blob/master/src/addons/tra... [2] https://github.com/facebook/react/issues/1950

Naive solution: What if every child had an intermediate parent node, something like:

    <Transition current={this.state.mode}>
      <TransitionItem name="map">
        <Map .../>
      </TransitionItem>
      <TransitionItem name="list">
        <List .../>
      </TransitionItem>
    </Transition>

By making the possible children explicit, you can preserve them in the virtual DOM as long as is needed. The actual child (Map and List) would be mounted/unmounted only as needed.

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!

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

+1 to an NPM package. I really like Velocity so would like to have this package handy.

Reply on news.ycombinator.com