React-beautiful-dnd: Delay between `mouseUp` and `dragEnd` events

Created on 18 Nov 2017  ·  8Comments  ·  Source: atlassian/react-beautiful-dnd

Bug or feature request?

Question, and a possible feature request.

I want to thank you for the great library and very detailed documentation and tests.

When dragging an item, there is notable delay (around 400-500ms) between releasing an item and triggering onDragEnd event. My question being - is there a way to remove this delay? I'm working on a simple kanban board, and this really affects UX. I did a search through the documentation, issues and even code, but I couldn't figure out if this was intended delay, or is it a performance issue (which I doubt).

It would be great to add a prop which would remove this delay.

Demo

This delay can be seen on all of your examples in the storybook, but I created one which console logs delay between mouseOp and dragEnd events (open console in the lower right).

https://codesandbox.io/s/6x0nk3m20k

Data copied from the example console:

"mouse up"  1511003328459
"drag end"  1511003328867
"delay"     408

"mouse up"  1511003331054
"drag end"  1511003331450
"delay"     396

"mouse up"  1511003794434
"drag end"  1511003794856
"delay"     422

Cheers!

question ❓

Most helpful comment

@tslocke this issue should go away in next as we are no longer using react-motion and the drop animation will end when the transition ends.

@Stanko the new drop animation approach would allow you to set the drop animation duration to 0 if you wanted to skip it (although not recommended!)

All 8 comments

Hi @Stanko,

The delay is caused by the drop animation. Also, I would not rely on a 1:1 relationship between a mouseup and a dragend. There are many ways a drag can end including user driven (the user presses the escape button) or automatic (the browser is resized during a drag). The duration of the delay will be impacted on how far the item has to travel to reach its home destination.

We are not supporting the ability to opt out of the drop animation as it goes against the core design principle of the library.

Cheers

The delay is caused by the drop animation

@alexreardon agreed, the animation is desirable, however I'm seeing a very noticeable delay after the dropped item comes to rest where it's supposed to be. Like @Stanko says, this definitely negatively effects the UX.

I've done a bit of tracing and the issue seems to be with react-motion. My guess is that the physics calculations are causing the object to wobble imperceptibly in place for a few hundred milliseconds, before firing the onRest callback. I've tried messing with stiffness and damping a bit to get it to snap into place more quickly, but no luck so far.

A good solution might be to have the option of having the application callback called before the animation instead of after. e.g. onDragWillEnd ?

@tslocke this issue should go away in next as we are no longer using react-motion and the drop animation will end when the transition ends.

@Stanko the new drop animation approach would allow you to set the drop animation duration to 0 if you wanted to skip it (although not recommended!)

@alexreardon thank you for letting me know! Is there a specific prop I should be aware of?

It will be in the release notes for version 10
On Fri, 14 Sep 2018 at 6:59 pm, Stanko Tadić notifications@github.com
wrote:

@alexreardon https://github.com/alexreardon thank you for letting me
know! Is there a specific prop I should be aware of?


You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/atlassian/react-beautiful-dnd/issues/180#issuecomment-421281936,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACFN7Zgg7gDEvaePVTD8M5AMzoU78Y5eks5ua2_1gaJpZM4Qi9_L
.

I agree that from a UX viewpoint, a transition (OOM 100ms) is needed on releasing a Draggable.

I also agree with @Stanko and @tslocke that, again, from a UX viewpoint, immediate action is usually needed upon drop, irrespective of any transition/animation going on. The user exercised the affordance, expecting immediate feedback. The user isn't going to think, "OK I dropped the thing, let's wait till it settles into its final destination which then will cause the thing I want to be executed". A drop user action _is_ an action. Unless I misunderstood this, there's no disagreement about it.

In other words, the _action taking part_ and the _visual transition part_ can be fairly independent of each other.

I just checked out and built next but I'm still seeing the old behavior, am I doing something wrong? Again, in line with your recommendation @alexreardon I'm not planning to use 0 transition time.

We might look at exposing a onDragAnimationStarted hook, which would let you do some work before a drop animation finishes

@alexreardon that would be awesome! Might be called this, or dragRelease to better tie it to the actual trigger (dragEnd would be even more apt but it's understandable if you don't want to align the meaning of that, as former userland code may rely on that being activated on, essentially, dragReleaseAnimationComplete)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

FutureKode picture FutureKode  ·  3Comments

alexreardon picture alexreardon  ·  3Comments

gitleet picture gitleet  ·  3Comments

khurram-wasim picture khurram-wasim  ·  3Comments

shalkam picture shalkam  ·  3Comments