Closed rushcodes closed 2 years ago
Problem is that in this case you couldn’t differentiate between clicking and long pressing cause long pressing in most cases would call onClick as well. The idea behind the onCancel is that you either click OR long press which should cover most cases. Unless you want to detect click THEN long press, onCancel should suffice. In case you need both try treating onStart as onClick.
onStart and onCancel trigger at the same time, even with the threshold set to 2000ms and the briefest of clicks, at least in Firefox desktop Windows 10.
I came up with a hacky fix (In react) by using useState and a setInterval - just checked if progress (The state) was below a certain level, in case anyone has the same issue.
Can you provide reproducible example of case above? Maybe it is related #5 ?
Ok, now I think I understand what you are trying to accomplish. If you want to treat onCancel
as onClick
in case less than x
ms elapsed then you can save Date.now()
to some variable (let's say d
) in onStart
handler and then in onCancel
handler you can write if(Date.now() - d <= x) { // handle onClick }
.
As for building that option directly into the library, I will consider it if turns out that's quite common case in the community.
Reasoning behind that is that it can be easily handled manually (as shown above) so I don't want to over-engineer the library to handle lot of edge cases, rather create something that can be used for all basic use cases for long pressing and is easily extendible in case someone need to handle more complex scenario.
It'd be nice if there was a difference between onClick and onCancel - maybe onClick activates when a touch/click lasts less than 100ms (Or ideally something definable)