Make timeForLongPress configurable

[Pajn]

Bug or feature request?

feature request

First of all, thanks for this amazing library. It works better than all others I have tested!

TL;DR

Basically, I would like to be able to change this value

react-beautiful-dnd/src/view/drag-handle/sensor/create-touch-sensor.js

Line 26 in bbec4c9

export const timeForLongPress: number = 150;

Motivation

The current value is set for quick dnd actions that are great for applications where dnd is a primary action which also seems to be the main focus of the library with regards to the examples. However, in my use case dnd is a secondary configuration action similarly to the homescreen on Android and the default value of 150ms is far to quick and easily causes items to be picked up when not intended to.

[alexreardon]

Sounds like a reasonable request!

[alexreardon]

The drawback of making it too small would be that you might accidentally prevent native scrolling on the list. By hard coding it we prevent any mistakes in that area

[Pajn]

The drawback of making it too small would be that you might accidentally prevent native scrolling on the list. By hard coding it we prevent any mistakes in that area

I do think the default behaviour should be kept as is, but allow modifying it if the default behaviour doesn't work for you for some reason. It should not be required to provide that value. Sure that doesn't stop people from shooting themselves and their users in the foot but it will be a good experience if you just drop it in.

[charlesbodman]

I am requesting this for the exact opposite behaviour.

dnd is the primary focus and I actually want to prevent scrolling to ensure quicker dnd feedback.

Thank you 👍

[szdc]

@alexreardon if this is something you would like implemented I am happy to make a PR - a prop on Draggable perhaps?

[tomhoad]

A prop on Draggable would be ideal here.

I can see why having the timeForLongPress is essential for scrolling applications (which, to be fair, is the vast majority). However, the alternative use case is when the application is locked to the visible screen area (i.e. overflow: hidden) and therefore scroll events aren't important.

The experience is quite cumbersome when this is the case, as every interaction requires a long press. We have seen users assume the dragging is 'broken' in these cases, with reports of it being 'laggy'.

This could either be an integer ms value, or a boolean to set the timeForLongPress to zero if false?

[alexreardon]

While I think this is a footgun and can lead to a strange user experience in some cases, i think it makes sense to allow people this choice. I will try to take a into this soon

[renanbandeira]

This feature would be great! I'm trying to create something like Spotify edit playlist functionality, but the time for long press is the only issue I have while I'm trying to reorder the items from my list.

[natew]

Just wanted to throw in another +1 here, besides virtualization support (in 12!) adjusting the press delay is all we need to switch from react-sortable-hoc (axis locking would be nice but that's easy to implement in user-land).

Basically, we have a selection option where you can drag to select, much like mac native. So we want to put the delay at about 350ms.

[spiritsack]

Do we have any updates on this? Would love the feature as well.

[badtant]

I have a pull request for it but haven't gotten any feedback on it.

[alexreardon]

Adding a prop for this is fairly straight forward. There is a complicating factor on mobile (force press interactions) #1401

Sadly although force press is going away, it is still around. The current value 120ms is tweaked to allow for the most resilient cross-device experience. Much higher and we run into issues. It would be interesting to see if we could go lower.

I suspect that most people asking for this would like it to be near instant. Rather than allowing the value to be controlled, perhaps we could supply an option for that

[spiritsack]

Adding a prop for this is fairly straight forward. There is a complicating factor on mobile (force press interactions) #1401

Sadly although force press is going away, it is still around. The current value 120ms is tweaked to allow for the most resilient cross-device experience. Much higher and we run into issues. It would be interesting to see if we could go lower.

I suspect that most people asking for this would like it to be near instant. Rather than allowing the value to be controlled, perhaps we could supply an option for that

I agree that's the usecase most of us seek.

[badtant]

@alexreardon maybe you can have a look at this:
#1304

[spiritsack]

Does the release of v12 complicate adding this feature?
Do we need a new PR?

[barelabs]

How soon do you think this will be added, where the feature of having near instantaneous drag after tap can be set with an option? Thanks! Tim

[RyanJMcGowan]

We are using drag-n-drop to quickly swipe items into other divs. If there's any delay at all, it feels stuck. We have no use for scrolling or other input on the Draggable that the delay is meant for. It's not a list in our case. Please consider the various use-cases beyond lists, as there's not many mobile drag-n-drop libraries available.

[lapanti]

I want to toss my hat in the ring for allowing for a configurable option, instead of a boolean choice, as our app has it as a secondary feature and it would be great to be able to make it longer. You can always add a disclaimer to the documentation that a longer time might break older devices etc. It's up to the user of the library to ensure it fits their own use case anyway.

[Aarbel]

@alexreardon any news about this feature ?

[julie-volkova]

I would love to see this implemented!
Any news?

[Porges]

I have a use-case for wanting a very short (or zero) delay; the items themselves don’t have any content so there is no interaction inside, and my whole app is inside a touch-action: none element, so it doesn’t scroll.

Perhaps (in addition to making the timeout configurable), react-beautiful-dnd could detect if touch-action: none is in effect and remove the timeout there, since there’s no possibility of the user trying to scroll?

[spiritsack]

I had a go at this. #1856
Please make suggestions for improvements.

[vishwajeet-pandey-exa]

+1 would love to see this. Some users tap slower, & complain about this as 'bug'/inconsistent behavior

[snowmas]

I had a go at this. #1856
Please make suggestions for improvements.

Is there any chance I can use this already? Thanks for pushing this.

I tried to fork the whole project on my own and change the hardcoded const timeForLongPress; myself. And use it in my codesandbox.io project - but I have no idea how to add it from github as a dependency in package.json.

[trevyn]

patch-package is a pretty easy way to change the hardcoded value. For example:

https://gist.github.com/trevyn/487871245b27cf86f6d869e33aa6dd84

[MaciejCaputa]

Any possibility to merge #1856 and release it shortly?
This is very important for me.

[zzliux]

is this feature released? in fact, dragging with handle needn't long press

[jinmingpang]

Any possibility to merge #1856 and release it shortly? This is very important for me.

2 years later...nothing has changed～

[smitpatel133]

Any timeline on when this will be out?