Drag and drop is a very useful tool in applications as it can simplify a large part of the process for users. It's also a common task we delegate t...
For further actions, you may consider blocking this person and/or reporting abuse
Very buggy. I got into this situation fairly quickly...
And this...
I don't seem to able to reproduce it. Which browser are you in?
Happens on all browsers I've tried - Firefox and Chrome on both macOS and Ubuntu. Easy to reproduce. I think it has to do with not disabling user selection on the draggable items (just a hunch, I don't have time to look into it)
I see, unfortunately I've tried a long time but I never was able to reproduce.
Anyways, thanks for the feedback! I'll look into it and see if I can do something about it.
I was able to get something similar. I separated the text into its own box and the black background into another box.
dev-to-uploads.s3.amazonaws.com/up...
Either way, this is a good start for a drag and drop component - it does work, but might need a little fine tuning.
Google Chrome Version 95.0.4638.69 (Official Build) (x86_64)
Can't reproduce, but thanks for the feedback. I'll look into this, and once i find out the issues I'll write a follow up!
It's kind of the wrong API for custom drag-and-drop operations - it's very limited in terms of what you can do with it, visually, and provides no real means of fine tuning the experience in terms of interaction either. It will let you go about as far as you went in this demo, but not much further.
I wouldn't recommend using the drag events API unless you need to drag to/from the desktop - for file uploads and such, about the only thing this API does well.
Unhappy with the complexity of drag-and-drop libraries myself, I started this library about four years ago:
github.com/mindplay-dk/zero-drag
It ended up a lot more complex than I would have liked - even if it is less than 200 lines of actual code (about 1K minified) when you get into all the details of these interactions (and even if this is a lot simpler than the libraries that also deal with the visuals) it's just a lot more complex than it seems. (On the up side, if you look at the examples of using it, those are about as simple as using the standard API.)
Note that this doesn't support touch events - I think that was the last remaining big push to finish this, but I've had no reason or inspiration to actually finish.
Maybe it inspires somebody else to do it. I'm a sure a lot has to do with taste, but I've really never seen a drag-and-drop library or approach that I really liked. 😉
You are totally right, when we need customization this doesn't really work (like all native APIs 🤣). When you need a fully featured approach libraries may be the right way to go.
This does work for when you just need the minimal functionality. I was just pointing this out for awareness because I don't want you to bloat your code :D
Hoping in the future this API will get better tho, if it does it will be awesome!
I'd suggest adding {} around the outside creating a scope so LET serves a purpose. "AppendChild" will automatically do a "removeChild" so you don't need that line. The overhead of the "function for nothing" is doing you no favors, the use of "target" instead of "currentTarget" is why some people are seeing behavioral bugs. Not even sure why you're messing around with setting the data type to text/plain... did you just blindly copy that part from a tutorial?
Though the worst problem is the hardcoding in the markup of the event preventing re-usability, lack of target restrictions, and that you hooked "document" instead of the actual elements!
Here's a "fixed" fork.
codepen.io/jason-knight/pen/poWzbNJ
Uses data- attributes so that each "set" can self-target. A lot of the logic you were tracking isn't necessary because it targets elements, it auto-hooks itself to all relevant elements, doesn't have those pesky false drop targets because again, it hooks the elements with Event.currentTarget not document and Event.target, etc, etc.
Don't use document events for individual elements no matter what some folks out there say. Likewise don't use Event.target it can give you the wrong origin and/or destination if a cascade of elements is involved. You start putting tags inside your draggables, those elements will report as Event.target.
Remember, Event.target is the lowest element clicked on. Event.currentTarget is the Element the event is attached to!
Oh and avoid garbage like Element.style if you can. Unless you're actually calculating values, that too is just bad code. Why? 1) Presentation has no more business in your JS than it does your HTML, 2) it makes it harder for people to style it since you have to dive into logic to just set the colours.
Anyhow, the script's not even 100 bytes larger despite all the added functionality.
Wow that's a lot of fixes! Thanks for sharing your insightful thoughts 😃
Will try this out