React-beautiful-dnd: Support hugely overlapping Droppables

[O4epegb]

Bug or feature request?

Possible bug, please check the demo.
I am not sure if such behaviour is supposed to work, maybe I should use something different for that :)

Expected behavior

Droppables are being selected correctly

Actual behavior

Very often higher positioned (z-index) Droppable (dropzone in demo) is not selected, but Droppable List underneath is selected instead.

Steps to reproduce

Just try to drag items from the list to dropzones at the bottom. Lists should be long enough that they overlap under dropzones, if they don't just try to add more items (there is a function at the top).

What browser are you using?

macOS Chrome Version 67.0.3396.99 (Official Build) (64-bit)

What version of React are you using?

"react": "16.4.1"

What version of react-beautiful-dnd are you running?

"react-beautiful-dnd": "8.0.5"

Demo

Very rough demo

https://codesandbox.io/s/yjp4zyjw3z

[alexreardon]

We currently do not consider z index when selecting the droppable target.

Overlapping droppables are not officially supported. A little overlap on the edges is fine, but the scenario you posted is not right now.

I'll convert this issue into a suggestion to add the feature 👍

[O4epegb]

Oh, that very nice, thank you! 👍

[ksloan]

We have this issue as well. We have want to allow user to drag cards between several "tabs", so we're showing/hiding the tabs when their label is moused over during a drag. However, when the card is dropped it's detected as being dropped on the original list even though it's been hidden/moved.

@alexreardon Any ideas how we could accomplish this? Thanks for your work!

[ksloan]

Example:

[ksloan]

Hey @alexreardon , do you have any ideas for work-arounds for this kind of scenario?

[artooras]

@alexreardon, you mentioned in your comment above that

We currently do not consider z index when selecting the droppable target.

Looking at the example posted by @O4epegb - and I have a conceptually similar setup, hence my interest in the issue - it seems (my assumption!) that the library is detecting the first DOM node wrapped in Droppable that is under a Draggable and triggers its interactions. Which, if z-index is not explicitly set, results in the library _always_ detecting the Droppable with a lower z-index simply because it's encountered first in the DOM tree.

If I'm reading the src correctly, you have an array of Droppables to check if the draggable is over any of those. The first Droppable you find() is the one returned. Perhaps doing a simple Array.reverse() before find() could solve this issue? Of course, needs to be tested, but... fingers crossed :)

[alexreardon]

Have a look and see how it goes!
On Sun, 9 Dec 2018 at 1:22 am, artooras [e-mail] wrote:

@alexreardon https://github.com/alexreardon, you mentioned in your
comment above that

We currently do not consider z index when selecting the droppable target.

Looking at the example posted by @O4epegb https://github.com/O4epegb -
and I have a conceptually similar setup, hence my interest in the issue -
it seems (my assumption!) that the library is detecting the first DOM node
wrapped in Droppable that is under a Draggable and triggers its
interactions. Which, if z-index is not explicitly set, results in the
library always detecting the Droppable with a lower z-index simply
because it's encountered first in the DOM tree.

If I'm reading the src
https://github.com/atlassian/react-beautiful-dnd/blob/master/src/state/get-droppable-over.js
correctly, you have an array of Droppables to check if the draggable is
over any of those. The first Droppable you find() is the one returned.
Perhaps doing a simple Array.reverse() before find() could solve this
issue? Of course, needs to be tested, but... fingers crossed :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/atlassian/react-beautiful-dnd/issues/655#issuecomment-445462836,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACFN7ZPehYzAh4QHGBFh6-GFqQsIbuTNks5u28sqgaJpZM4VWL4J
.

[artooras]

Hi. I managed to have some progress on the issue. As I expected, all it indeed was to reverse the array of Droppables. Changing the return value of toDroppableList method here from

values(droppables) // returns an array

to

values(droppables).reverse()

makes the example above work as expected.

@alexreardon, would it be possible for someone on the team to check if this change breaks any tests? I'm cautiously optimistic it doesn't. I wish I could do it myself, but I managed to glue together a working example on my machine - only just - and I'm surprised it even ran with all the errors my editor is throwing at me...

[treshugart]

Hey, @artooras. Alex will be back mid-jan. See #1010 for more details.

[artooras]

@treshugart any updates on this? #1010 also fails to shed more light...

[Arrow-Green]

@alexreardon Having z-index for prioritizing droppables would be good. I've a similar setup that could use this feature. Any workaround or updates regarding this?