Academy
hardExtra#98

Gesture handler swipeable row

Prompt

Create a swipeable list row using react-native-gesture-handler + Reanimated that reveals a "Delete" button when swiped left. Clamp the drag to the left, snap open past a threshold, and make sure the pan doesn't steal the list's vertical scroll.

Solution

export default function SwipeableRow({ children, onDelete }) {
  const translateX = useSharedValue(0)

  const pan = Gesture.Pan()
    .activeOffsetX([-10, 10]) // let vertical drags go to the list
    .onUpdate((e) => {
      translateX.value = Math.min(0, e.translationX)
    })
    .onEnd(() => {
      translateX.value = withSpring(translateX.value < -80 ? -100 : 0)
    })

  const animatedStyle = useAnimatedStyle(() => ({
    transform: [{ translateX: translateX.value }],
  }))

  return (
    <GestureDetector gesture={pan}>
      <View style={{ flexDirection: 'row' }}>
        <Animated.View style={[{ flex: 1 }, animatedStyle]}>
          {children}
        </Animated.View>
        <Button title="Delete" onPress={onDelete} />
      </View>
    </GestureDetector>
  )
}
Mentor's take

The reason this stack — gesture-handler plus Reanimated — is the modern answer is thread placement: onUpdate/onEnd and useAnimatedStyle run as worklets on the UI thread, so the row tracks the finger at frame rate even while the JS thread is busy rendering the rest of the list. The gesture never waits on React.

The mechanics worth narrating: Math.min(0, e.translationX) clamps the drag to the left — no right-swipe overshoot. onEnd implements snap semantics: past the -80 threshold, commit to the open position revealing Delete; otherwise spring home. withSpring gives the release physical feel instead of a linear slide. And useAnimatedStyle is the only correct way to bind a shared value to style — reading translateX.value in the render body doesn't subscribe to anything, so the UI would never move.

The detail interviewers use to separate seniors: activeOffsetX([-10, 10]). Inside a scrollable list, an unconstrained pan captures vertical drags too, and your list stops scrolling wherever a row sits. The offset makes the pan activate only after clear horizontal intent, yielding everything else to the scroll view.

Red flag: reaching for PanResponder with JS-driven Animated.event — every move event crosses to the JS thread, so the row stutters exactly when the app is busy, which is exactly when users are scrolling.

Say it: "The pan and the spring run as worklets on the UI thread, so a busy JS thread can't drop the gesture — and activeOffsetX is what keeps my horizontal swipe from stealing the list's vertical scroll."