Drop target size is inconsistent depending on if source is self or other.

[xavierzwirtz]

Note how easily Todo 11 can be dropped at the end of List 2 whenever it started its drag from List 2. When the drag starts from List 1 however, the drop zone is only the size of the original element, it does not expand to the visible element size.

[alex35mil]

Thanks for reporting! I believe this is the same issue as https://github.com/MinimaHQ/re-dnd/issues/9?

[xavierzwirtz]

Hmm, it might be. I think the issue is though, when dropping on the same list as you started on the drop zone is much bigger than when dropping on a list that is different than the one you started on. I think it could be improved by making the drop zone the same size in both cases, without needing the heuristic you are discussing in #9.

[xavierzwirtz]

Notice how in the case where you are dropping on source, the dropzone expands to provide a slot for the new element. However in the case where you are dropping on a different list, the dropzone looks to expand to provide space for the new element, but if you drag into that space you are out of the dropzone, and the extra space collapses away.

[alex35mil]

Notice how in the case where you are dropping on source, the dropzone expands to provide a slot for the new element. However in the case where you are dropping on a different list, the dropzone looks to expand to provide space for the new element.

Yeah, it's b/c placeholder from original droppable container never removed until drop is finished (there's another issue related to it https://github.com/MinimaHQ/re-dnd/issues/1).

Making all of the containers of same size means adding placeholder to every single droppable which might not be the most elegant solution (though it's definitely improvement over current state of things). I was thinking of some logic that figures out nearest droppable and adds placeholder only to it but tbh I haven't put any meaningful thinking into this yet.

[xavierzwirtz]

That explains it then. From my usage, the placeholder in the original container makes the drag and drop feel really good there. Feel free to close this issue if you feel its better encapsulated elsewhere.

[xavierzwirtz]

One possible solution is to add the placeholder once a drop target has focus, keep it for the duration of the focus, and remove when focus is lost.

[alex35mil]

I spent few minutes on thinking on it. How about the following. On the drag start, I collect all geometry of draggable items & droppable containers. Looking at the neighbor droppables, I can determine axis in which those are placed in layout. Knowing this, I can assume that either width or heigh is infinity and if current draggable item is within (in case of card board) column area, then I inject placeholder into this column.

Most likely, it would require some refinement. E.g. if I drag item too far down relative to the bottom of the column, placeholder shouldn't be injected since most likely user don't want to drop it there. So instead of infinity, the virtual height of the column (that is used to detect if draggable is within droppable) can be expanded to ownColHeight + draggableItemHeight.

Thanks for reading my train of thoughts 😄

[xavierzwirtz]

I like the sound of that, would make the injection of placeholder feel very sane.

Not a problem, thanks for honing in on the issue.