The Gesture Responder System: Who Gets the Touch?

WHY IT EXISTS In a nested UI, a single touch is ambiguous. Is it a tap on a button, or the start of a scroll on its parent container? The Gesture Responder System was created to solve this by allowing components to negotiate for control of a touch gesture, preventing conflicts without needing direct knowledge of their parents or children.

THE MENTAL MODEL Think of it as a negotiation. When a touch occurs, the system asks components if they want to handle it. By default, it asks the most deeply nested component first. If that component says "yes," it becomes the "responder" and receives all subsequent touch information. It holds this role until the gesture ends, or until another component requests and is granted control.

HOW IT WORKS A view can request to become the responder by returning true from onStartShouldSetResponder (on initial touch) or onMoveShouldSetResponder (during movement). If the system grants the request, onResponderGrant is called. The view now receives updates via onResponderMove and onResponderRelease. If another component wants to take over, the current responder's onResponderTerminationRequest is called. If it returns true, it loses control and onResponderTerminate is fired. This negotiation process bubbles up from the deepest child to the outermost parent. To invert this, a parent can use the capture phase (onStartShouldSetResponderCapture) to intercept a touch before its children see it.

WHEN TO USE IT Use the raw responder system for custom, complex gestures not covered by standard components. This includes building a draggable element, a swipe-to-delete interaction, or a pinch-to-zoom view. It gives you fine-grained control over the entire touch lifecycle and how components cooperate.

WHEN NOT TO USE IT For simple taps, avoid this system's complexity. Use the built-in Touchable components like TouchableOpacity or TouchableHighlight. They are abstractions built on top of the responder system, designed specifically to make a view behave like a button or link without the boilerplate.

ONE CANONICAL EXAMPLE Consider a scrollable list with tappable items. When a user presses an item, the system first asks the item if it wants to respond (bubbling). If the user taps and releases, the item handles the press. If the user presses and drags, the parent ScrollView can see the movement, request to become the responder via onMoveShouldSetResponder, and take control to initiate a scroll. The item is then told to terminate its response.