Transferring TransitionGroup Maintenance

[gaearon]

We haven't been good at maintaining ReactTransitionGroup as we don't use it much at Facebook.

As a result it's stagnating: the bugs don't get fixed, new features don't get added, APIs don't acknowledge changes in React (e.g. fake lifecycle hooks that can't work on functional components), nobody has the time to review PRs to it, and it's like a dead weight on the core team. We all feel guilty about it but there's not much we can do.

There are some great alternatives in the ecosystem such as React Motion. However we understand there are a lot of people who are happy with TransitionGroup as it is.

This issue is a call for a new maintainer. If you are using TransitionGroup widely in your codebase and would be happy maintaining a fork of it and documentation, please let us know here, and we'll deprecate our package in favor of your package.

[developit]

I don't use it either, but I wanted to drop a link to a refactored standalone version I put together here because it'd make a pretty compelling starting point for anyone looking to maintain a standalone version of ReactTransitionGroup:
https://github.com/developit/preact-transition-group

It's obviously for Preact, but forking it to work with React again would basically just be changing the imports and dependencies to point to React instead.

It was originally a fork of react-component/css-transition-group, extracted from the React 0.14 source.

[fjckls]

So what do you use at Facebook? React Motion? Does that mean that the end is in sight for < ReactTransitionGroup> and we should start refactoring our code in favor of react motion?

[gaearon]

So what do you use at Facebook? React Motion?

The Facebook product itself doesn't have many insertion/deletion animations so we don't use anything much.

Does that mean that the end is in sight for < ReactTransitionGroup> and we should start refactoring our code in favor of react motion?

No, why? Even if we completely stop releasing new versions it won't be any worse than it is now: effectively it's already been abandoned for a year or so. You can keep using it, or fork it yourself if you want to improve it. In fact this is what the issue is about.

[fjckls]

For us animation itself is not a problem we're using great GSAP tweening engine. The problem comes when we have to animate out component on removal. React motion almost solves this problem - there is only one issue with React Motion- there is no onRest callback for TransitionMotion....
Anyhow there will never be 100% perfect solution out of the box... so will have to invest some too :)

[jquense]

me and @taion might be interested in maintaining, I've copy and pasted and forked this component so many times . It'd be nice to make direct improvements.

We also already have a similar but different Transition component we maintain in react-overlays

[gaearon]

@jquense This would be amazing, you've done some great work maintaining React libraries.

[jquense]

ok 👍 we are glad to take over maintenance.

My initial thought is to move it to https://github.com/react-bootstrap/react-overlays since it pairs nicely with the Transition component there, one for single components, and TransitionGroup for lists. We can also keep it a separate repo if necessary, but I think if folks only want that component requiring it individually from the suite shouldn't cause to much friction.

[gaearon]

Would you like to do it under reactjs org? My concern with react-bootstrap org is people will think it's going to require Bootstrap, or something like this.

[taion]

Tangential, but we would prefer to move react-overlays under reactjs – potentially replacing react-modal: reactjs/react-modal#156.

[jquense]

under reactjs is 👍 It might make sense to pull Transition out of react-overlays into an anaimation specific package since it doesn't have to do specifically with overlays :p

[gaearon]

What would be our next steps? Do you need any help with the forking?

[beckiechoi]

Not sure if it's too late to mention this. At Squarespace we have our own version of transition group which essentially uses the same approach, but is not a fork of ReactTransitionGroup. We were planning on open sourcing the library in near future (we will have to go through appropriate compliance to open source it). It's something we use pretty heavily on our platform, so all the bugs that were found have already been straightened out. @gaearon Will you be interested in favoring that?

[jquense]

I think there is probably room for both :)

from my end helping folding would great. Im not sure the best way to split the code out or of there is a feasible solution to keeping the current git history

[gaearon]

I wouldn't worry about keeping the history.

[beckiechoi]

Sounds good. I'll keep you all updated.

[jquense]

@gaearon works for me, if you want to add me to the organization I can move the code or I can bug @taion to do it :P

[ghost]

@gaearon, I think if react adds ability to return a promise in componentWillUnmount hook for delay unmount stuff and then there will be no needs to use ReactCSSTransitionGroup which uses internal react api anyway

[gaearon]

@bgnorlov

if react adds ability to return a promise in componentWillUnmount hook for delay unmount stuff

Sure, but this is tangential to this thread. You can discuss deferred unmounting in #6003.

which uses internal react api anyway

This is not the case as far as I know.

[jquense]

starting at: https://github.com/reactjs/react-transition-group

[taion]

can someone with access add @jquense to the @reactjs org?

[gaearon]

I added @taion, @jquense and @beckiechoi to a new "react addons" team that has admin access to https://github.com/reactjs/react-transition-group.

[levithomason]

Should this issue be closed then? Any open issues regarding maintenance and future TransitionGroup support?

[gaearon]

Yep, let’s close. Further issues about TransitionGroup should be filed against https://github.com/reactjs/react-transition-group.

We haven't deprecated ours officially well but we likely will.