Gesture Responder System lifecycle

WHAT THIS TESTS This probes understanding of the lower-level touch system that underlies touchables, and the negotiation that decides which single view owns a gesture.

A GOOD ANSWER COVERS The Gesture Responder System designates exactly one view as the responder for a given active touch, so touches do not fire on many views at once. A view declares interest by returning true from onStartShouldSetResponder, evaluated when a touch begins, or from onMoveShouldSetResponder, evaluated as the finger moves. The distinction is timing and intent: onStartShouldSetResponder is for views that want the touch immediately on contact, like a button; onMoveShouldSetResponder lets a view wait and claim the gesture only once movement occurs, which is how you distinguish a scroll or drag from a simple tap so a child can take a tap while a parent takes a drag. There is also a capture variant, onStartShouldSetResponderCapture and onMoveShouldSetResponderCapture, letting an ancestor intercept before children. Once a view wins, onResponderGrant fires, then onResponderMove during movement, and onResponderRelease when the touch ends, with onResponderTerminate if the responder is taken away, for example by a scroll.

COMMON WRONG ANSWERS Believing multiple views simultaneously handle one touch. Confusing the should-set negotiation with the grant and release lifecycle. Forgetting the capture phase that lets parents intercept.

LIKELY FOLLOW-UPS What is the capture phase for? How does this relate to react-native-gesture-handler? What causes onResponderTerminate?

ONE CONCRETE EXAMPLE In a draggable card inside a scroll area, the card returns false from onStartShouldSetResponder so a quick tap is not stolen, but returns true from onMoveShouldSetResponder once the finger moves enough, claiming the drag. It then receives onResponderMove updates to follow the finger and onResponderRelease to settle, while the parent scroll yields ownership.