Hacker News new | past | comments | ask | show | jobs | submit
Hit-test where the mouse-down event is fired, hit-test where the mouse-up event is fired. What the hell do you need a library for?

> If anyone can dig up an ancient library on GitHub for drag-and-drop back in those days, I'd imagine it would be several thousand lines long,

I bet, the JS devs who do write code overcompensate for the ones who can only stitch together libraries. I suppose because the expectation is that the library consumer is incapable of writing their own code extending it, so the library itself must support every possible combination of use cases for a million different users, even though the code any individual consumer actually needs is more like 100 loc.

  > What the hell do you need a library for?
On the frontend, you have to re-calculate the display state for all the possible drop positions, in-between transitions, and drop-end-snap-back.

Think of a grid of cards, and all the possible drag, hover, and drop state transitions it can be in with any other card, and the animations required to make it look nice

Now also consider that you need to persist the final state on the backend, and handle things like rejection, cancellation, failed updates/errors.

It becomes a massive state chart and web of complexity

I mean, maybe we're missing context here. Is that what your boss was actually asking for? 99% of web applications (or, hell, desktop applications) don't have ultra-interactive, fully-responsive-animation drag-and-drop. If he was asking for functional drag-and-drop and the team was implementing top 1% cosmetic drag-and-drop, that's certainly one avenue for a mismatch in expectations.
loading story #50423654
What does that look like mid drag, and how?

If you are dragging within the page, then the draggable “ghost” is your problem too (it’s not automatic). As is deciding whether the ghost should affirmatively snap out of and into the source and target containers (that is, whether the destination container should appear to “make room” for the ghost at some transitional point), whether there’s a transition on that, etc.

Drag and drop in desktop non-web GUIs have all sorts of visual affordances that users expect for consistency that are your job in HTML.

I was once quite up-to-date with raw frontend work and I tried to implement this; it’s actually not trivial.

> draggable ghost

Okay, you've added a requirement. Poll the current cursor position after the first hit-test sets the dragging state and call a function to render your object with X% opacity at a higher Z level than anything else. Your 30 minute job has become a 60 minute job.

> As is deciding whether the ghost should affirmatively snap out of and into the source and target containers (that is, whether the destination container should appear to “make room” for the ghost at some point), whether there’s a transition on that,

Most applications don't go this far, including your operating system like Windows that sets baseline UX expectations, so you're well beyond the default expectation for drag-and-drop. If someone asks you to implement drag-and-drop without specifying they want all the bells and whistles, and you respond it's going to take you a week because you're planning to go all-out beyond necessary business requirements, they'd have a valid reason to be like "WTF mate?". Also this is still pretty paltry and not a week's worth of work.

loading story #50421143
loading story #50420672