Problem with Dragging/Snapping then Removing/Appending elements

[rastapopolous]

Hi Taye,

A question about dragging/snapping and removing/appending children in interact.js 1.2.6 (and a couple small related questions). I started using it about 2 mos ago, it’s a really great library. Thanks for putting it out there!

My project is a board game, standard setup, xy axis of 20x15 boardsquare divs. For players, tray divs with six traysquare divs each to hold player game tiles. Tiles are dealt at start to each tray as children of traysquares.

GAME BASICS:

1. I've implemented pretty standard draggable, with dropzone  targets on each boardsquare, with snap options configured, to receive tiles dragged from player traysquares.

2. On dragenter to any boardsquare dropzone target  a 'play' class is added to the tile div.  On dragleave it is removed. 

3. On dragenter, tile node should be removed from current parent  and appended to its new parent (trayspace >>>boardspace, boardspace>>>trayspace.

3 PROBLEMS:

• I've implemented  parts 1&2 above.  All functionality works properly w/o throwing errors, except that snaps to dropzone always have overlap(not sitting evenly on dropzone)
 You can see this overlapping in the attached image  I can probably fix this with experimentation, wondered if you had ideas.

• When I return a tile to the tray it started in, if a tile is dragged onto a trayspace that precedes it in the array of trayspaces (for example: tile[3] dragged to  trayspace[2]) the tile will only drag into position "under" the trayspace.  But it will drag OVER any trayspace with a lower hierarchy. (Also illustrated in the attached image).

• Part 3 of gamebasics, above ,is my biggest headache   When I add the following code to my ondragenter  function:
       var thisTile = event.relatedTarget;
       event.target.appendChild(thisTile.parentNode.removeChild(thisTile));

The dragging/snapping and addclass go crazy.  Dragging tile elements from the trayspaces, they no longer snap to the dragzone, but fly away without gravity to the upper left side of the window.  They will append themselves to a parent, but a random unintended one in the upper left portion of the board.  The '.play' class sometimes adds and sometimes does not.  Without the two remove/append lines above everything works fine

UPDATE: 1/21: reformatted remove/append into 3 lines:
thisTile = event.relatedTarget;
thisTile.parentNode.removeChild(thisTile);
event.target.appendChild(thisTile);

No errors thrown, DragDropSnap works as expected, .play class is added, but elements are not appending, maybe because after the .move theyre gone before they can .append(?)

UPDATE 1/23: removed all snap functionality from draggable{} snap: definitions and .dragenter snap target reference. Without snapping, using 3 lines for remove/append above dragging is less crazy/flyaway than before, appending works, as does adding '.play' class. However, under this scenario .on dragleave remove playclass no longer works...

Thanks for your help Taye. I think this is pretty clear, esp w the image attached, but I could also post to jsfiddle if needed

THE INTERACT CODE:

interact('.draggable').draggable({
    snap: {
        mode: 'anchor',
        anchors: [],
        range: Infinity,
        elementOrigin: { x: 0.5, y: 0.3 },
        endOnly: true
        },        
    intertia: true,
    restrict: {
        //restriction: "parent",
        endOnly: true,
        elementRect: { top: 0, left: 0, bottom: 1, right: 1 }   
    },
    onmove: dragMoveListener
});

interact('.dropzone').dropzone({ overlap: .51 });

interact('.dropzone')
    .on('dragenter', function (event) {
        var dropRect = interact.getElementRect(event.target),
        dropCenter = {
            x: dropRect.left + dropRect.width  / 2,
            y: dropRect.top  + dropRect.height / 2
        };

        //adds '.play' class to tile when tile is dropped on another element (board squares)
        if (event.target.classList.contains('boardSquare')) {
            event.relatedTarget.classList.add('play');
        }

        event.draggable.snap({
            anchors: [ dropCenter ]
        });      
        var thisTile = event.relatedTarget;
        event.target.appendChild(thisTile.parentNode.removeChild(thisTile));        
    })
    .on('dragleave', function (event) {
        event.draggable.snap(false);
        event.relatedTarget.classList.remove('play');
    });

function dragMoveListener (event) {
    var target = event.target,
    // keep the dragged position in the data-x/data-y attributes
    x = (parseFloat(target.getAttribute('data-x')) || 0) + event.dx,
    y = (parseFloat(target.getAttribute('data-y')) || 0) + event.dy;

    // translate the element
    target.style.webkitTransform =
    target.style.transform =
        'translate(' + x + 'px, ' + y + 'px)';

    // update the position attributes
    target.setAttribute('data-x', x);
    target.setAttribute('data-y', y);
}

[taye]

Hello rastapopolous,

I'm glad you found my thing useful! It looks like you're using a fairly old version of interact.js. Try to upgrade to the unstable version. Despite the name it's the most bug-free version at the moment. There are also many improvements to snapping (see #127, #133 and #325 (comment)). There are some comments on how to update snapping to use the new API in #79 (comment).

I'm not totally clear on your issues. Can you make a small demo or give me access to the game? My email address is to the left of my Github profile

[rastapopolous]

Hi Taye,
thanks for getting back to me, and the advice on newest version. I'll try that first tomm, see if it helps w the appending issue, then if not I'll get it up on jsfiddle, that should work...

[rastapopolous]

Hi Taye,
Just sent you an email with the codepen link and an explanation of whats going on. Let me know if questions. Thanks!

[rastapopolous]

Hi Taye,
Wondering when you might have time for some feedback on this. The appending/removing is pretty central to my game logic, so if its a liability for interact I might have to try to figure out something else. Guessing it should have an easy solution but havent been able to figure one out. Hope to hear back soon as I need this to move ahead. Thank you!

[rastapopolous]

Hi Taye,
I'm closing this issue, after a month and a half of little response from you I finally managed to fix it myself. The awkward behaviour on appending to target was fixed by first changing dropenter event to just drop. That way the event could finish more easily before other actions (like append) occured. This also solved the snapping problem I had mentioned earlier.

The other part of the solution was to removeAttribute data-x and data-y attributes, and set transform to '' before append. Too many incompatible things happening together at the same time as the dropenter I think.

Thanks Taye.

[Joeao]

While I understand your frustration at having to deal with an issue for so long, I don't think it's fair to call out the developer for not helping with your issue.

If this were a bug with the software, I'm sure the priority would be raised, but even if that were the case, the developer isn't required to do anything about it. There are many people entering the Gitter page and asking for help, some get it, others eventually work out the problem themselves
The licence of this project is "as is", which pretty much removes all liability from the developer. I know this is more in a legal sense, but I'd think it applies to tech support too.

In regards to the letting the community know about extended leaves etc. This project seems to be active when it needs to be, there are many other projects which are left unfinished for months and while it's a shame, you just have to move on and find a solution, though this wouldn't be one of those projects.

I'd recommend bringing your issues which aren't related to bugs or feature requests to StackOverflow or Gitter as the users there are much more likely to have time to help with your problems. You'll also be given more time to explain your issue without having to condense it down.

I'd also like to say that with this particular issue, what you're doing is somewhat complex and it may be easier for you to find the solution yourself rather than asking someone else to get completely into the mindset if your project. The developer makes this project that can fit into so many scenarios which they wouldn't have ever dreamed of when starting the project, therefore just because they're the authors doesn't mean that they can instantly figure out your issue. They too have to research to get up to where you are, which isn't necessarily a fair thing to ask from someone who has already put so many hours into the project.

Tldr: I get the frustration too, we've all been there. You were very civil in your response too so there's no problem there. I'd just recommend adjusting your expectations. Tech support that a developer gives is a nice bonus, rather than an entitlement.

[rastapopolous]

Thanks for your feedback Joeao. While you're correct that it would be inappropriate to call the developer out on a lack of assistance, my communication was based on expectations set by the developer themselves; the project presents as far more highly polished than most on Github. I initially expected no support, was then led by the developer to provide extensive documentation of my particular situation so that they could assist me on this. Accordingly I planned based on their offer.

The one mistake was probably calling them out publicly on this issue. Really this was more of a personal issue between me and Taye. Accordingly, I've gotten in touch with them privately and amended my comment so that it pertains only to closing the issue.

[taye]

This project is a personal exercise in software development, Web/graphic design, product branding and technical documentation. I do this because I enjoy it and I don't understand why a very similar "drag and drop" solution hadn't been developed to this extent before. I don't do it to make money and I hardly do it to make people happy. I'm just scratching an itch. When this itch goes away or anything more important comes up, I change focus.

Your problem, like the majority of issues opened for this repo, was that you took a wrong aproach or weren't aware of how the module and the event listeners you used operated. I offered my help because I thought that I'd have time for it. It turned out that I wouldn't have time but I still think it's better to have offered with the honest intention of providing useful support than to have closed the issue as simply being your problem and not mine. I didn't expect you to significantly reduce your own efforts to solve your problem and I'm sorry if you felt your time was wasted by documenting your issue.

The LICENSE file clearly states a lack of warranty. If my work seems too highly polished to be that of one person working for free who makes no promises and who feels entitled to disappear for a few months, that's your problem not mine. It's nice to help people and I greatly appreciate it when people help me, but I'm not here to foster a community. I just want to scratch this pesky itch.

[rastapopolous]

Taye,
thanks for responding. I didn't have a "problem;" I was confused. Yes,
like the majority of issues opened for this repo, I took a wrong approach
and wasn't aware of how the module and the event listeners I used
operated. But no one forced you to create the impression that this was an
active project and that you wanted to help people. That has nothing to do
with a warranty and everything to do with your apparent outward appearance
as a nice person with a well designed library.

If that's no longer the case and you dont have time or interest in helping
me or anyone i could really care less. Scratch whatever the f**k you
want. Just do the decent thing and dont let the people down who YOU
invited to depend on you. Looking at your open issues many, like me, (but
probably too polite to say anything) have been waiting around since the end
of December.

Post a notice on your project. Take the 30 seconds to write back to
someone like me saying youre checking out and i should solve it on my own.

No there's no warranty. But its the decent thing to do.

On Fri, Apr 8, 2016 at 4:19 PM, Taye A [email protected] wrote:

This project is a personal exercise in software development, Web/graphic
design, product branding and technical documentation. I do this because I
enjoy it and I don't understand why a very similar "drag and drop" solution
hadn't been developed to this extent before. I don't do it to make money
and I hardly do it to make people happy. I'm just scratching an itch. When
this itch goes away or anything more important comes up, I change focus.

Your problem, like the majority of issues opened for this repo, was that
you took a wrong aproach or weren't aware of how the module and the event
listeners you used operated. I offered my help because I thought that I'd
have time for it. It turned out that I wouldn't have time but I still think
it's better to have offered with the honest intention of providing useful
support than to have closed the issue as simply being your problem and not
mine. I didn't expect you to significantly reduce your own efforts to solve
your problem and I'm sorry if you felt your time was wasted by documenting
your issue.

The LICENSE
https://raw.githubusercontent.com/taye/interact.js/master/LICENSE file
clearly states a lack of warranty. If my work seems too highly polished to
be that of one person working for free who makes no promises and who feels
entitled to disappear for a few months, that's your problem not mine. It's
nice to help people and I greatly appreciate it when people help me, but
I'm not here to foster a community. I just want to scratch this pesky itch.

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
#343 (comment)