source.id and target.id are identical in "onDragEnd" event

[feroxbyte]

Description

When handling the dragend event from DragDropProvider, both event.operation.source.id and event.operation.target.id return the same value (the target's ID), even when the dragged item was moved to a different position.

This makes it impossible to detect whether an item was actually moved or dropped in place, as comparing source.id !== target.id always evaluates to false.

Reproduction

<script lang="ts">
  import { DragDropProvider, type DragDropEvents } from "@dnd-kit-svelte/svelte";

  const handleDragEnd: DragDropEvents<MyData>["dragend"] = (event) => {
    const { source, target } = event.operation;

    console.log("source.id:", source?.id); // e.g., "item-3"
    console.log("target.id:", target?.id); // e.g., "item-3" (same value!)

    // This condition is never true, even when items are visually moved
    if (source?.id !== target?.id) {
      // Reorder logic never executes...
    }
  };
</script>

<DragDropProvider onDragEnd={handleDragEnd}>
  <!-- sortable items -->
</DragDropProvider>

[hanielu]

Please provide a proper minimal reproduction on https://svelte.dev/playground

[feroxbyte]

Here is the reproduction link

[brandensilva]

I can confirm this indeed an issue on my end as well. My workaround which may not work for every situation was to use the index instead of target.id.

[brandensilva]

Since this was hot in my context window already, I decided to check see if it could locate the bug with Opus 4.5. If this is correct, it may be upstream from this package:

Looking at the OptimisticSortingPlugin in the @dnd-kit/dom package:

Root Cause (line 419 in sortable.js) :
// In the dragover handler, after reordering:
manager2.actions.setDropTarget(source.id) .then (() = manager2.collisionObserver. enable());

The Bug Explained:

1. When you drag a sortable item over another, the OptimisticSortingPlugin handles the dragover event
2. It reorders the DOM elements and updates the sortable indices
3. Crucially, it then calls setDropTarget(source.id) - setting the drop target to the SOURCE item's ID
4. By the time dragend fires, target.id === source.id because the plugin explicitly set them equal

This is actually intentional behavior for the "optimistic" live-reordering UX where items swap positions
visually as you drag. The problem is that consumers expect target to remain the item you dropped onto, but
the plugin has already "resolved" the sort and made source and target the same.

[brandensilva]

It indeed looks like an upstream issue @feroxbyte if you want to work around it.

Summary:
Aspect: Issue
Details: source and target are identical in onDragEnd

Aspect: Cause
Details: The library performs "optimistic DOM updates by default" - it repositions elements during drag.
When the drag ends, the target defaults to the dragged item itself.

Aspect: Official Workaround
Details: Use source.sortable.index and source.sortable.initialIndex instead of comparing source/target IDs
The maintainer confirmed that while DOM updates are automatic, developers should access position data
through:

• event.source.sortable.index - current position
• event.source.sortable.initialIndex - original position
• event.source.sortable.group - for multi-container scenarios

Referencing the source issue upstream: clauderic/dnd-kit#1564.