Allow collision with drag overlay node rather than activeNode

In our application it’s a frequent occurrence that things that can be dragged/sorted together are of different sizes. These sizes can differ radically and unpredictably and therefore make the dragging experience with a “presentational component” of the underlying node pretty bad. As an example, imagine dragging a giant rectangle from one container grid into a different container grid of many tiny squares. The large rectangle covers many of the squares during the drag, making it hard, from both the user’s perspective and for the collision detection, to precisely drop where you want.

For this reason, and to provide additional contextual information about the thing being dragged, we’ve opted to go with a statically sized drag overlay that has no relation to the underlying node being dragging. It’s small in size, contains an icon indicating what’s being dragged, and the number of items that will ultimately be affected by the drag.

Our issue is that DragOverlay is sized based on the underlying node that started the drag. We can fix this stylistically by passing a style prop, but the ViewRect that is passed into collision detection is still from the underlying activeNode. This makes collision computation inaccurate in relation to what the user actually sees (our small, statically sized child of DragOverlay).

I can see a few paths forward for making this experience better, but would love to get @clauderic’s input here as, currently, DragOverlay seems fundamentally tied to the activeNode in many ways. Ultimately, the high-level goal is to allow collision to occur with drag overlay rather than the node the started the drag.

[wmain]

Sure, happy to take a crack.

[clauderic]

Is this something you’d be comfortable taking a stab at @wmain? I remember looking at this a while back and I agree with you that this needs a bit of work, just haven’t had time to prioritize this area yet.