| |
| ▲ | adastra22 4 hours ago | parent | next [-] | | Ah, I was thinking desktop applications. | |
| ▲ | anonymous908213 4 hours ago | parent | prev [-] | | 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. | | |
| ▲ | gavinray 3 hours ago | parent | next [-] | | > 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 | | |
| ▲ | anonymous908213 3 hours ago | parent [-] | | 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. |
| |
| ▲ | dofm an hour ago | parent | prev [-] | | 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. | | |
| ▲ | anonymous908213 an hour ago | parent [-] | | > 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. | | |
| ▲ | dofm an hour ago | parent [-] | | Did you ever actually do this work? Do you remember what browser testing was like? Remember the quirks of browsers’ different understanding of transparency, of z-index, of events, of DOM compliance? I think the suggestion that getting it right could take a week in the context of a particular application is actually not particularly hyperbolic. Mind you, I was doing cross-browser testing long enough ago that I am one of those people who can say they independently invented AJAX in-house. | | |
| ▲ | anonymous908213 an hour ago | parent [-] | | I've done it a dozen times in gamedev, where interfaces and interactivity are routinely built from scratch without any help of a framework. I didn't work on web applications in 2010, but even with the clusterfuck that the web is I find it difficult to believe it was that hard to do. | | |
| ▲ | dofm 35 minutes ago | parent [-] | | It could be absolutely exasperating, even in 2010 (especially then since browser support for touch events was still shaking out). The problem is that even without a framework, you didn’t have a blank slate (which would have been better). You had a moving target of blank slates, you had platform differences, you had drag vs touch-drag, entrenched older browsers and the simple frustration of testing on an array of real devices, all sorts. Now, if you were talking about 2015, then it starts to get a bit flatter. |
|
|
|
|
|
|
