Gesture Handler and Interactive Transitions

React Native's built-in `Pressable` and touch events on `View` are enough for a button, but they fall apart the moment two gestures need to negotiate over the same touch — a horizontal swipe inside a vertically scrolling list, a pinch-to-zoom photo that also needs to be pannable, or a bottom sheet whose drag handle should win over the scroll view beneath it. The previous lesson introduced Reanimated's worklet model as the answer to running animation logic on the UI thread; this lesson covers the other half of that story, react-native-gesture-handler, which is what actually recognizes gestures using native, platform-level touch handling rather than React Native's JavaScript-driven `PanResponder`, and gives you explicit control over which gesture wins when two are plausible candidates for the same touch.

The failure mode without this discipline is specific: a card meant to swipe horizontally inside a vertical list either steals every vertical scroll attempt near it, or never recognizes a horizontal swipe because the list's own scroll gesture claims the touch first, and toggling between the two by trial and error rarely produces a result that feels right in every direction a user might actually swipe. Gesture composition — deciding explicitly which gestures can run together, which must fail before another begins, and which one gesture should win outright — is what makes an interaction feel deliberate instead of accidental.

This lesson builds on the shared-value and worklet model from the previous lesson and treats a gesture as something with a real lifecycle — begin, update, end, or fail — that has to be reasoned about explicitly against every other gesture recognizer that could plausibly claim the same touch, not assumed to "just work" because a single gesture works fine in isolation during a quick manual test.

Analogy🏏Cricket

🏏 Think of it like cricket: On-field appeal decisions do not resolve by every fielder independently shouting and acting on their own read of what happened — there is an explicit, understood hierarchy for who has authority over which call, and when two fielders' instincts genuinely conflict, that hierarchy resolves it, rather than the match simply grinding into confusion because two players believed different things simultaneously. A wicketkeeper's appeal for a catch behind and a bowler's simultaneous appeal for lbw on the very same ball are two competing claims over the same moment, and the umpire's role is precisely to adjudicate which claim actually applies, explicitly, rather than let both proceed as if they were compatible. Just as an umpire explicitly adjudicates which of two competing appeals actually applies to a single ball, a gesture-handling system explicitly adjudicates which of two competing gesture recognizers actually claims a single touch. Just as a match without a clear adjudication hierarchy would descend into chaos the moment two appeals genuinely conflicted, a screen without explicit gesture composition rules produces a UI that behaves unpredictably the moment two plausible gestures overlap on the same touch. The insight is that competing claims over the same input need an explicit resolution mechanism decided in advance, not an implicit hope that only one claim will ever actually arise.