Here's a rough draft proposal for an extension to the animated component that can handle both simple and advanced FLIP use cases.
Initiate a FLIP animation on a component by updating the flipKey prop.
Match unconnected components across renders by making sure they share the same flipId prop, and when one unmounts and the other mounts, they will be connected with a FLIP animation.
Occasionally, like in the example below, users will want to be able to FLIP pre-existing springs, if for instance a FLIP could be interrupted by a drag.
The api allows for this as well, by passing in a flipSet prop in addition to a flipKey or flipId.
This is a first draft of the code wrapping the animated component to make the above three use cases possible.
The AnimationHandler outer wrapper attempts to simplify the most common use cases. However, if you pass in the flipSet prop you can bypass this
to get total control of the animation to facilitate interruptability and more complex effects.
- Think about improving or simplifying
flipId/flipKey/flipSetapi. - Figure out chained staggering of FLIP components and/or whether it is necessary (react-flip-toolkit supports it).
- Figure out how to lazily import FLIP functionality into
animatedso as not to bloat the bundle for users who don't need FLIP. (or perhaps just have aFlippableAnimatedcomponent or similar?) - Make the springs customizable for abstracted FLIP cases (like examples one and two). this would be easy with a
flipSpringprop or something but that might start making the api too complex.
Thank you both for your comments!
@aleclarson, I would defer to you on using hooks. It looks like the api you're proposing in your first example would be focused on list re-ordering, though, which is only one possible use case for flip.
In your second example of animating two separate components, i'm not sure I understand what the benefits using hooks over a wrapper component would be, or why
would necessarily be superior to
@dbismut one issue with using flip to animate to
height:autois that FLIP uses transforms, which won't affect the layout of the rest of the page. So you will get a very different looking animation if you usescaleYversusheight. Maybe that's an ok tradeoff, but I would just want to know what sort of effects people were hoping to achieve. I guess in my head I think of animating toheight:autotypically is for something like this collapse, which wouldn't work as well as a flip animation. Was that sort of what you were thinking of or did you have other types of animation in mind?