Transformed SortableContext yields an offset drag overlay

[ranbena]

When offsetting a SortableContext with css transform (for instance, when an open sidebar pushes it sideways), the drag overlay gets wrongly positioned.

Sandbox demo https://codesandbox.io/s/dnd-kit-offset-b2744

Originally posted by @ranbena in #205 (comment)

[ranbena]

Here's a demonstration:

Screen.Recording.2021-04-30.at.18.40.50.mov

[ranbena]

#379 allows consumers to configure how to measure the draggable node, so I gave it a shot:

const measuringConfig = {
  draggable: {
    measure: (element) => {
      return {
        ...getBoundingClientRect(element),
        left: getViewportLayoutRect(element).left
      };
    }
  }
};

The result is better - there is no offset during drag 🎉
BUT the drop animation sends the overlay to an offset position.
Sandbox code: https://codesandbox.io/s/dnd-kit-offset-with-measuringconfig-6ujp6?file=/src/App.js

Screen.Recording.2021-09-30.at.9.42.18.mov

[tflanagan]

This specific example is showing an x translation, but any translation (x/y) causes this bug.

A y translation actually induces another bug with detecting where the element is in the list. It seems to push the item to the bottom of the list, regardless of where the overlay is positioned.

[headfire94]

@ranbena did you find a workaround for animation?

[ranbena]

Nah, I'm avoiding the use of transform till it's fixed :/ (using a non-gpu property animation in the meantime)

[ranbena]

@clauderic in my original post I provided a reproducible sandbox demo.
I now upgraded the dependencies in the demo to @next but the issue doesn't seem to be fixed - actually even more offset.
Am I missing something?

---

Current: https://b2744.csb.app/
Upgraded: https://fzcdy.csb.app/

[clauderic]

Hey @ranbena,

The problem with your sandbox is that you're also rendering the DragOverlay component in the same transformed container, so it too is offset by 135px when we measure it.

It's generally recommended that you try to render the DragOverlay in a portal higher up in the DOM tree (document body or root element).

Here's a forked sandbox where that is the only change I made, everything seems to be working: https://codesandbox.io/s/dnd-kit-offset-forked-hbtwb?file=/src/App.js

[ranbena]

Understood. I'll try that 👍

[ranbena]

Works! 🎉

[riledigital]

This was really helpful! I had the same exact problem that was caused by some combination of flexbox layout containers. I'll see if I have time to PR a note about this being a good use case for React Portal in the dndkit docs article for DragOverlay.

Edit: I found the documentation repo and see that a Portal example is in there!

[RahulRana0707]

@clauderic what if the same issue of @ranbena occurs inside a modal of mui. As I am implementing dnd-kit inside the modal.
If we createProtal the dragoverlay stays behind mui modal is their any solution for it?

[fmukaba]

@RahulRana0707 Did you figure something out?
I am facing the same issue with using dnd kit in a React Modal - the overlay shows up behind the Modal

[rrajaste]

@RahulRana0707 @fmukaba Sorry for the late reply, but I was facing a similar issue with both a modal and drag overlay being portaled and directly attached to root div causing drag overlay to appear behind the modal.

I solved it by increasing the z-index of the drag overlay to be greater than that of the modal. Hope this helps someone.

Modals typically have a rather big z-index set by default so they appear over everything else so you might need to set the z-index of the drag overlay to be pretty big as well.