Add didLeave method to <TransitionMotion />

[hkjorgensen]

Had a case where the index of each element was essential for correct visual representation. didLeave can be used to keep track of what elements <TransitionMotion /> is still animating.

Can also be used as the onRest equivalent for <TransitionMotion />.

[hkjorgensen]

@nkbt @chenglou do one of you have time to take a look?

[chenglou]

Will do tonight!

[chenglou]

Alright, this looks good. Tbh I've forgotten a big chunk of the codebase. Since the tests pass this is non-breaking, I can merge it. But before that, are we sure about the name here? DidLeave vs onRest?

[souporserious]

I like onRest to match the Motion component.

So excited for this! This will allow me to do auto height animation in the UI pack 🙌

[DetweilerRyan]

didLeave seems to be a more appropriate name than onRest. To me at least, onRest implies that the TransitionMotion component as a whole is no longer in motion. While, on the other hand, didLeave implies that a single child has finished transitioning out of the TransitionMotion component, yet other children may still be in motion.

[hkjorgensen]

didLeave seems to be a more appropriate name than onRest. To me at least, onRest implies that the TransitionMotion component as a whole is no longer in motion. While, on the other hand, didLeave implies that a single child has finished transitioning out of the TransitionMotion component, yet other children may still be in motion.

@DetweilerRyan, that was also what I thought when naming it 'didLeave' :-)
onRest would be misleading compared with <Motion onRest />.
Next, I would suggest/PR for a didEnter, and those two combined would allow for a proper onRest implementation.

@chenglou do you see react-motion as abandonware? I still believe it's one of the best packages for doing spring animations in React. The spring logic is solid, but there is always room for further development for the API :-)

[chenglou]

I'm aggressively cautious about adding API overhead. TransitionMotion's API has a bit of learning overhead already and I didn't want to add more to it. Lots of people add an animation to their project then move on, so having a stable API throughout time in a (whether I want it or not) flagship react project might be worth more than finding a neater API that breaks dependents every few months. Just doing my part of not adding churn =)

Personally, I'm overwhelmed with emails lately so even pings against me might go unnoticed. Trying to catch up though. Also I've been working on some important react-related work lately too (will be open-sourced this week. It's gonna change everything!). But I have to apologize for the codebase quality too. It's not exactly straightforward to navigate it I feel. Feel free to submit more PRs though! And ping me about them!

Thanks a lot for this PR. I'll be merging this. Do we want to make a new release?

[souporserious]

Yes to a new release please 🙏 thanks for this @hkjorgensen!

[hkjorgensen]

@chenglou Thanks for the explanation - I still look forward to that new open source project :-)

Thanks a lot for this PR. I'll be merging this. Do we want to make a new release?

Yes, please cut a new version. This expands the API and doesn't break anything :-)

[chenglou]

Ok, published as a patch update then! Tell me if anything goes wrong, thanks.