Invoke this from an onResponderReject event.
Some other element is not yielding its role as responder. Normally, we'd
just disable the UIScrollView, but a touch has already began on it, the
UIScrollView will not accept being disabled after that. The easiest
solution for now is to accept the limitation of disallowing this
altogether. To improve this, find a way to disable the UIScrollView after
a touch has already started.
Merely touch starting is not sufficient for a scroll view to become the responder. Being the "responder" means that the very next touch move/end event will result in an action/movement.
Invoke this from an onStartShouldSetResponder event.
onStartShouldSetResponder is used when the next move/end will trigger
some UI movement/action, but when you want to yield priority to views
nested inside of the view.
There may be some cases where scroll views actually should return true
from onStartShouldSetResponder: Any time we are detecting a standard tap
that gives priority to nested views.
If a single tap on the scroll view triggers an action such as recentering a map style view yet wants to give priority to interaction views inside (such as dropped pins or labels), then we would return true from this method when there is a single touch.
Similar to the previous case, if a two finger "tap" should trigger a
zoom, we would check the touches count, and if >= 2, we would return
true.
There are times when the scroll view wants to become the responder
(meaning respond to the next immediate touchStart/touchEnd), in a way
that doesn't give priority to nested views (hence the capture phase):
Invoke this from an onStartShouldSetResponderCapture event.
We will allow the scroll view to give up its lock iff it acquired the lock during an animation. This is a very useful default that happens to satisfy many common user experiences.
Invoke this from an onTouchEnd event.
Event.
Invoke this from an onTouchMove event.
Since we know that the SimpleEventPlugin occurs later in the plugin
order, after ResponderEventPlugin, we can detect that we were not
permitted to be the responder (presumably because a contained view became
responder). The onResponderReject won't fire in that case - it only
fires when a current responder rejects our request.
Touch Start event.
Invoke this from an onTouchStart event.
Since we know that the SimpleEventPlugin occurs later in the plugin
order, after ResponderEventPlugin, we can detect that we were not
permitted to be the responder (presumably because a contained view became
responder). The onResponderReject won't fire in that case - it only
fires when a current responder rejects our request.
Touch Start event.
The calculations performed here assume the scroll view takes up the entire screen - even if has some content inset. We then measure the offsets of the keyboard, and compensate both for the scroll view's "contentInset".
Position of input w.r.t. table view.
Position of input w.r.t. table view.
Width of the text input.
Height of the text input.
Warning, this may be called several times for a single keyboard opening.
It's best to store the information in this method and then take any action
at a later point (either in keyboardDidShow or other).
Here's the order that events occur in:
The ScrollResponder providesModule callbacks for each of these events.
Even though any user could have easily listened to keyboard events
themselves, using these props callbacks ensures that ordering of events
is consistent - and not dependent on the order that the keyboard events are
subscribed to. This matters when telling the scroll view to scroll to where
the keyboard is headed - the scroll responder better have been notified of
the keyboard destination before being instructed to scroll to where the
keyboard will be. Stick to the ScrollResponder callbacks, and everything
will work.
WARNING: These callbacks will fire even if a keyboard is displayed in a different navigation pane. Filter out the events to determine if they are relevant to you. (For example, only if you receive these callbacks after you had explicitly focused a node etc).
This method should be used as the callback to onFocus in a TextInputs' parent view. Note that any module using this mixin needs to return the parent view's ref in getScrollViewRef() in order to use this method.
The TextInput node handle
Optional additionalOffset: numberThe scroll view's top "contentInset". Default is 0.
Optional preventNegativeScrollOffset: booleanA helper function to scroll to a specific point in the scrollview. This is currently used to help focus on child textviews, but can also be used to quickly scroll to any element we want to focus. Syntax:
scrollResponderScrollTo(options: {x: number = 0; y: number = 0; animated: boolean = true})
Note: The weird argument signature is due to the fact that, for historical reasons, the function also accepts separate arguments as an alternative to the options object. This is deprecated due to ambiguity (y before x), and SHOULD NOT BE USED.
Optional x: number | { Optional y: numberOptional animated: booleanA helper function to zoom to a specific rect in the scrollview. The argument has the shape {x: number; y: number; width: number; height: number; animated: boolean = true}
Optional animated?: booleanOptional animated: booleanios
Special form of calling
addListenerthat guarantees that a subscription must be tied to a component instance, and therefore will be cleaned up when the component is unmounted. It is impossible to create the subscription and pass it in - this method must be the one to create the subscription and therefore can guarantee it is retained in a way that will be cleaned up.