Summary:
We recently updated React Native's docs site to have its own domain reactnative.dev and needed to update the URLs in the source code
CHANGELOG:
[INTERNAL]
Reviewed By: hramos
Differential Revision: D20072842
fbshipit-source-id: 1970d9214c872a6e7abf697d99f8f5360b3b308e
Summary:
Right now, people are calling `getInnerViewNode` and `getInnerViewRef` to get the ref of the `View` within `ScrollView`. Instead, this change adds a prop to `ScrollView` to give people direct access to that `View` if they need it.
Previous usage:
```
const myRef = React.createRef<React.ElementRef<typeof ScrollView>>();
<ScrollView ref={myRef} />
const innerViewRef = myRef.current.getInnerViewRef();
innerViewRef.measure();
```
New usage:
```
const myRef = React.createRef<React.ElementRef<typeof View>>();
<ScrollView innerViewRef={myRef} />
// now, myRef.current can be used directly as the ref
myRef.current.measure();
```
Changelog:
[Changed][General] ScrollView: Deprecate getInnerViewNode and getInnerViewRef methods. Use innerViewRef={myRef} prop instead.
Reviewed By: TheSavior
Differential Revision: D19713191
fbshipit-source-id: 3304cb94a253dafb458ef49d6331e0e432693431
Summary:
In case when Platform is different from Android or iOS, ScrollView initialised RCTScrollView two times, which caused a crash. It looks for me that default option is obsolete and can be united with iOS one to fix this issue.
## Changelog:
[Internal] [Fixed] - Fixed crash during ScrollView initialisation if Platform.OS is not iOS or Android
Reviewed By: ejanzer
Differential Revision: D19623046
fbshipit-source-id: 84f8a46ea24b463aa6aae761f4386ab7e4e95f9b
Summary:
The flow team is rolling out exact-by-default object types to xplat/js. In order to do that, we need to take all inexact objects `{}` and turn them into explicitly inexact objects `{...}`.
This codemod does not change any type checking behavior. Prettier was run on all of the modified files with `format`.
drop-conflicts
Changelog: [Internal]
Reviewed By: zackargyle
Differential Revision: D18785076
fbshipit-source-id: c89c7fcc9eabe69859c8a488e03185fba5d06f80
Summary:
We are rolling out exact-by-default syntax to xplat/js.
I had to manually move around some comments to preserve proper placement.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D18633611
fbshipit-source-id: 48f7468dcc55b1d00985419d035a61c6820b3abe
Summary:
ScrollView isn't using codegen, therefore we need to manually write commands interface. I also typed commands so it uses `Double` instead of `number`.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D18371887
fbshipit-source-id: 3bd11b9969b80ce6d2302e2f0da28884e9221b7e
Summary:
Add handwritten view config for AndroidHorizontalScrollContentView. Same as RCTScrollContentView, this native component has no props of its own other than what View accepts. It's simply used as a container for the horizontal ScrollView on Android.
Changelog: [Internal]
Reviewed By: rickhanlonii
Differential Revision: D18284673
fbshipit-source-id: 8cd6282a3b2e5c9876da5cc0e068b12dd56acfd8
Summary:
Adding a handwritten view config for AndroidHorizontalScrollView, the native component that's used with `<ScrollView horizontal={true} />` on Android. Native props are the same as `RCTScrollView`, so I'm reusing the type for that.
Changelog: [Internal]
Reviewed By: rickhanlonii
Differential Revision: D18284517
fbshipit-source-id: 7c81f72440b93d611f9574ad2c01a96530d07bf7
Summary:
Adding a handwritten view config for RCTScrollContentView. This host component doesn't actually have any props of its own separate from View; it's just a container for a ScrollView.
Changelog: [Internal]
Reviewed By: rickhanlonii
Differential Revision: D18283792
fbshipit-source-id: db95e981f54bef7c068b907c5d1fa52774dad147
Summary:
Adding a handwritten view config for RCTScrollView, to be used in DEV only (for now).
Changelog: [Internal]
Reviewed By: rickhanlonii
Differential Revision: D18263203
fbshipit-source-id: 975499f030c7caed9851bcde0be42c5058911ad5
Summary:
Changelog: [Internal] Convert scrollTo, scrollToEnd, flashScrollIndicators to use native commands
This was reverted because of a circular dependency that was found in AMA. See D18065033 for fixing the circular dependency
Reviewed By: TheSavior
Differential Revision: D18063703
fbshipit-source-id: 7bd0125833f4f9e9e2f227732af0d6e38f009c06
Summary:
Revert D17983169 since it causes instant crash on AMA
Changelog: [Internal] Revert D17983169
Differential Revision: D18054783
fbshipit-source-id: 2b0957ee266dc034336eb157a5a343d051563389
Summary:
`ReactNative.js` as a side effect registers `RCTEventEmitter`, this is required in Fabric's `RCTScrollViewComponentView`.
Here we force ReactNative.js side effect.
This is needed as a temporary workaround so we can invoke events on `RCTEventEmitter` (old architecture) from `RCTScrollViewComponentView` (new architecture)
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D17931469
fbshipit-source-id: 3efa453ba199bb1685403201ad444238750a3d14
Summary: These types were wrong, this is a HostComponent, not a ReactNative.NativeComponent
Reviewed By: lunaleaps
Differential Revision: D17862305
fbshipit-source-id: e1e7acc7a5892f124b07cdc39d73d6ce7d414063
Summary: The instance type wasn't being set properly. Using AbstractComponent
Reviewed By: lunaleaps
Differential Revision: D17859988
fbshipit-source-id: 95e2098a7218afeaf3f6ee39ba2b69170ee2f54c
Summary: These need to be both optional and nullable to support spreading props like `<ScrollView {...props} />` where these types are optional in a parent component.
Reviewed By: lunaleaps
Differential Revision: D17859633
fbshipit-source-id: 093456d13ee041473a4605e62bf48b3510b49b8f
Summary: These are already defined as part of ViewProps. They don't need to be duplicated
Reviewed By: lunaleaps
Differential Revision: D17859553
fbshipit-source-id: c3de534526efd94c0a9ff2c772a4d92c6164815b
Summary:
If you passed
```
contentInset: { bottom: 10 }
```
then it wouldn't go into the if case and it could try to call `setOffset` with `undefined`. `setOffset` requires a number.
Changelog:
[Fix][ScrollView] ScrollView contentInset top now defaults to 0 in expected situations
Reviewed By: JoshuaGross
Differential Revision: D17796155
fbshipit-source-id: 951dbbb0de1052f64a6835963e8bbc564990c120
Summary:
This function doesn't exist on the scroll responder so this prop is being set to undefined.
As this is an event, not setting the prop just means that nothing will listen to the event.
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D17795678
fbshipit-source-id: 73f2c125e0868e19258b43e3a053447be3f5e768
Summary:
In React Native there are three types of "Native" components.
```
createReactClass with NativeMethodsMixin
```
```
class MyComponent extends ReactNative.NativeComponent
```
```
requireNativeComponent('RCTView')
```
The implementation for how to handle all three of these exists in the React Native Renderer. Refs attached to components created via these methods provide a set of functions such as
```
.measure
.measureInWindow
.measureLayout
.setNativeProps
```
These methods have been used for our core components in the repo to provide a consistent API. Many of the APIs in React Native require a `reactTag` to a host component. This is acquired by calling `findNodeHandle` with any component. `findNodeHandle` works with the first two approaches.
For a lot of our new Fabric APIs, we will require passing a ref to a HostComponent directly instead of relying on `findNodeHandle` to tunnel through the component tree as that behavior isn't safe with React concurrent mode.
The goal of this change is to enable us to differentiate between components created with `requireNativeComponent` and the other types. This will be needed to be able to safely type the new APIs.
For existing components that should support being a host component but need to use some JS behavior in a wrapper, they should use `forwardRef`. The majority of React Native's core components were migrated to use `forwardRef` last year. Components that can't use forwardRef will need to have a method like `getNativeRef()` to get access to the underlying host component ref.
Note, we will need follow up changes as well as changes to the React Renderer in the React repo to fully utilize this new type.
Changelog:
[Internal] Flow type to differentiate between HostComponent and NativeMethodsMixin and NativeComponent
Reviewed By: jbrown215
Differential Revision: D17551089
fbshipit-source-id: 7a30b4bb4323156c0b2465ca41fcd05f4315becf
Summary:
We need to get rid of findNodeHandle calls so migrating scrollResponderScrollNativeHandleToKeyboard to take a ref to a host component.
I made this change with Flow, and tested by rendering UserJobApplicationForm
Reviewed By: mdvacca
Differential Revision: D17099280
fbshipit-source-id: 96af692006aace2c206f268f5416984b00f8a438
Summary: This function was deprecated in Dec 2016. It has no callsites at FB and should be deleted.
Reviewed By: zackargyle, ejanzer
Differential Revision: D17180174
fbshipit-source-id: de3ab78c469220b629ef7f6773d60507959f6db6
Summary: FlatList and VirtualizedList were typing this value as any instead of using the actual type from ScrollView. I started with that change and then fixed the type to solve the other callsites in the codebase.
Reviewed By: zackargyle
Differential Revision: D17089934
fbshipit-source-id: bfc22cec9993904d779cad37b1de7cb3c0484d2c
Summary:
After some thought, we decided we don't need the flexibility of
separate horizontal and vertical props - it would be much nicer
to just have a single prop for the edge length and then the native
code can enable the booleans as appropriate.
Original PR: https://github.com/facebook/react-native/pull/26163
Original commit changeset: f72a9a890d90
Reviewed By: TheSavior
Differential Revision: D16997468
fbshipit-source-id: 7973262287a7ec2cee5957f8dc1806a0f28c1432
Summary: It's ok to put VLists in ScrollViews with different scroll directions.
Reviewed By: yungsters
Differential Revision: D16217209
fbshipit-source-id: 7b1c3e93c19867da7414ccda4cda8cc89d25d522
Summary:
This PR adds support for custom `StickyHeaderComponent` to be used in ScrollView (and by extension in FlatList, SectionList..).
Motivation: I've been working on a FlatList with hidable header that has a search field in it. Something like https://medium.com/appandflow/react-native-collapsible-navbar-e51a049b560a but using a FlatList w/ pull-to-refresh. The implementation can be found at https://snack.expo.io/vonovak/hidable-header-flatlist .
I used the `ListHeaderComponent` prop to render the custom header - as opposed to absolute positioning which is used in the linked article because I also need the loading indicator (I added `refreshing` and `onRefresh` for that) to show up above the header.
I proceeded by adding `stickyHeaderIndices={[0]}` to keep the header at the top, which seems to be the idiomatic way to do so. Then I added `Animated.View` with custom translation logic to the rendered header.
All appears to be working fine at the first sight - when you tap any item, you'll see it react to touch (red underlay). You'll also see the header becomes hidden if I scroll far enough and appears again after scrolling up. BUT - when you scroll down so that the header becomes hidden and tap the first visible item in the list, it will not react to touches! The reason is that `ScrollViewStickyHeader`
https://github.com/facebook/react-native/blob/9a84970c35d22b68fb3d8eac019c7f415a14c888/Libraries/Components/ScrollView/ScrollView.js#L984
has its own translation logic and when I tap onto the item at the top of the list, it seems like I'm tapping the item but I'm in fact tapping that `ScrollViewStickyHeader`.
I tried working around this by not specifying `stickyHeaderIndices={[0]}` and using `ListHeaderComponentStyle` prop (this needed some additional changes in https://github.com/facebook/react-native/blob/9a84970c35d22b68fb3d8eac019c7f415a14c888/Libraries/Lists/VirtualizedList.js#L786, and the animation is junky for some reason - as if the header always needed to "catch up" with the scroll offset, causing jitter) and `CellRendererComponent` (junky animations too), but concluded that allowing to specify custom `StickyHeaderComponent` is the cleanest way to make something like this work. I'm slightly surprised I needed to do all this to make such a usual pattern work - am I missing something?
## Changelog
[GENERAL] [ADDED] - allow custom StickyHeader in ScrollView-based components
Pull Request resolved: https://github.com/facebook/react-native/pull/25428
Test Plan: This is a minor change that should not break anything; tested locally.
Differential Revision: D16073016
Pulled By: cpojer
fbshipit-source-id: cdb878d12a426068dbaa9a54367c1190a6c55328
Summary:
This breaks virtualization, viewability callbacks, and other features, so should be warned against.
Hopefully this would have made D15890785 trivial to figure out.
Reviewed By: PeteTheHeat
Differential Revision: D16040939
fbshipit-source-id: 593cd5da9891450fdcb501aef41455cf2d7baa4f
Summary:
Fixes#22752
On line 1021 you are passing base style to props:
`style: [baseStyle, this.props.style],`
Explicitly passing base style to ScrollView just overrides this line and doesn't let developers to customise style of any inheritors of ScrollView (not only FlatList) with custom RefreshControl.
So this line (1113) seems to be removed.
## Changelog
[GENERAL] [Fixed] - fix of Android's bug that doesn't let override ScrollView's Style with custom RefreshControl.
Pull Request resolved: https://github.com/facebook/react-native/pull/24411
Differential Revision: D15713061
Pulled By: cpojer
fbshipit-source-id: 461259800f867af15e53e0743a5057ea4528ae69
Summary:
This is the next step in moving RN towards standard path-based requires. All the requires in `Libraries` have been rewritten to use relative requires with a few exceptions, namely, `vendor` and `Renderer/oss` since those need to be changed upstream. This commit uses relative requires instead of `react-native/...` so that if Facebook were to stop syncing out certain folders and therefore remove code from the react-native package, internal code at Facebook would not need to change.
See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
[General] [Changed] - Migrate "Libraries" from Haste to standard path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24749
Differential Revision: D15258017
Pulled By: cpojer
fbshipit-source-id: a1f480ea36c05c659b6f37c8f02f6f9216d5a323
Summary: This diff migrates VirtualizedList to use ref.measureLayout instead of UIManager.measureLayout, this is a pre-req to make measureLayout to work in Fabric
Reviewed By: JoshuaGross, TheSavior
Differential Revision: D14865762
fbshipit-source-id: 45dd3374813370188c914acfc7e631075508f74a
Summary: For some reason the scroll events are sometimes generated with highly irregular spacing, some coming less than a millisecond apart. For interactions that must track scrolling exactly, this can cause them to glitch. With a scroll throttle of less than 17 ms, the intention is clear that the UI should be updated in sync with the scroll view so we shouldn't drop any events.
Reviewed By: PeteTheHeat
Differential Revision: D15068841
fbshipit-source-id: 730e7cb29cc3ddae66f37cf7392e02e0cc9d7844
Summary:
Would like feedback from the community as this may not be the best solution for all
I would like to restrict (or paginate) the fling of a horizontal ScrollView when `snapToInterval` is set. This is not currently possible with `pagingEnabled`, since the pagination works only when items are the entire width of the ScrollView.
This implementation simply restricts the predicted `targetOffset` found from the `x` velocity and replaces it with the offset when the pan gesture ended.
To get pagination working, I may paginate based on the interval by calculating the offset delta from the beginning of the gesture to current offset and restricting the scrolling behavior to the `snapToInterval`. If this is preferred, I can update this PR or make a new one, but wanted to start a discussion since it seems like there are many in the community that would like this feature #21302 .
[General] [Added] - add prop `disableIntervalMomentum` to disable the predictive scrolling behavior of horizontal ScrollViews
Pull Request resolved: https://github.com/facebook/react-native/pull/24045
Differential Revision: D14939754
Pulled By: sahrens
fbshipit-source-id: 26be19c47dfb8eed4d7e6035df53a77451e23081
Summary:
ScrollView's scrollTo behavior on iOS was recently changed to limit the offset to the content size plus any content inset (see #23427). This departure from the old behavior created UI issues for anyone that is using the over-scroll ability for the purpose of positioning elements at specific coordinates on the screen. Examples include using this behavior to position TextInputs above the virtual keyboard programmatically when focused or moving drop down elements positioned near the bottom of the content toward the top of the screen when selected to show a larger absolutely positioned item list. Default behavior does not change and this is an "opt-in" type of prop to re-enable the old behavior.
[iOS] [Added] - Added scrollToOverflowEnabled prop to ScrollView
Pull Request resolved: https://github.com/facebook/react-native/pull/24296
Differential Revision: D14762619
Pulled By: cpojer
fbshipit-source-id: d2a552b5cb321d52e8ea4116327bf9ec647a3aae
Summary: D13103990 updated the flow types for ScrollView. This diff just updates our internal callsites to address the flow errors.
Reviewed By: TheSavior
Differential Revision: D14305453
fbshipit-source-id: 58fe28da06a6c83a81ba29bebe96e74c2f3ed5e5
Kacie Bawiec
Rachel Nabors
Arthur Kushka
Mike Vitousek
Nikita Shanin
Eli White
Jordan Brown
George Zahariev
Emily Janzer
Daniel Sainati
Samuel Susla
Emily Janzer
Luna Wei
Yuanzhe Bian
Andres Suarez
André Krüger
Spencer Ahrens
Logan Daniels
Min ho Kim
Vojtech Novak
Пётр Потапов
James Ide
Nat Mote
David Vacca
Taylor123
Craig_Martin
Ramanpreet Nara
