Make PanGestureHandler more compatible with ScrollView and FlatList by adding a "minDurationMs" prop to it

[Fearnbuster]

As has been mentioned in various other issues (issue #434 in particular), PanGestureHandler and ScrollView/FlatList don't work so well together.

I, for example, currently have a situation where a ScrollView is completely filled with multiple PanGesturehandlers which leaves no space to interact with the ScrollView.

While attempting to find a workaround, I noticed that the LongPressGestureHandler has almost the exact functionality that I need.

For example: by setting minDurationMs to a reasonable value, shouldCancelWhenOutside to false, and maxDist to an arbitrarily large value that would never be reached, I was able to simulate what would best be described as a PanGestureHandler that required you to hold your finger in place for the given amount of time before it became the ACTIVE handler.

If however, you moved your finger too much (I'm not sure what the built-in distance is) before the LongPressGestureHandler activated, whichever handler wrapped the LongPressGestureHandler (which was a ScrollView in my case) became the ACTIVE handler (which, in the case of a ScrollView, meant it was now able to be scrolled).

I wish I could just use the LongPressGestureHandler for my particular use-case, but unfortunately, it does not send the translationX and translationY properties through the onGestureEvent callback like the PanGesturehandler does.

If someone could add a minDurationMs prop to the PanGesturehandler that almost directly mirrored the same props from the LongPressGestureHandler, it would drastically increase how easy it is to use the PanGesturehandler within other handlers (ScrollView and FlatList being the two biggest and most pressing examples)

If this prop ever did get added, then it would probably be wise to enable developers to customize how far the user's finger could move during this initial "waiting" phase without canceling the handler.
Although it's important to note, that obviously this new "max distance" prop would apply to the PanGesturehandler only while it is in the "waiting" phase.

I would love to try to implement this feature myself, but unfortunately, I don't have a Mac, so I wouldn't be able to develop the iOS functionality.
I would be willing to try my hand at implementing the Android functionality if someone would be willing to help me with the iOS side, although I would prefer to have someone more competent than myself do it.

[connectdotz]

by adding the minDurationMs you pretty much turn PanGesturehandler into LongPressGestureHandler? On the same token, you could consider adding the delta feature (translationX/Y) into LongPressGestureHandler, which made LongPressGestureHandler pretty similar to PanGestureHandler... Both approaches beg the question "do we need 2 different gesture handler then?"

IMHO, a pretty simple work-around is to implement your own translationX/Y on top of LongPressGestureHandler, which is what we did after facing exactly the same problem you described. Just use a ref to record every gesture movement, then you can calculate the delta between the new and prev move...

[Fearnbuster]

It's true that those two gesture handlers would become very similar, nonetheless, I still think there's a very good case to be made for adding the functionality.

Personally, I'm more concerned about the practical utility that such a feature would provide than I am about the philosophical purity of making sure that there is an easily distinguishable boundary between the handlers.

It's definitely a valid suggestion to implement the translation logic on top of the PanGesturehandler (one that I've actually considered), but unfortunately that means that I have to drive the gesture tracking/animation through the JS thread, which would prevent me from using the Native driver.

[ShaMan123]

#1034

[jgonet]

@ShaMan123 linked PR which resolves interactions between handlers and components that are wrapped by NativeViewGH. You should be able to use waitFor or simultaneousHandlers to achieve interactions you need (I believe waitFor is the right choice in this case).

If you have further questions or you didn't manage it to work please reply with repro, we'll try to figure something out.