Summary:
We're spreading this in via `...ViewPropTypes` also. Having both confuses
flow when you try to pass style (even though they're identical), when the
types are defined via `React.ElementProps`
Reviewed By: jingc
Differential Revision: D6028659
fbshipit-source-id: 203e29682d34f1648a47d9ddbaef0c9630fbcb99
Summary:
I don't think a test plan is required here! 😛
Closes https://github.com/facebook/react-native/pull/16243
Differential Revision: D6005196
Pulled By: hramos
fbshipit-source-id: 3b46346e57e0d9971078c4807a4fa0045a8366b1
Summary:
When false, ScrollView disables use of pinch gestures to zoom in and out. This allows ScrollView's pinch gesture responder to be disabled to only allow zooming programmatically. The default value is ~false~ true.
**Test Plan**
Tested that pinch gesture responder is disabled when pinchEnabled=false.
/cc nicklockwood sahrens
🍺
Closes https://github.com/facebook/react-native/pull/10037
Differential Revision: D5491953
Pulled By: shergin
fbshipit-source-id: eae16f92ec616e415b4ddacfccb84c697582daf9
Summary:
In iOS11, Apple added a new layout feature called "Safe Areas" (this blog post talks a bit about it: https://www.bignerdranch.com/blog/wwdc-2017-large-titles-and-safe-area-layout-guides/).
UIScrollView is one component that is affected by this change in Apple's API. When the `contentInsetAdjustmentBehavior` is set to `automatic`, for example, it will adjust the insets (and override any manually set insets) automatically based on whether or not there's a UINavigationBar, a UITabBar, a visible status bar, etc on the screen. Frustratingly, Apple decided to default to `Automatic` for this behavior, which will cause any apps that set contentInset/contentContainerStyle padding to have their values offset by, at the very least, the size of the status bar, when they compile their app for iOS 11. Here's more information about this behavior: https://developer.apple.com/documentation/uikit/uiscrollview/2902261-contentinsetadjustmentbehavior?language=objc
Mostly, this is a really straightforward change -- it simply adds a new iOS-only prop to ScrollView that allows setting `contentInsetAdjustmentBehavior`. But I did decide to default the behavior to `never`, so that it mimics the behavior we've seen in iOS < 11. I think it's good to keep something as crucial as scrollview content insets non-magical, and also keep it behaving similarly between platforms.
Closes https://github.com/facebook/react-native/pull/15023
Reviewed By: javache
Differential Revision: D5517552
Pulled By: hramos
fbshipit-source-id: c9ce4bf331b3d243228268d826fdd4dcee99981d
Summary:
In iOS11, Apple added a new layout feature called "Safe Areas" (this blog post talks a bit about it: https://www.bignerdranch.com/blog/wwdc-2017-large-titles-and-safe-area-layout-guides/).
UIScrollView is one component that is affected by this change in Apple's API. When the `contentInsetAdjustmentBehavior` is set to `automatic`, for example, it will adjust the insets (and override any manually set insets) automatically based on whether or not there's a UINavigationBar, a UITabBar, a visible status bar, etc on the screen. Frustratingly, Apple decided to default to `Automatic` for this behavior, which will cause any apps that set contentInset/contentContainerStyle padding to have their values offset by, at the very least, the size of the status bar, when they compile their app for iOS 11. Here's more information about this behavior: https://developer.apple.com/documentation/uikit/uiscrollview/2902261-contentinsetadjustmentbehavior?language=objc
Mostly, this is a really straightforward change -- it simply adds a new iOS-only prop to ScrollView that allows setting `contentInsetAdjustmentBehavior`. But I did decide to default the behavior to `never`, so that it mimics the behavior we've seen in iOS < 11. I think it's good to keep something as crucial as scrollview content insets non-magical, and also keep it behaving similarly between platforms.
Closes https://github.com/facebook/react-native/pull/15023
Differential Revision: D5441491
Pulled By: shergin
fbshipit-source-id: 7b56ea290f7f6eca5f1d996ff8488f40b866c2e6
Summary:
Similar to `TextInput`'s `returnKeyType`, comments allow to see at a glance which options are cross-platform and which are not.
<!--
Thank you for sending the PR!
If you changed any code, please provide us with clear instructions on how you verified your changes work. In other words, a test plan is *required*. Bonus points for screenshots and videos!
Please read the Contribution Guidelines at https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md to learn more about contributing to React Native.
Happy contributing!
-->
Closes https://github.com/facebook/react-native/pull/14780
Differential Revision: D5480895
Pulled By: hramos
fbshipit-source-id: c38337def920678d29c8322e52b54f57e80cb95b
Summary:
<!--
Thank you for sending the PR!
If you changed any code, please provide us with clear instructions on how you verified your changes work. In other words, a test plan is *required*. Bonus points for screenshots and videos!
Please read the Contribution Guidelines at https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md to learn more about contributing to React Native.
Happy contributing!
-->
Closes https://github.com/facebook/react-native/pull/15158
Differential Revision: D5479401
Pulled By: shergin
fbshipit-source-id: d4864e1630a36deb1a227c1b6242255ac1f788e6
Summary:
<!--
Thank you for sending the PR!
If you changed any code, please provide us with clear instructions on how you verified your changes work. In other words, a test plan is *required*. Bonus points for screenshots and videos!
Please read the Contribution Guidelines at https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md to learn more about contributing to React Native.
Happy contributing!
-->
Closes https://github.com/facebook/react-native/pull/15156
Differential Revision: D5479265
Pulled By: shergin
fbshipit-source-id: a2dfa3a4357e126838a17dac4797d1d845cd56ae
Summary:
<!--
Thank you for sending the PR!
If you changed any code, please provide us with clear instructions on how you verified your changes work. In other words, a test plan is *required*. Bonus points for screenshots and videos!
Please read the Contribution Guidelines at https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md to learn more about contributing to React Native.
Happy contributing!
-->
Closes https://github.com/facebook/react-native/pull/15144
Differential Revision: D5478574
Pulled By: shergin
fbshipit-source-id: 33c49f0efdfb3a518e1ee254b1dc01ec22f09269
Summary:
Current description is misleading (without looking at implementation) to believe that both horizontal and vertical pagination are supported on both platforms. This comment clarifies that vertical pagination is not supported on Android.
Closes https://github.com/facebook/react-native/pull/14844
Differential Revision: D5393488
Pulled By: hramos
fbshipit-source-id: e79246a65e1011b2667e7eea67e85e17394026a8
Summary:
This replaces all uses of `React.createClass` with `createReactClass` from the `create-react-class` package, attempting to match use of `var` and `const` according to local style.
Fixes#14620
Refs #14712
Closes https://github.com/facebook/react-native/pull/14729
Differential Revision: D5321810
Pulled By: hramos
fbshipit-source-id: ae7b40640b2773fd89c3fb727ec87f688bebf585
Summary:
Subview clipping still causes issues on Android and would be pretty hard to fix properly, I investigated this a bit and sticky header views are getting removed because it doesn't take transform into consideration. It would also require to recalculate subview clipping on every transform change so I think it is better to just disable subview clipping in when there are sticky headers, especially since we seem to be moving away from subview clipping with things like FlatList.
**Test plan**
Tested that sticky headers work in ListView paging example.
Fixes#14000
Closes https://github.com/facebook/react-native/pull/14010
Differential Revision: D5283723
Pulled By: sahrens
fbshipit-source-id: 183b3202765ae09aaae05497694c3f514e969ea1
Summary: Optimize ScrollView by adding flag "DEPRECATED_sendUpdatedChildFrames" to gate whether updatedChildFrames data is computed and propagated on scroll events. The frame data is used in ListView by the onChangeVisibleRows prop. When this prop is not defined, unnecessary computation in ScrollView should not be performed.
Reviewed By: sahrens
Differential Revision: D5174898
fbshipit-source-id: e3eaed8760b76becf14dfeb00122bdebdaeae4ef
Summary:
Flashing scroll indicators is a standard behavior on iOS to show the user there's more content.
Launch RNTester on iOS, go to the ScrollView section, tap the "Flash scroll indicators" button.
You'll see this:
I've exposed the method `flashScrollIndicators` on all scrolling components that were already exposing a `scrollToXXX` method so it's usable from those components using a ref.
Let me know what you think.
Closes https://github.com/facebook/react-native/pull/14058
Differential Revision: D5103239
Pulled By: shergin
fbshipit-source-id: caad8474fbe475065418d771b17e4ea9766ffcdc
Summary:
The documentation for the prop `scrollEnabled` on the `ScrollView` component does not clarify that scrolling is still possible by calling `scrollTo` on the view ref.
Please see [this expo snack demo](https://snack.expo.io/BJKTVMM-Z) showing scrolling is allowed while `scrollEnabled` is `false`.
This PR makes the documentation for this prop more clear, in that setting it to false will only disable scrolling by touches, not universally.
In my opinion, this also raises the question of a need for an additional prop which would disable all scrolling, even when calling `scrollTo`.
I have attached a screenshot of what this part of the documentation looks like with my edit:
Closes https://github.com/facebook/react-native/pull/14140
Differential Revision: D5138593
Pulled By: shergin
fbshipit-source-id: db1a5f9c8ac41ecfce952e7b1fce9428b2068162
Summary:
There was an issue that sometimes sticky headers would stop moving when re-rendering because we did not reattach events properly. This makes sure that we always detach and reatach on rerender in case the scroll view ref changes.
**Test plan**
Tested that this fixes issues with sticky headers we discovered when updating Expo to RN 0.44.
Closes https://github.com/facebook/react-native/pull/14012
Differential Revision: D5094418
Pulled By: javache
fbshipit-source-id: a56050ae786712e8a3de2a6e3b4e8749a2fde86e
Summary:
This PR updates the example of scrollTo that uses `;` instead of `,` to separate x, y and animated values.
Closes https://github.com/facebook/react-native/pull/13318
Differential Revision: D4913285
Pulled By: javache
fbshipit-source-id: 02c219fbeae0f9e3b63f4b64eb4cca34868641c1
Summary:
Use `getChildDrawingOrder` instead of reordering views. The old implementation didn't work properly when `removeClippedSubviews` was enabled and this one should have better performance since we don't play with the view hierarchy at all.
This fixes weird bugs with sticky headers in `SectionList` and allows removing the hack that disabled `removeClippedSubviews` when using sticky section headers.
**Test plan**
Tested using the SectionList and ListViewPaging examples that use sticky headers which uses z-index.
Closes https://github.com/facebook/react-native/pull/13105
Reviewed By: sahrens
Differential Revision: D4765869
Pulled By: achen1
fbshipit-source-id: be3c824658a3ce965b6e7324ad95c77cbd8a86ae
Summary:
This adds support for both automagical sticky section headers in
`SectionList` as well as the more free-form `stickyHeaderIndices` on
`FlatList` or `VirtualizedList`.
The basic concept is to take the initial `stickySectionHeaders` and remap them
to the indices corresponding to the mounted subset in the render window. The
main trick here is that the currently stuck header might itself be outside of
the render window, so we need to search the gap to see if that's the case and
render it (with spacers above and below it instead of one big spacer).
In the `SectionList` we simply pre-compute the sticky headers at the same time
as when we scan the sections to determine the flattened length and pass those
to `VirtualizedList`.
This also requires some updates to `ScrollView` to work in the churny
environment of `VirtualizedList`. We propogate the keys on the children to the
animated wrappers so that as items are removed and the indices of the
remaining items change, react can keep proper track of them. We also fix the
scroll back case where new headers are rendered from the top down and aren't
updated with the `setNextLayoutY` callback because the `onLayout` call for the
next header happened before it was mounted. This is done by just tracking all
the layout values in a map and providing them to the sticky components at
render time. This might also improve perf a little by property configuring the
animations syncronously instead of waiting for the `onLayout` callback. We
also need to protect against stale onLayout callbacks and other fun stuff.
== Test Plan ==
https://www.facebook.com/groups/react.native.community/permalink/940332509435661/
Scroll a lot with and without debug mode on. Make sure spinner
still spins and there are no crashes (lots of crashes during development due
to the animated configuration being non-monotonic if anything stale values get
through). Also made sure that tapping a row to change it's height would
properly update the animation configurations so the collision point would
still be correct.
Reviewed By: yungsters
Differential Revision: D4695065
fbshipit-source-id: 855c4e31c8f8b450d32150dbdb2e07f1a9f9f98e
Summary:
**Motivation**: On tvOS, Flatview and other components that use ScrollView with a RefreshControl will break without this change.
**Test plan**: Manual testing on tvOS simulator.
Closes https://github.com/facebook/react-native/pull/12751
Differential Revision: D4669503
fbshipit-source-id: 320036571788dc0102ec2611492d0fc97bceb53b
Summary:
Enable back navigation on Apple TV (with the remote's menu button) in code making use of BackAndroid. The module is renamed to BackHandler. BackAndroid is still exported to ReactNative for now, until external projects switch to using the new name for the module. The navigation in https://github.com/react-community/react-navigation makes use of this module.
**Test plan**: Manual testing with an example app (https://github.com/dlowder-salesforce/react-nav-example).
Closes https://github.com/facebook/react-native/pull/12571
Differential Revision: D4665152
Pulled By: ericvicenti
fbshipit-source-id: 925400ce216379267e014457be6f5eedbe4453ec
Summary:
Remove the native iOS sticky headers implementation that has been replaced by the js Animated one. Also remove a line in JS that made sure we passed null to native so it did not use the native implementation.
**Test plan**
Made sure there were no more mentions of sticky / header in native ScrollView related code.
Tested that sticky headers still work :o
Closes https://github.com/facebook/react-native/pull/12696
Differential Revision: D4657391
Pulled By: ericvicenti
fbshipit-source-id: 16324a45ca4ce5cd143293c61394a0fa7ad0c4a1
Summary:
We're seeing ` inputRange must be monotonically increasing -1,0,0,-33,-32 ` which happens when we
have zero height headers, wherever those come from...maybe rendering null?
The math was also off and didn't handle variable height headers correctly, and it was confusing
because it was `setNextHeaderY` with the header y _minus it's height_, which only works
if the prev height was also the same height.
Reviewed By: furdei
Differential Revision: D4649404
fbshipit-source-id: c2c2d438fa0d0b979c2cbdfa5752eaf86c14768b
Summary:
This re-implements sticky headers in JS to make it work on Android.
The only change that was needed was to expose a way to attach a an animated value to an event manually since we can't use the Animated wrapper and `Animated.event` to do it for us because this is implemented directly in the `ScrollView` component. Simply exposed `attachNativeEvent` that takes a ref, event name and event object mapping. This is what is used by `Animated.event`.
TODO:
- Need to check why momentum scrolling isn't triggering scroll events properly on Android.
- Remove native iOS implementation
- cleanup / fix flow
**Test plan**
Test the example list in UIExplorer, test the ListViewPaging example.
Closes https://github.com/facebook/react-native/pull/11315
Differential Revision: D4450278
Pulled By: sahrens
fbshipit-source-id: fec8da2cffce9807d74f8e518ebdefeb6a708667
Summary:
Added a note to the `refreshControl` prop on ScrollView to call out that the prop only works for vertical ScrollViews.
Fixes#12139
Closes https://github.com/facebook/react-native/pull/12150
Differential Revision: D4508796
Pulled By: mkonicek
fbshipit-source-id: 8e71692f29ee175e32177c3a26a4ed2e8d14f139
Summary:
This prop exposes the functionality provided by Android ScrollView's setOverScrollMode method.
One interesting thing to note is that, if you were to read the Android docs, you would think that the value "always" is the default over scroll mode. However, the docs are incorrect and "always-if-content-scrolls" is actually the default value (http://stackoverflow.com/a/27116306).
**Test plan (required)**
Verified this change in a test app. Also, our team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10905
Differential Revision: D4500957
Pulled By: mkonicek
fbshipit-source-id: 873eba38183defba133c228e0c1038efa83297d3
Summary:
This is a followup for https://github.com/facebook/react-native/pull/12088 and implements the scrolling to end on Android natively rather than sending a large scroll offset from JS.
This turned out to be an OK amount of code, and some reduction in the amount of JavaScript. The only part I'm not particularly happy about is:
```
// ScrollView always has one child - the scrollable area
int bottom = scrollView.getChildAt(0).getHeight() + scrollView.getPaddingBottom();
```
According to multiple sources (e.g. [this SO answer](http://stackoverflow.com/questions/3609297/android-total-height-of-scrollview)) it is the way to get the total size of the scrollable area, similar to`scrollView.contentSize` on iOS but more ugly and relying on the fact the ScrollView always has a single child (hopefully this won't change in future versions of Android).
An alternative is:
```
View lastChild = scrollLayout.getChildAt(scrollLayout.getChildCount() - 1);
int bottom = lastChild.getBottom() + scrollLayout.getPadd
Closes https://github.com/facebook/react-native/pull/12101
Differential Revision: D4481523
Pulled By: mkonicek
fbshipit-source-id: 8c7967a0b9e06890c1e1ea70ad573c6eceb03daf
Summary:
Right now, the ScrollView's keyboard hiding behavior is either all or nothing: Hide the keyboard on any tap, or do nothing ever. This PR introduces a third mode to keyboardShouldPersistTaps which is much closer to what I consider should be the default.
In the new behavior, the tap responding is done in the bubbling phase (instead of the capture phase like =true). As a result, a child can handle the tap. If no child does, then the ScrollView will receive the tap and will hide the keyboard. As a result, changing TextInput focus works as a user expects, with a single tap and without keyboard hiding. But taping on Text or on the empty part of the ScrollView hides the keyboard and removes the focus.
You can view the behavior in a monkey patched ScrollView demo on rnplay:
https://rnplay.org/apps/E90UYwhttps://rnplay.org/apps/UGzhKA
In order to have a uniform props set, i added 3 values to the keyboardShouldPersistTaps:
'never' and 'always' are the same as false and true.
'handled' is the new behavior.
I don't
Closes https://github.com/facebook/react-native/pull/10628
Differential Revision: D4294945
Pulled By: ericvicenti
fbshipit-source-id: 1a753014156cac1a23fabfa8e1faa9a768868ef2
Summary:
Internal research at FB has shown that many devs don't know why they should use ListView instead of ScrollView, or that ListView even exists. This PR changes ScrollView's docs to upsell ListView.
I could put this as a separate guide in the docs, but I think this place will have the best possible reach for target audience.
Suggestions welcome. Let me know if it doesn't make sense or is too verbose.
Closes https://github.com/facebook/react-native/pull/11349
Differential Revision: D4292109
Pulled By: mkonicek
fbshipit-source-id: e4a14e5a55333c9282d0e407461505e71e850b20
Peter Ruibal
Masayuki Iwai
Yann Pringault
Sam Goldman
Matt Bruce
Marshall Roch
Caleb Meredith
Jake Murzy
Adam Miskiewicz
Saad Ismail
Taylor Kline
Tomas Reimers
Sean Wang
Seth Fitzsimmons
Spencer Ahrens
Brian Vaughn
Janic Duplessis
John O'Leary
Jean Regisser
Chris Knepper
James Isaac
Fran
Steffen Forkmann
Spencer Ahrens
Jakob Kerkhove
Douglas Lowder
Jeff Morrison
Jon Cursi
Valentin Shergin
Adam Comella
Martin Konicek
Maxime Lapointe
Martin Konicek
