Currently with <transition-group> you can build great JS-only transitions, but there's no way to hook into Vue's move functionality.
A hook/callback ( move or beforeMove ?) would be extremely handy allowing for custom JS to handle the FLIP when items need to move.
The hook would ideally receive an array of elements that will be moving and an array with the calculated positions/offset that Vue already builds for the CSS FLIP, and if Vue needs it, a done callback.
Based on a quick look at the <transition-group> code, this should not add much weight since Vue is already collecting all of that data.
Possibly related to #5813 or #4885 but this seems distinct.
<transition-group name="flip-me" @move="myFlipMethod"> ... </transition-group>
methods: {
// Hook receives an array of elements and an array of the position data
myFlipMethod(elements, positions, done) {
// Custom GSAP animation to move the elements, allowing for staggering and fancy effects
var tl = new TimelineLite({ onComplete: done });
elements.forEach( (el,i) => {
tl.from( el, 1, {
x: positions[i].dx,
y: positions[i].dy,
ease: Elastic.easeOut,
delay: i * 0.01
});
});
}
sorry my fault
Unfortunately, FLIP animations are entirely CSS transition driven and it would be very difficult to provide a JS driven API with the same behavior. It would also likely bloat the codebase further. In the future we may split the transition system out as standalone packages so that we can add more opt-in features to it.
However, is there any callback at the moment? There are scenarios like recalculating a scrollbar, e.g., where such a final callback would be really handy...
It would be nice to have something along the lines of "beforeMove" or "afterMove" to apply any kind of pre/post logic desired. For example, it would be nice to be able to set the zIndex of all my elements before and after a transition, because I want a column-stacked list to have the higher cards move "behind" the lower ones when re-organizing.
Most helpful comment
Unfortunately, FLIP animations are entirely CSS transition driven and it would be very difficult to provide a JS driven API with the same behavior. It would also likely bloat the codebase further. In the future we may split the transition system out as standalone packages so that we can add more opt-in features to it.