Support css transition of transform to final position

[martinpengellyphillips]

Currently the way onDragEnd works results in items jumping back to their original position before animating to their new position when a css transition is used for transforms. Investigate how to improve this so that the draggable transitions instead from its current dragged position. Perhaps by not clearing the transform on drag end immediately - instead do it in a queued microtask etc.

[jcuenod]

I would love to see something like this.

[martinpengellyphillips]

@jcuenod what in that link are you interested in for this issue? (I couldn't see anything that animated final transform.)

What I am thinking about here is more like this - note the dragged element doesn't jump to position on drop, but rather moves smoothly to it.

[jcuenod]

Sorry, I might have got the wrong end of the stick on this issue. I am hoping for animations of the "middle" (transitioning) state when two elements swap places while one is being dragged. I'm less concerned by the "final" transition tbh.

In sortablejs, this is evident in the simple list example but it also happens in the example you linked.

[martinpengellyphillips]

Ah, gotcha.

So you can use css transform transitions today for the swapping effect. The issue you'll see then is that on drop the dropped item will transition oddly, which is what this issue is about.

[jcuenod]

Gosh, I didn't even think of looking at how you were rearranging things under the hood. I just assumed you were changing the DOM, not adjusting styling. Makes sense. Thanks.

[martinpengellyphillips]

Update on this - I'm exploring two approaches currently:

A) Defer clearing drag state until after all onDragEnd handlers have executed. This removes the need to locally cache state for the purpose of determining positioning post drag for animation. But it also creates an oddity in that there is effectively a dragEnding state that some parts care about and others ignore. The entire system also has knowledge of animation embedded throughout as a result which will make it harder for consumers to customise.

B) Treat animation as an entirely separate concern. This approach attempts to do something similar to autoAnimate - it observes the dnd state and runs animations as appropriate. This is likely to be cleanest solution, but I'm still working through some complexity around changing nodes.

[martinpengellyphillips]

After extensive investigation, I'm going to pursue option (b) and have started foundations for that in 0.7.0. Option (a) ended up overcomplicating the code and expectations for consumers too much.

[membranobruno]

Hi. Any updates on this topic? Could you please suggest how I can add rotation for the object onDragStart?

[martinpengellyphillips]

This issue is about animating final transform - effectively after solid dnd has completed the drop.

For your case of rotation you should be able to add and remove appropriate style to the item using the draggable.isActiveDraggable property.

[membranobruno]

wow! Thanks, but seams I mess up a little bit. I’m trying to implement the transform like this

  onDragMove(({ draggable, droppable }) => {
    draggable.node.style.transform = "rotate(10deg)"
  })

but have no result.

[martinpengellyphillips]

I added an example to https://solid-dnd.com/ - see the "Custom transform (rotate on drag)" example for a rough approach @membranobruno

[tylermercer]

Are there any updates on the on-drop transform issue? I'm willing to hop in if help is needed—this would be great to have. But I'm not sure where to start or where this issue is at.

[martinpengellyphillips]

No updates - my focus has been elsewhere. I've got a bit more free time currently though so might take another run at it.

Happy to have some help :) The approach I want to try next is keeping this animation decoupled from the core. I see the https://github.com/formkit/auto-animate library as a good inspiration.

The main challenges are:

• By the time we get onDragEnd the drag is over and the transform clearing.
• Have to handle both the overlay and non-overlay cases.
• Sortables logic - especially when moving between containers.

Trying to sprinkle the logic to handle this throughout was brittle and confusing. That's why I want to see what an external 'observe and animate' approach could do.