Finalize callback is called with some delay

[benkuper]

Hello, I'm building a flexible UI editor using svelte and this lib is great !

I have different containers with different layout types (horizontal, vertical, grid and "free" which is absolute positionning).
Almost everything works very well, except the free layout : I need to specify the top/left absolute position on drop so that the dragged element goes exactly where it was dropped.
I managed to use consider and finalize callbacks to set the properties of the element, but whatever I use, either the placement or the timing won't be good :

• if I only set top/left in consider(), the events are not called often enough so that the last set position is actually the drop position
• if I only set on finalize, the object will first go to its previous top/left, then will animate to its good top/left, because finalize is called with a delay.

Is there a callback that is called either on each mouse move (including the even detail), or a "drop" callback that is called right after the mouseup (at least before it's animated) ?

I think both implementations would be great, as it seems from the different issues that getting more info on mouse and dragged element when dragging is of interest to many people :)

Thank you !

[isaacHagoel]

Hi Ben,
Can you make a simple REPL that demos the issue?
I might be able to help you get what you're after without any changes to the lib or if changes are needed having the demo will help me test any change I make to make sure it works for this usecase.

[benkuper]

very reactive, thank you ! I'll make that

[benkuper]

Here you go :
https://svelte.dev/repl/040c04b8d7744ddf886ceab2bd2a87a4?version=4.2.15

What I understand from this is that finalize is called after the last animation which is of length flipDurationMs
It would be great to have a call before this animation.

Ideally, having both mouse information and DOM element in the callbacks event object would make everything easier and cleaner for this kind of manipulation

[isaacHagoel]

From the libs perspective what happens is the element is dropped outsize of any dndzone and should return to its original spot. One feature that was discussed before (I don't remember why it wasn't merged but can try to dig it up if needed) is the ability to cancel the final animation to place but...
I would like to suggest that in your scenario it would be easier to implement absolute dragging as a separate action without using the library at all because 99% of the features of this lib are not only unused in this scenario but actively get in your way (e.g keyboard dragging would work incorrectly as well as the accessibility features, if you drag over a zone stuff inside would try to respond etc). What am I missing?
If this is a legit suggestion I am happy to show you how to do that. It doesn't require creating a new element like the lib does, just listening on mousedown, when that happens attaching a mousemove listener that updates the top and left coordinates of the original element (and then adding touch and keyboard support which is straightforward as well).

[benkuper]

Thank you for your answer.
I simplified the scenario for the sake of showing the problem with absolute positionning, but that's not the only thing I need.
I'm mixing different layouts, one of them being absolute.
You can see some manipulation here (and the same problem as in the REPL) :
the canvas with absolute positionning is the one with the small UI elements and light grey background

The other thing that I want to implement that I can't seem to do is being able to "snap" to some position depending on the neighbouring elements (in the absolute canvas), so it makes it easier to align elements.

[isaacHagoel]

I see.
So sounds like you need the following:

1. A new option to cancel the drop animation
2. Getting the final mouse position or element boundingRect as part of the payload of the finalize event
   Correct?

[benkuper]

yes :)
additionnally, being able to have a callback that is the same frequency as mousemove and containing the information about mouse/element would help a lot to create "drag-aware" live visual while dragging.

I think in general, adding more information to the callbacks (and more frequent callbacks) would allow users to be more free to create more specific scenarios

[benkuper]

Actually it's not really cancelling the drop animation (though it would be a nice option), but being able to run code before. Let's say I would want to force it to a certain snapped position instead of exactly where I dropped it, then I would want to set its top/left just before the drop animation occurs. It should then just go smoothly to the target position

[isaacHagoel]

Can you define how that would look like? Changing the order/timing of the events could break other stuff

…

On Tue, May 7, 2024, 18:14 Ben Kuper ***@***.***> wrote: Actually it's not really cancelling the drop animation (though it would be a nice option), but being able to run code before. Let's say I would want to force it to a certain snapped position instead of exactly where I dropped it, then I would want to set its top/left just before the drop animation occurs. It should then just go smoothly to the target position — Reply to this email directly, view it on GitHub <#572 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE4OZCYPPWYB2TOCWK4NVIDZBCEOPAVCNFSM6AAAAABHI3K47KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJXG4YTEMRZGI> . You are receiving this because you commented.Message ID: ***@***.***>