is there anyway to get the old and new index of the moved item?

[YousefJalali]

is there anyway to get the old and new index of the moved item in the finalized event? it will be much better to send the old and new index to the server and do a swap there instead of sending the whole list.

[isaacHagoel]

The lib has the info about the original index but it could be an index in a different list (if you have more than one). It is not included in the event atm.
With that said, it is easy to get it on your own with just a few lines of code.
In the consider event check for the trigger and if it is DRAG_STARTED grab the id property from the event (the id of the dragged element) and find its index in the list before mutating the list. Use that id in the finalize event to find the new index.

[gregg-cbs]

This library should tell you the index where you moved from and where you are moving to. Its the basic concept of sorting. You need to know the from and to indexes to update the sort orders in the database appropriately.

[gregg-cbs]

Also looking at this payload, there is nothing in here about the original index:

[isaacHagoel]

@gregg-cbs you have the item id.
Before you assign the items from the payload of the event to the items in your app you can use the item id to trivially find the index in both.

[gregg-cbs]

No no. I went to sortable, they give you the "to" and "from" index, not sure why you want me to do a find on two different datasets when you know the indexes?

How many developers have to spend time struggling to get the indexes, reading the docs, coming to github, realizing they cant and then having to write the same find code over and over again. The amount of energy expended because you think a find is "trivial" is a lot... vs you just adding the "to" and "from" indexes to the detail because you should have them.

Sortable you do:

{
  onEnd: async function (evt) {
    await on_sort(evt.oldIndex, evt.newIndex)
  },
}

[isaacHagoel]

From the library point of view, while this can be added, it increases the surface area and adds room for bugs. items can move between lists and be copied on drag or on drop (by the user's code). In keyboard dragging the indexes change "one by one" rather than the jump you get when using a pointing device etc. The lib can report what it thinks the index was and should be, but in advanced examples (some of which appear on the README and people use them as a starting point) it would be more confusing than having user side code do it when needed based on their usecase. My policy so far with this lib was to only avoid adding pure syntax sugar.

…

On Wed, Dec 18, 2024 at 12:31 AM gregg-cbs ***@***.***> wrote: No no. I went to sortable, they give you the "to" and "from" index, not sure why you want me to do a find on two different datasets when you know the indexes? How many developers have to spend time struggling to get the indexes, reading the docs, coming to github, realizing they cant and then having to write the same find code over and over again. The amount of energy expended because you think a find is "trivial" is a lot... vs you just adding the "to" and "from" indexes to the detail because you should have them. Sortable you do: { onEnd: async function (evt) { await on_sort(evt.oldIndex, evt.newIndex) },} — Reply to this email directly, view it on GitHub <#559 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE4OZC72NYGEW3DR3534STD2GARUXAVCNFSM6AAAAABTSZLRZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBYGQ3TAOBWGA> . You are receiving this because you commented.Message ID: ***@***.***>