Relocate event does not fire on parent change

[Rene-Sackers]

I've created a JSFiddle here. When you drag Item 1.1 as child to Item 2, it does not trigger the "relocate" event.

It does, however, when you change the order of Item 2.1 to below Item 2.2.

It seems to be in this section:

if (!(this._pid_current === this._uiHash().item.parent().parent().attr("id") &&
    this._sort_current === this._uiHash().item.index())) {
    this._trigger("relocate", this._relocate_event, this._uiHash());
}

I honestly have no clue what this if statement is supposed to do, or mean, so I'm a bit afraid to touch it. Any chance you can look into this?

Great library otherwise.

[Rene-Sackers]

Simply removing the if statement in its entirety seems to help (of course leaving the trigger), but are there any consequences to this?

[KarelCemus]

I confirm the issue.

I honestly have no clue what this if statement is supposed to do, or mean, so I'm a bit afraid to touch it.

Btw, I debugged it and IMHO you can safely remove it. I guess the following meaning:

this._pid_current === this._uiHash().item.parent().parent().attr("id")

_pid_current should contain the id of the source list, while the right side reads id of the target list.

this._sort_current === this._uiHash().item.index())

_sort_current should contain index of the item in the source list and the right side reads the index in the target list.

IMHO the issue occurs when there are multiple lists without ids and the movement among them on the same level. Then the condition results in if ( ! (undefined === undefined && index === index ) ) which is always false that is why the event is not fired.

If my explanation is correct, there is only one consequence of the if removal: The event will we fired even when no actual movement is performed, i.e., when the position remains same.

[lllopo]

I confirm - if you use other than 'id' attribute ... something like 'data-id' or something - th eproblem occurs. The attribute shouldn't be hardcoded, since other stuff like toArray method make it flexible.

[ilikenwf]

Put in a pull request to fix it?

[KarelCemus]

Any suggestion how to workaround this consequence?

The event will we fired even when no actual movement is performed, i.e., when the position remains same.

I think of keeping this with && id !== undefined. That would reduce the impact of this consequence to trees without ids. But still it is not optimal. Thoughts?

I'd create the PR then.

[lllopo]

This won't help, as it will effectively turn of the identification of the leaves. The real solution would be to add an option to define the ID holding html attribute (same as the one used by toArray), default it to 'id' and use it on both places - in relocate and _clear methods.

[KarelCemus]

Would you take care of it, @lllopo? Sounds you've thought it through.

[Substractive]

Good day , I encountered same problem since there is no official fix for that I created workaround outside the plugin, for my case I have used update function and there I retrieve id of the item that is moved after that jQuery grab that item and find it's parent..

Here is my example if someone is curious.. $('.sortable').nestedSortable({ handle: 'div', items: 'li', maxLevels:0, toleranceElement: '> div', update: function(event,ui) { treeChange(ui.item.attr("id"),$("#"+ui.item.attr("id")).parent().parent().attr("id")); } });

[FlameArt]

It is true: after i added id attribute to a <li> elements, problem had been solved.

[ghost]

I was experiencing the same issue, the solution suggested by @FlameArt did the trick. I simply added <li id="*someid*">···</li>