Here's a rough draft proposal for an extension to the animated
component that can handle both simple and advanced FLIP use cases.
Example usage
1. Simplest example
Initiate a FLIP animation on a component by updating the flipKey
prop.
2. Two different components example
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.
3. Advanced custom spring example
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
.
Proposed extension to animated component
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.
To do:
- Think about improving or simplifying
flipId
/flipKey
/flipSet
api. - 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
animated
so as not to bloat the bundle for users who don't need FLIP. (or perhaps just have aFlippableAnimated
component or similar?) - Make the springs customizable for abstracted FLIP cases (like examples one and two). this would be easy with a
flipSpring
prop or something but that might start making the api too complex.
@aholachek many thanks for this. Take my comment with a grain of salt, I may have a very naive approach on FLIP!
1. Simplest example
I'm not sure how this is related to FLIP, but I was hoping that this potential PR could animate
auto
. I know some people ask why this doesn't work withreact-spring
:The above makes me think that maybe we could get rid of
flipKey
in the first example if we delegate the animation touseSpring
... Of course the upgradedanimated
component needs to know when to measure its bounds, but in that casegetSnapshotBeforeUpdate
would work here I guess?The problems I anticipate:
flipKey
guarantees that this would only happen whenflipKey
has changed, but I don't know if this would lead to a major performance issue.const [spring, set] = useSpring(() => ({...}))
then it wouldn't trigger a re-render and thereforegetSnapshotBeforeUpdate
wouldn't be of any use... I don't know howanimated
could be aware ofset
being called.2. Two different components example
I'm not exactly sure how the previous example would translate API-wise, although this might work?
Again, this might be stupid or naive, I haven't dug too much in the internals of
<FlippableAnimatedDiv />
and I would understand that this might not work for you. But I like the idea of being able to separate the animation (useSpring
) from the component!