Pressable has unchangeable delay for opacity effect (onPressIn)

[mrousavy]

Description

The <Pressable /> component has an unchangeable delay between pressing and visual feedback.

See:

Pressable	TouchableOpacity

As you can see, the TouchableOpacity has instant visual feedback when I press it, where as the Pressable takes about 120ms (wild guess).
I though 49b2a6e should fix this delay?

React Native version:

info Fetching system and libraries information...
(node:46144) Warning: Accessing non-existent property 'padLevels' of module exports inside circular dependency
(Use `node --trace-warnings ...` to show where the warning was created)
System:
    OS: macOS 10.15.5
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Memory: 6.86 GB / 32.00 GB
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 14.4.0 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.6 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.9.3 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 13.5, DriverKit 19.0, macOS 10.15, tvOS 13.4, watchOS 6.2
    Android SDK:
      API Levels: 25, 28, 29
      Build Tools: 28.0.3, 29.0.2, 29.0.3, 30.0.0, 30.0.0, 30.0.0
      System Images: android-29 | Google APIs Intel x86 Atom, android-29 | Google Play Intel x86 Atom
      Android NDK: 21.2.6472646
  IDEs:
    Android Studio: 4.0 AI-193.6911.18.40.6514223
    Xcode: 11.5/11E608c - /usr/bin/xcodebuild
  Languages:
    Java: 1.8.0_252 - /usr/bin/javac
    Python: 2.7.16 - /usr/bin/python
  npmPackages:
    @react-native-community/cli: Not Found
    react: 16.13.1 => 16.13.1 
    react-native: 0.63.1 => 0.63.1 
  npmGlobalPackages:
    *react-native*: Not Found

Steps To Reproduce

Provide a detailed list of steps that reproduce the issue.

1. Create <Pressable /> component
2. Give it an opacity effect with the new style function that supplies the pressed argument
3. See delay between press and effect

Expected Results

The opacity effect/visual feedback should appear instantly, like on the TouchableOpacity.

Snack, code example, screenshot, or link to a repository:

PressableOpacity.ts:

import React, { useCallback } from 'react';
import { Pressable, PressableProps, PressableStateCallbackType, StyleProp, ViewStyle } from 'react-native';

export interface PressableOpacityProps extends PressableProps {
	disabledOpacity?: number;
}

export type StyleType = (state: PressableStateCallbackType) => StyleProp<ViewStyle>;

export default function PressableOpacity(props: PressableOpacityProps): JSX.Element {
	const { style, disabled, disabledOpacity, ...passThroughProps } = props;

	const getOpacity = useCallback(
		(pressed: boolean) => {
			if (disabled) return disabledOpacity ?? 1;
			else return pressed ? 0.6 : 1;
		},
		[disabled, disabledOpacity],
	);
	const _style = useCallback<StyleType>(({ pressed }) => [style, { opacity: getOpacity(pressed) }], [getOpacity, style]);

	return <Pressable style={_style} disabled={disabled} {...passThroughProps} />;
}

Now just use it:

App.js

export default function App() {
  return (<PressableOpacity style={{ width: 200, height: 30 }} onPress={() => console.log('hello!')} />);
}

[cristianoccazinsp]

Still finding this same problem with 0.63.1, and so far the only work around is to monkey patch it to add a default 0 delay.

Note that I'm seeing the odd delay even with TouchableOpacity, not just with Pressables

[mrousavy]

@cristianoccazinsp How did you patch the delay on the Pressable?

[cristianoccazinsp]

I have only patched the Touchable components since I didn't migrate to Pressable (yet), but I'm seeing the exact same issue, and I would guess that Touchables are using Pressable behind the scenes?

My only work around was to patch the default props like this:

TouchableOpacity.defaultProps = TouchableOpacity.defaultProps || {};
TouchableOpacity.defaultProps.delayPressIn = 0;
TouchableWithoutFeedback.defaultProps = TouchableWithoutFeedback.defaultProps || {};
TouchableWithoutFeedback.defaultProps.delayPressIn = 0;

[padapada09]

I am having the same problem. TouchableOpacity is not using Pressable but Pressabilitty API (The same one TouchableOpacity use). That said, Pressable use a hook to use the API, TouchableOpacity is a Class comoponent so it uses the class alternative to use the API. (i don't know if there is any difference between them). Looking to the source code, I can't find a prop or even a reference to a "press in delay". I hope the add such a prop, otherwise Pressable is not usefull for me.

[mrousavy]

Pressability.js contains the prop. Changing this manually (e.g.: on a TouchableOpacity) will remove the delay, and everything works as expected. On a component, you can't set this prop (yet), making it unusable.

[padapada09]

#29395 I've created a pull request to add "delayPressIn" to Pressable.

[radiosilence]

I seem to be getting a delay for onPressIn for all TouchableOpacity, will verify if also affects TouchableWithoutFeedback.

Why on earth would you introduce a default delay on this? Surely the whole point of onPressIn is to be right when someone's finger makes contact with the screen?

[padapada09]

I believe the change was made on Pressability API, which all Touchables use. But you can set delayPressIn={0} to fix it.
The problem is with Pressable, cause you can`t change it there.

[jehartzog]

While not much better than a monkey-patch, you can use patch-package to change these defaults that should globally to everything affected by this recent change.

We recently upgraded from 61.4 to 63.1 and immediately noticed a significant difference in all of our touch handling (we primarily use `TouchableOpacity).

Looks like this delay option was added here with a sensible default of 0. It seems like this default may not have been intended, and it was fixed here.

I'm guessing the idea of this delay is to avoid a technically incorrect visual response of a touch on a child touchable during a scroll swipe, since the touch events first goes to the child before being correctly captured by the parent ScrollView. I agree with this desire, but it seems very difficult to do on the JS side without introducing noticeable delay to nearly all touches, as this thread shows.

Either way it's a significant change from the previous default, unintended or not, that should either by identified on changelog (I checked a few times and didn't see it), or reverted and re-introduced with the change made clear to developers.

Edit: Fixed link to when delay option added

[mrousavy]

@jehartzog That's the only use case that would make sense, and even then an opt-in would be a way better option. If I actually have the use case of the scroll view, I can manually increase the pressable's delay instead of the other way around.

[andreialecu]

This seems like a major regression, especially when navigation is involved.

Buttons don't have a chance to highlight before new screens render, making the entire interface feel static and non interactive.

Note that we don't even use Pressable at all, just react-native-paper and react-navigation. Any UI elements with an onPress that navigate somewhere don't highlight properly since updating to RN 0.63.1. On RN 0.62 it was fine. On react-navigation the navigation header buttons (such as the < Back button on iOS), don't visually respond to touches any more unless they are long pressed.

Adding delayPressIn={0} to react-native-paper buttons (which use TouchableHighlight or TouchableNativeFeedback behind the scenes) fixes it. But this is nonetheless a major regression.

Perhaps @yungsters might know more about this?

[yungsters]

Thanks for the tag, @andreialecu.

I'd like to share some history, the purpose of the delay, what changed recently, and what I propose that we do next.

The default "press in" delay of 130ms was always in Touchable.Mixin, but it was accidentally always overridden to zero by TouchableWithoutFeedback, et al.

The purpose of this delay is to prevent accidental activations when a user initiates a scroll gesture. For example, if you have a <ScrollView> and a <Pressable> within it, we do not want the <Pressable>'s "pressed" style to be displayed if the user only happened to press it as the start of a scrolling / swiping gesture. The 130ms delay creates enough time for the <ScrollView> to emit a cancel event if a scroll gesture is detected.

Keep in mind that when a "press out" is detected within the 130ms, we immediately fire onPressIn and onPressOut. However, as mentioned above, we still have a problem in which a user who quickly taps an interactive element does not experience any visual feedback. This is because when onPressIn and onPressOut fire instantaneously, the onPressIn visual side effect is not visible. To fix this, we introduced a minimum press duration so that onPressOut will always fire at least 130ms after onPressIn (to give people time to see the visual feedback of the element being pressed).

The fix for preserving the default press in duration was only intended for <Pressable>. But when TouchableWithoutFeedback (et al) was refactored to use Pressability, I forgot to inherit the original bug. We can fix that.

There is still the remaining question of what the default behavior for <Pressable> should be. I recognize the concerns around unnecessary delays, but I also want to highlight the purpose of the delay (to avoid accidental activations on scroll gestures). We could certainly introduce a delayPressIn prop to <Pressable>, but I think we should avoid it if possible because I believe the only use case would be setting delayPressIn={0}.

One thing we could do is change <Pressable> to default to 130ms only when nested within a <ScrollView>. The downside of this approach is that if the scrolling container is rendered by a parent view (outside of React Native), <Pressable> may not know about that and will not behave correctly.

Curious to hear what everyone thinks. Thanks!

[jehartzog]

@yungsters Thanks for writeup.

There are many cases where having this press in delay will cause undesired impacts, even if the delay is refactored to intelligently only apply when it detects itself inside a <ScrollView>. Any CTA style button at the bottom of a ScrollView which triggers a navigation event will have no animation response to a touch which immediately triggers a navigation event. If the code is well designed, the transitions animations should begin firing well before this 130ms delay is over. There is no way for the framework to know if a developer is using this element to trigger a navigation transition vs just altering some local UI state, so I can't think of any way to just fix this perfectly for everyone.

I do recognize the desire to avoid the undesired press animation on a touch that ends up captured by the parent ScrollView, but I don't believe there is a way to do this automatically without making it excessively complicated, and requiring each developer to understand how it's implemented in order to avoid the pitfalls.

My recommendation:

1. Revert back to the pre RN 63 behavior of default delayPressIn={0} for all Pressability derived components, including Pressable.
2. Add the delayPressIn as an optional prop for Pressable.
3. Add to the documentation of Pressable that it's recommended to set delayPressIn={130} for Pressable components inside of ScrollViews, and the reason for doing so. Have a line in there that mentions they may want to avoid this for actions that trigger screen transitions.

Developers who care to actually clean up their UI as much as possible will be able to opt-in to this when needed, and there are no chances of missing the much more important onPress animation on the pressed component itself. I'd much rather get the extra onPress animation briefly on something I'm scrolling with, than risk pressing on something and getting no visual response.

If you do decide to add the behavior to auto apply delayPressIn={130} when inside ScrollView, this should be mentioned in docs (and not just source code) so developers are warned that if they fire navigation events from this, they will not get the expected onPress animation.

[andreialecu]

One thing we could do is change to default to 130ms only when nested within a . The downside of this approach is that if the scrolling container is rendered by a parent view (outside of React Native), may not know about that and will not behave correctly.

I'm not sure this would help. In my experience most pressables would be nested inside ScrollViews.

The most noticeable issue I saw from the added delay in 0.63 was that TouchableHighlights that were rendered as list items were not changing their background prior to triggering a navigation somewhere else. Since they were already in a FlatList, this fix wouldn't help in that case and I would still need to set delayPressIn={0}.

It would also make it inconsistent and I feel users wouldn't understand what's going on.

I have been looking at how other apps do it for a bit, and I noticed that in Outlook for iOS for example, when you tap an email, there's a slight delay (several miliseconds) before it navigates to the screen that shows the email. It's enough time to show visual indication that you tapped on something. And there are no "accidental activations" when scrolling.

Note that I have no experience with Pressable yet, so I'm writing this from a Touchable* perspective.

How about something like this:

1. When the user releases the tap, the Touchable*'s visuals are immediately updated to show feedback of the tap.
2. A very small amount of time later (timeout of 10ms? requestAnimationFrame?), onPress is called.

Would this not work? (Note that there would need to be a way to prevent repeated taps from triggering onPress multiple times in quick succession - otherwise it may introduce additional bugs such as navigating twice, etc)