i need a bit more details about the behaviour. the dragged element copies it the styles of the shadow element (top level, ignoring children styles).
Do you want the dragged element to morph to the size of the small placeholder? that should be achievable

I would like this design to work correctly. Meaning small shadow and big item. (I updated css of repl to match this gif).

I

Got back to this today and did some debugging, it seems that custom placeholder is not the issue but it's caused by different item heights.

No problem dragging big items ("responsive"), but becomes "unresponsive" when dragging small ones.

Gif:

Repl: https://svelte.dev/repl/97224142fc5641c4849c8ab55ad473bd?version=3.24.1

Seems to me like issue with cacheShadowRect, would cache wipe on drag direction change fix this? (down->up, up->down, ...). Wiping cache helps, but does not resolve completely. Still weird.

@isaacHagoel

Problems with current wouldBeIndex implementation:

A) Different dragging behavior on way back

• When you go top-bottom shadow moves when center of dragged ENTERS i-th child rect
• On way back bottom-top shadow moves when center of dragged LEAVES i-th child - to be precise, when dragged is over cached shadow rect (not visible), which was cached on way top-bottom

REPL: https://svelte.dev/repl/97224142fc5641c4849c8ab55ad473bd?version=3.24.1
GIF:

B) Dnd becomes "unresponsive" on fast movement back.
REPL: https://svelte.dev/repl/97224142fc5641c4849c8ab55ad473bd?version=3.24.1
GIF:

I created draft PR that solves this ONLY for vertical dnd zone for now. I think UX in draft is better than actual, same behavior for dragging both ways and always "responsive". However it's based on drag direction and I have no idea how to make it work for vertical and horziontal (and possibly grid) lists without adding config option forcing user to specify.

the caching mechanism was created on purpose to solve issues with items jumping around.
getting locked on fast drag back is definitely a bug that i want to fix.
can your solution be enhanced to be container direction independent?

@mataslib ^

@isaacHagoel Hello isaac.

can your solution be enhanced to be container direction independent?

I don't know, I don't think so, I didn't figure out any idea yet.

I think that #312 may be duplicate of this issue.

Unfortunately I'm finishing project and can not spend any more time on this as of now. I didn't realize how complex this is and how many strategies are there. It seems like other libs also have problems supporting grids and rather supports Vertical/Horizontal lists and custom user strategies. I will spend some time on container autoscroll support now as it blocks shipping the project.

B) Dnd becomes "unresponsive" on fast movement back.
REPL: https://svelte.dev/repl/97224142fc5641c4849c8ab55ad473bd?version=3.24.1

Looking at the REPL and gif again (wanted to fix it) - looks like it is working as intended to me. In the gif the item is not dragged back high enough to make the large item move. I don't think it is related to the speed of dragging

looks like it is working as intended to me. In the gif the item is not dragged back high enough to make the large item move.

In my opinion it is 130px over first large item "Am", that seems enough to me to make it moved? I think the correct behavior is that shadow should never be allowed to be in further distance than 1 idx away from bellow element. It's distance of two in gif and I am even able to make it bigger distance (4) as you can see in this screenshot.

Not mentioning difference in behavior on switching direction of dragging. How can user know where to drag after a while of dragging - is it start of element or end?

I get your point, all hat I can say is that there are many things in production which doesn't make them correct even if nobody complained yet. (Actually I'm the first one, our designer second one, hopefuly there will be others.)

Back to the problem. I don't get one thing, In the last image, shadows were cached on the way down. How is it possible, that above element is hovering over item idx 0, but shadow of item idx 3 is rendered. I would expect shadow at idx 0 or 1 (based on first drag direction). Does it mean that shadow with idx 4 was cached for item with idx 0?

you are right. in the second example the index should become 2 (between the two large items). this is definitely something i can look into and fix

Hi! We have the same problem (and it's really a problem). Can you, please, tell what's the status?
I see that @mataslib has created a pull request to fix this. Is something wrong with it?

@kkarpeev

Well, there are multiple problems with it. Main one is that it's currently solving only Vertical dropzone and it's hardcoded, not ready to be merged. In current state, it's just an example how this could be solved for vertical lists. It would have to be further updated to at least allow picking between default one and my algo, optionally adding support for horizontal dropzone too. PR algo would also force user to specify whether dropzone is vertical or horizontal, and prob wouldn't work with grid dropzone (vertical + horizontal). Also I have updated version of this pr in my project (some bugs fixed), since we don't use grids, this PR works nicely for our usecase. Unfortunately i don't have resources to spend more time on this at the moment or in near future (uni last year + work). It would be nice to allow user to pass his own strategy (or pick from library's provided ones) as there are many strategies of collision detection to pick from and the best one differs from case to case (nice blogpost that inspired my pr and I would recommend to inspire from is https://docs.dndkit.com/api-documentation/context-provider/collision-detection-algorithms), fix or change current solution.

@mataslib Oh, I see. Thank you!

Reviving an old thread, but I've got the same problem when using morph. Also, when the dragged element is morphing back and forth, the dragged element is not recentering relative to mouse and can be way off the actual mouse position.
Those are 2 problems, but I believe that at least being able to choose mouse position as collision system would help a lot on stability. What do you think ? I can make another issue if you prefer.

Swap thresholds in SortableJS was what made me feel good about this concept : https://sortablejs.github.io/Sortable/