Virtualized Draggable ListBox

[hipstersmoothie]

I have a virtualized draggable listbox and it mostly work.

One thing that doesn't is dragging things from the start of the list to the end of the list. If the dragged item gets unmounted while the drag is happening, the useDraggableItem calls it onDragEnd and the drag operation won't work.

Is there any guidance on this?

Looking at the code it looks like useDrag doesn't really depend on the original element still being mounted.

The issue lies in the code below

    // If the dragged element is removed from the DOM via onDrop, onDragEnd won't fire: https://bugzilla.mozilla.org/show_bug.cgi?id=460801
    // In this case, we need to manually call onDragEnd on cleanup

[LFDanLu]

Thanks for bringing this up, looks to be a bug on our end. Looks like we aren't properly persisting the dragged keys in our Virtualizer, the key being persisted is actually changing to match the key that the drop is currently hovering over and thus the original item gets removed from the DOM as you noticed. Seems to be some difference between the docs example and our storybook example as well, the storybook example doesn't cancel the drop on when dragend is triggered by the item unmounting but the docs example does: https://codesandbox.io/s/vigorous-sun-v5v43v?file=/src/App.js. I'll convert this to an issue.

[LFDanLu]

Ah and just as a fyi, the issue I created for this is here: #5336, didn't realize Github doesn't auto link it here

[hipstersmoothie]

Ah yeah adding a no op onDrop does fix it!

[hipstersmoothie]

Also on a kind of related note: Drop target calculation is broken for a virtualized list if you:

• use estimated size
• have multi sized rows

It ends up using the estimated size even if you tell the virtualizer/layout the updated height

[hipstersmoothie]

Huh after switching to onDrop: noop this introduces a new bug:

when I use my keyboard to do the drag and drop it now tries to target on of the draggable items where with just onReorder it only did before/afters

[LFDanLu]

Huh after switching to onDrop: noop this introduces a new bug:
when I use my keyboard to do the drag and drop it now tries to target on of the draggable items where with just onReorder it only did before/afters

What do you have in your getDropOperation logic? Do you return cancel for "target.dropPosition === on"? Providing onDrop was meant as a more fine grained way of supporting a variety of drop operations/custom drop operations all in one callback (see https://react-spectrum.adobe.com/react-spectrum/dnd.html#low-level-drop-handlers-and-options) whereas only providing onReorder/onRootDrop/etc high level handlers would allow us to handle omitting specific drop operations (i.e. why it only allowed before/after drops for you prior to adding onDrop)

Also on a kind of related note: Drop target calculation is broken for a virtualized list if you:
use estimated size
have multi sized rows
It ends up using the estimated size even if you tell the virtualizer/layout the updated height

interesting, our TableView/ListView should hit both cases (we estimate row sizes in an initial pass, and support variable sized rows): https://codesandbox.io/s/vigorous-sun-v5v43v?file=/src/App.js. Do you have a sandbox you can share?