Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Support live drag and drop #16457
requested review from
Jul 8, 2019
Nice work. Here's a GIF:
There are some things we should discuss, but before that and on a high level: this is impressive work, and it has the DNA of something amazing. I can't wait to see how this ends.
There's a smallish issue that is performance related: appears to be some jank when moving blocks short distances. It feels like it's related to some hover labels maybe/maybe not blinking in and out of existance as you are moving. I'm sure we can fix this.
The larger issue is one of the actual drag and drop behavior itself. The thing you see in master can prosaically be described like this: when you start dragging, you lift the block off the page and see a gray slot where it used to be, and a blue line indicator for where you mean to drop it.
This design came to be out of the idea that this drag and drop helps clarify the intention of the action — you can see where the block was (gray slot), and where it will be when you release (blue line).
The other classic drag and drop method is more real time. As soon as you start dragging a block, it is taken out of the flow and now sits under your cursor until you drop it.
What's in this branch right now sits kind of in between those two approaches — blocks are moved immediately when a "destination slot" is under the cursor, but you have no clone, and no blue line to indicate where you can drop the block. So, although it feels more organic, it's harder to see where to drop the block. Surprisingly I don't miss the clone — but the lack of the blue line means that when your mouse is not over a different dropzone, it looks like drag and drop is broken:
I would suggest that the best thing we can do here is pick sides.
Option 1, keep the blue line. Either we keep the blue destination indicator (maybe maybe make it even thicker?), but add in your lovely animation and ditch the clone (trying in this branch the clone itself does not seem necessary). But it also probably means you can't move the block until you release the cursor — i.e. no fluid "live movement".
Kind of like this:
Option 2, embrace the fluidity entirely. That means as soon as you start dragging, you pull the block out of the flow — if your mouse was a hand that hand now holds the block and holds it until you release it, and surrounding blocks rearrange themselves as you move it around.
Kind of like this (from react-beautiful-dnd):
I used to be a proponent of the blue line approach due to the intrinsic way it let you know what would happen if you released the cursor. But I've come around the the more fluid approach (example 2 above) because it feels more like actual drag and drop, and because we have highly visible undo controls if you made a mistake. But it feels like it's either or — either the blueline indicates where you drop the thing and THEN the block is moved, or the block is pulled out of the flow and makes room for itself regardless of where the mouse is. Combining the two, I'm not sure can work.
What do you think?
We also need to check the preferred flow for nested areas.
I think that is the key missing ingredient. So long as there's a big "dead area" where the mouse doesn't appear to do anything, it feels buggy. Agree that https://codesandbox.io/embed/01p1kxymow is something that could work really well.
I spent the day on this. The bad news is that it's not possible to use the approach from that codepen because it relies on the fact that the array of data doesn't really reorder while in our case it's a requirement.
I think we can build on top of the current approach to get close to that behavior but I'm not sure we'd able to recreate it entirely.
jorgefilipecosta left a comment
This PR looks like a promising step, nice work @youknowriad.