drag don't work after ajax refresh

[rogeecn]

in my work there has to area A and B , A has some dragable elements, but A don't accept drop action, B has some elements too, but the elements in area B can drag and drop any where but cant drop to area A. when i refresh the area B twice ,via ajax the elements in area A cant't be drag to area B , the elements in area B can't do and drag and drop job (only work in first time);

here is the area A code:

$(function(){
        $(".ext_list").sortable({
            group: 'ext-drop',
            drop: false,
            onDragStart: function (item, container, _super) {
                console.log(container, container.options);
                // Duplicate items of the no drop area
                if(!container.options.drop)
                {
                    if(container.el.hasClass('ext_list'))
                    return false;
                    item.clone().insertAfter(item)
                }
                _super(item)
            }
        });
    });

here is the area B code which load via AJAX:

$(".group_wrap .position_extension_list").each(function(){
            $(this).sortable({
                group: 'ext-drop',
                handle: 'i.icon-move'
            });
        });

[karimlahlou]

I think you need to re-call A again while you are in ajax call, simply wrap the A as function and insert it in ajax.

[johnny]

@karimlahlou is on the right track. The plugin is bound to loaded elements in the DOM at the moment. Since the behavior you desire is quite common, and I have been hit by the same limitation, I will try to fix this.

As a temporary workaround (which will continue to work)

// Destroy the old sortable
$(".group_wrap .position_extension_list").sortable('destroy')

// after the new DOM nodes are insterted, initialize sortable again
$(".group_wrap .position_extension_list").sortable({ ... })

You do not need to manually iterate over the elements. The sortable plugin does this for you.

[duluca]

I have a similar problem on a Backbone SPA, first time everything works great, but if I navigate away and then come back to the page (doesn't matter if the page re-initialized or just re-rendered), then my drop targets doesn't work. Items I drag return to the list I pulled from (which is not a dropable list). I tried .sortable('destory'), but it doesn't do anything for me. I tried to run it after initializing for the first time to see if it broke the sortable functionality, but everything worked fine.

Any suggestions on how to approach my issue would be most welcome.

[johnny]

Which version are you using? destroy is only supported in the master branch and I have not released it yet.

[duluca]

0.9.11 - I cloned the master and tried destroy again, but still it didn't do anything for me.

[calliePepper]

Same problem here, I use the sortable call after an ajax refresh which seems to work perfectly. However without a way to destroy / fully unbind all the previous calls I end up with massive memory issues (over a long time). Tried using 0.9.11 and see the same issue.

[mrpohoda]

I have the same problem. Destroy does not help. Tries 0.9.11 and master which has destroy in its source code.

[pascoual]

Same here on a meteor project.
First time is ok but if I navigate on other pages and come back, drop is broken.

Symptom:

• isValidTarget : container is never the right one (like if the container is not initialised sortable)
• onDrop : has a empty container (null)
• destroy don't solve the issue (with last version from pull request 6 days ago)

How can I help ? Johnny, do you want me to check something in the console when it's broken ?

[pascoual]

Seem to have found the problem after some debugging time.
Meteor destroy template and if we need it back later, re-render it.

Just need to call destroy in the right place, in Template.myTemplate.destroyed instead of just before re-init sortable in Template.myTemplate.rendered function.

So not a bug from sortable ;).
Thanks Johnny for your plug-in !

[giobaldac]

HI. I had the same problem. After some debugging I found that the issue was in ContainerGroup array which never was cleaned. I solved it by changing the name of the container group on every redraw/page change.
Assuming you have two sortables you want to connect, here's the workaround (look at the three commented lines):

var currDate = new Date().getTime(); // important! get current time in msec
$(sourceEl).sortable({
group: "my-group"+currDate, // using a new group every time
onDrop: function (item, container, _super) {
_super(item);
}
});
$(targetEl).sortable({
group: "my-group"+currDate, // using the same new group every time on both sortables
onDrop: function (item, container, _super) {
_super(item);
}
});

At least for me it worked.

[HandyAndyShortStack]

I had a similar issue with my Backbone app. In order to get it working properly I first had to store a randomly-generated sortable group id string on my app's global object. I had to call .sortable('destroy') on all the sortable elements after each AJAX refresh, generate a new sortable group id string, then call sortable again on all my sortable elements using the new group id string. It is hacky, but much less work than finding a new sortable library at this point.

[noelblaschke]

I have an issue like that.

I've got n-rows that can contain n-elements per row. If I re-render the row's view or element collection's view, sortable doesn't work anymore for those elements. So I started to initialize it again on each change/re-render, but it works only if I remove the group option and than I'm unable to nest elements into other rows.

Update:
Subsequent instantiations of further containers in the same group do not change the group options.

So I had to create a new group named by timestamp (as giobaldac mentioned) or just find a way to destroy all old sortables and reinitialize again with the wanted group.

[miguelmanzano]

Thanks I got the same issue and with this fix works fine.