Vue.draggable: Cancelling move doesn't revert element to original position

Created on 16 Apr 2020  路  3Comments  路  Source: SortableJS/Vue.Draggable

When an element is not allowed to be moved to a position, it should revert back to it's original position which is not happening.

https://jsfiddle.net/clemsontiger/cmn8p9va/7/

Steps: Drag element Three to position 1

What is happening: Three is not allowed in position 1, but ends up being listed in position 2 after Three is not allowed in position 1.

What I would have expected to happen:
When intention of user is to try to move an element in a position of 2 or greater into the top position, it should not be allowed and the element being moved should revert back to its original position: i.e. if moving element Three to position 1, do not allow and then revert element Three back to position 3 (its original position).

So when one drags element Three up the list, it obviously hits position 2 first due to how the dragging works, even though user is not intending to put the element in position 2. Since the user has not let go of (dropped) the element into position 2 and instead tries to move the element into position 1, when it is cancelled, it should revert the element back to its original position (in this case position 3), not leave it in the previously allowable position as it is doing now.

How do I get the element to revert back to it's original position when it encounters its move being cancelled? Should I not be using the move event for this? I feel like I'm completely missing something obvious here.

Most helpful comment

Dragula didn't prove as quick of an implementation as I wanted, so I attempted the dirty solution you suggested, more or less, and got what I wanted. I feel a bit dirty myself that the (wrong) drop actually happens and then I revert it, but it does work and I don't actually see it get dropped visually into the wrong slot. I set a temp array on @start, then set a flag on move when I cancel the original move that I don't want to allow, and then on @end I check the flag and reset to the array it was on @start. I didn't notice that I had to hide the ghost or dropped element at all during this.

This will do for now, but I can hope and dream that this issue will be fixed in the future.

All 3 comments

Doing a quick search in this repo indicates that this has been asked many times but the past issues have all been closed with a non-answer, my guess is that this bug is impossible to fix/won't be fixed anytime soon. It seems that this library has some sort of bug where the element is moved
right after :move but before @end, while the expected/default behaviour in Sortable.js is the opposite.

A really dirty solution would be to store the dragged object in an array if the move should be cancelled, allowing the move but using a css property to hide the ghost element and dropped element, and then binding to @end to move the element back to where it originally was.

I'm obviously not searching for correct terms then, as I did search the repo (as I always do before posting a question) and didn't hit on anything that sounded like mine. Anyway, thanks for the response along with the suggested solution. A little more than what I want to do to get around the issue, and I've seen someone else abandon this repo in favor of dragula, I'm going to try that as well.

Dragula didn't prove as quick of an implementation as I wanted, so I attempted the dirty solution you suggested, more or less, and got what I wanted. I feel a bit dirty myself that the (wrong) drop actually happens and then I revert it, but it does work and I don't actually see it get dropped visually into the wrong slot. I set a temp array on @start, then set a flag on move when I cancel the original move that I don't want to allow, and then on @end I check the flag and reset to the array it was on @start. I didn't notice that I had to hide the ghost or dropped element at all during this.

This will do for now, but I can hope and dream that this issue will be fixed in the future.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Kuohao-wu picture Kuohao-wu  路  3Comments

Kgwkgwkgw picture Kgwkgwkgw  路  3Comments

tomdong picture tomdong  路  3Comments

ghost picture ghost  路  3Comments

Leadaxe picture Leadaxe  路  3Comments