Grid Snap Not Working?

[jrmoynihan]

Hey, love the clean API on this package!

Just having some trouble getting grid-snapping to work. Can you provide an example, or elucidate what might be wrong with the following code? I'm not seeing any snap behavior change with or without the grid options provided in the DragOptions object.

[PuruVJ]

Can you make svelte REPL of this example please?

[jrmoynihan]

I figured it out! I interpreted the grid array to be the number of grid divisions (i.e. a 2x2 grid), not the pixel dimensions of each grid block (i.e. an infinite grid with snap points every 2px vertically and 2px horizontally). I would clarify that in the docs for other naive users.

[PuruVJ]

Thanks, ill update the docs

[jrmoynihan]

I did encounter a second, somewhat related issue though: When using a defined grid, I can't move an item back to its original position. If I move an item from its [0, 0] position, I can't move it back to that origin.
REPL

Am I not setting something correctly?

[PuruVJ]

Yur right, it's definitely a bug. I'll look into it.

[jrmoynihan]

Thanks for checking it out. I also noticed that when dragging two items on top of each other, they can end up having very slightly different translation distances (different by ~1px or less than a pixel). I think this is a subpixel calculation/rendering difference across browsers.

I was trying to detect if two elements were overlapping after a drag event (so I could move one of them out of the way), but I wasn't getting consistent results when I dragged items on top of each other. This might be easier if the onDragEnd event returned the expected Cartesian coordinates of the element (i.e. the grid [x,y] coordinates, not just the translation offset). Since the user already provides the pixel size of the grid blocks, returning the coordinates should be relatively trivial.

So, if the user provides a grid of [50, 50] in a bounded container that has a width of 250px, and a height of 150px, you might get coordinates that look like this:

Column1	Column2	Column3	Column4	Column5
0, 0	1, 0	2, 0	3, 0	4, 0
0, 1	1, 1	2, 1	3, 1	4, 1
0, 2	1, 2	2, 2	3, 2	4, 2

Then a user could store the coordinates returned from the onDragEnd event and check if they match another draggable item's stored coordinates, rather than checking the pixels from getBoundClientRect() or parsing out the element.style.transform. Instead of comparing offsetX: 534.4325..., offsetY: 200.250... and offsetX: 534.8762..., offsetY: 200.501..., I could just compare x: 4, y: 1 and x: 4, y: 1.

What do you think?

[PuruVJ]

Seems good to me. I think I can expose a domRect property in all the events

[PuruVJ]

Should be fixed now.

About the domRect, I will make a release soon with the fix and this feature included

[PuruVJ]

Released in 2.5.0