iOS: TouchableOpacity inside Swipeout makes it harder to swipe.

[RobertBiehl]

I'm trying to make the whole ListView row touchable while also having a swipeout menu.
When I added a TouchableOpacity inside the SwipeOut component it seems like the Touch is given to the TouchableOpacity first, and only is passed after an annoyingly long delay to the wipeout component.
This means the wipeout feels glitchy. Many swipe attempts will fail, or just trigger the onPress of TouchableOpacity.

The native behaviour expected on iOS is that the Swipeout component should have priority, and only after no pan gesture has been detected, the touch is passed on.
In the iOS Mail app this behaviour can be observed, causing a ~300ms delay when tapping an email, and immediate feedback when swiping.

This (or a similar) issue has been addressed before in #97.

Does anyone have an idea how to solve this?

Best,

Rob

[ataillefer]

Hi, I solved a similar issue by using this fork, finding out that this specific commit did exactly what I needed:

"Also implement the onMoveShouldSetPanResponderCapture to ensure that
the swipeout is activated even if there’s a touchable child view.".

We should probably create a PR about this.

[RobertBiehl]

@ataillefer Thanks! Are you ready to create a PR?

[ataillefer]

#97 (comment) mentions that it has been fixed in version 2.0.13, have you tried it out?

[RobertBiehl]

@ataillefer Will do now! 👍

[AfflatusX]

I think this is still an issue for 2.3.1. @RobertBiehl any luck?

[jamesbillinger]

For my part, I found that this is related to sensitivity. I had sensitivity set to 0 for IOS - which worked perfectly in an earlier version. However, in the current version, the event is only captured if the 'Y' (dy) distance is less than or equal to the sensitivity. So it would take a perfect horizontal swipe to make it work with a sensitivity of 0.

After setting the sensitivity back to the default of 50 I found that it works as expected on IOS.

[bolan9999]

try this,please
https://github.com/bolan9999/react-native-largelist

Features
The performance of react-native-largelist is much better than FlatList and SectionList.
Large data source supported, infinite data supported, super fast sliding support.
Full cross-platform.
Sticky Section support.
Callback when Cell/Item enter/leave the safeArea support.
List header/footer/empty support.
Swipe out to edit Cell.
Pull to Refresh and Scroll loading more.
Scroll loading more custom view support, all data source load completed custom view support.
Dynamic variable support, for example: size, contentOffset, currentSection, contentSize, height of Header/Footer, visibleIndexPaths and so on.
Scroll to offset or index path.
Reload data.
Custom optimize parameters.
More callbacks or dynamic variable can be added through a new issue.

[jenskuhrjorgensen]

@ataillefer I just ran into the same performance issue with a TouchableOpacity within a Swipeout component running version 2.3.3, so it turns out to still be a problem.

Cloning your suggested fork solved the problem in a jiff! Thanks a bunch! 😄

BUT, the fork doesn't support the disabled prop for the Swipeout component, so a PR would be awesome 🥇 Haven't checked what other features might be missing in the fork, but right now having a clickable performant cell has the highest priority for me.

[jenskuhrjorgensen]

Haha, I've run into quite a few of your recommendations in this repository already - maybe I should give it a try. I'm just scared away by all the Chinese signs 🇨🇳 😄

Besides, I already have a fine working RN Flatlist, so I would prefer importing a component which just exactly covers my needs and not a completely new list :)

[bolan9999]

Sorry, I thought you were talking to me on email.

[isaachinman]

Any update on this? Just ran into it myself. Using @magrinj's fork does not work for me, I get this error:

Cannot read property 'node' of undefined.

[Obi1Kennoby]

Have the same issue, any updates here?

[kalinchuk]

Same