[rolha-capoeira]

I have no idea how DFlex works under the hood (nor any other modern drag & drop library), but I'll share something clever I came up with. I'm sure others arrived at a similar solution.

I had to build something for my employer's website maybe 12-15 years ago. jQuery was the hot, new thing at the time. So was customizing UI. All available solutions used a combination of absolute positioning & coordinates to determine the interactivity of the elements. As you can imagine, it was a finicky, buggy mess.

I found myself wishing I could just use the DOM's own mouseover event -- but that didn't work, because the cursor was only over the element being dragged. My epiphany was this: When an element was picked up (drag start), I could duplicate every element in the set and set their opacities to zero (I called them "ghosts"). If I gave them a higher z-index than the element being dragged, mouseover events would be triggered on the ghost elements and I wouldn't have to do anything with coordinates, ever. It was also, by far, the most efficient solution at a time when browsers kinda sucked.

(I finally had a reason to share this anecdote.)

Anyway, thanks for this library, I'll be taking a look!

[jimmy2020]

Cloning elements and duplicating containers are what DFlex tries to avoid. Because the usual implementation is to clone the element (ghost it) and then append a new one with a fixed position. The result is to reconstruct the DOM tree directly with every user interaction which leads to poor user experience and not a very practical transformation. That's why the default thing to do with DFlex is not to clone or change the element position unless there's a need to do so, for example: transforming from a container with a scroll.

[rolha-capoeira]

That sounds reasonable!

To be clear, though: In my old example, there would only be DOM manipulation on drag start and drag end. All interactions between are handled with JS and CSS.

Cheers.