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:
Flatlist's `getItemCount` function is frequently called internally by VirtualizedList.
As with other functions, we can remove unnecessary operations with the `numColumns` value.
This makes it much more efficient.
## Changelog
[Internal] [Changed] - Better implementation for getItemCount on FlatList
Pull Request resolved: https://github.com/facebook/react-native/pull/26164
Test Plan: Not required
Differential Revision: D16989335
Pulled By: sahrens
fbshipit-source-id: b0075b2c2aeb9b9d7644c8bb18702a7cca8a4dce
Summary:
Motivation: when you receive error like `scrollToIndex out of range: 5 vs -1` it's not immediately clear if I requested 5 or -1. This will make the error a little easier to understand.
## Changelog
not needed
Pull Request resolved: https://github.com/facebook/react-native/pull/25973
Test Plan: not needed, tests must pass
Differential Revision: D16708522
Pulled By: osdnk
fbshipit-source-id: 8dfcbd95ff0f42805dbe32cd57969a93aea55add
Summary:
Need to add explicit type annotations in these areas to unblock types-first architecture for Flow. These are locations the codemod could not automatically handle.
I'll call out areas I need a close eye on in the comments.
Reviewed By: panagosg7
Differential Revision: D16659053
fbshipit-source-id: 167dd2abe093019b128676426374c1c62cf71e7f
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 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:
`<VirtualizedList />` will throw an error if the `renderItem` Prop component uses hooks. Function components without hooks and class components work without issue.
Super contrived Example
```{js}
function FlatListItem({ item }) {
React.useEffect(() => console.log(item),[])
return (<Text>{item}</Text>);
}
<FlatList data={[1, 2, 3]} renderItem={FlatListItem} />
```
Example Error:
```
Invariant Violation: Hooks can only be called inside the body of a function component. (https://fb.me/react-invalid-hook-call)
This error is located at:
in CellRenderer (at VirtualizedList.js:688)
in RCTScrollContentView (at ScrollView.js:976)
in RCTScrollView (at ScrollView.js:1115)
in ScrollView (at VirtualizedList.js:1081)
in VirtualizedList (at FlatList.js:632)
in FlatList (at WithoutScrollbars.js:21)
...
```
## Changelog
[General] [Added] - VirtualizedList ListItemComponent. An alternative to renderItem that accepts function components with hooks.
[General][Added] - FlatList ListItemComponent. An alternative to renderItem that accepts function components with hooks.
[General][Added] - VirtualizedList and FlatList tests and updated RNTester example
Pull Request resolved: https://github.com/facebook/react-native/pull/24832
Reviewed By: sahrens
Differential Revision: D15334020
Pulled By: cpojer
fbshipit-source-id: 882db722fd6e22f07260b08091b3456d1c66c2c8
Summary:
first, I edited this post so that the comment below are NOT relevant any more
problem: `scrollToLocation` behavior in SectionList on master is inconsistent between platforms.
Recently, there have been two PRs changing this function: https://github.com/facebook/react-native/pull/21577 and https://github.com/facebook/react-native/pull/24034
let me just quote the [docs](https://facebook.github.io/react-native/docs/sectionlist#scrolltolocation) here
> Scrolls to the item at the specified sectionIndex and itemIndex (within the section)
originally, the code was `let index = params.itemIndex + 1;`
so if we call
```js
node.scrollToLocation({
animated: false,
itemIndex: 0,
sectionIndex: 0,
viewPosition: 0,
viewOffset: 0,
});
```
inside scrollToLocation, index is incremented and that results into the list scrolling to the first item (the first section heading is not visible - see the gif). If I specify `itemIndex = -1`, it will scroll all the way up. I was expecting `itemIndex = 0` to bring me all the way up, so that the first section heading is visible. Not sure which way this should work but at least this behavior is in line with the docs.
next, there was https://github.com/facebook/react-native/pull/21577 that changed it to
`let index = Platform.OS === 'ios' ? params.itemIndex: params.itemIndex - 1;`
so that https://github.com/facebook/react-native/issues/18098 is fixed. The PR had a bug and so next, there was https://github.com/facebook/react-native/pull/24034 that changed it to
`let index = Platform.OS === 'ios' ? params.itemIndex : params.itemIndex + 1;`
the reasoning was
> Note however, how the sign for non iOS changed from + to - causing a crash on Android when trying to scroll to index 0 as that will be evaluated to -1 instead of 1 and thus be out of bounds.
with this change, the list does not crash. However, the behavior is not consistent between platforms (see gifs):
So, this PR works under the assumption that
```js
node.scrollToLocation({
animated: false,
itemIndex: 0,
sectionIndex: 0,
viewPosition: 0,
viewOffset: 0,
});
```
should scroll all the way up, so that even the first section heading is visible. This should keep this bug https://github.com/facebook/react-native/issues/18098 fixed. However, this change means different behavior from how it used to be and from how it is documented, which should be pointed out in release notes and docs need to be updated.
Finally, if we agree this is the way to go, it'd be nice to have some automated tests.
cc melina7890 danilobuerger
[Android][Fixed] - fix scrollToLocation not consistent between platforms
Pull Request resolved: https://github.com/facebook/react-native/pull/24734
Differential Revision: D15334565
Pulled By: cpojer
fbshipit-source-id: f7122ef4a5c252fc3e0d2112861d1460742e9fa4
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:
When using `scrollToLocation` together with `stickySectionHeadersEnabled` in a `SectionList`, the length of the section header is not accounted for when scrolling to any item except the header.
[General] [Fixed] - Adjust scrollToLocation when using sticky section headers
Pull Request resolved: https://github.com/facebook/react-native/pull/24735
Differential Revision: D15240953
Pulled By: cpojer
fbshipit-source-id: fd7121d990c5b01533e456bdfa39bebf6245fa80
Summary:
In fabric, the measureLayout method expects 'node ref' instead of 'node handle'.
Node refs are supported by the current production version of RN and for Fabric, no changes should be expected in the current production version of RN
Reviewed By: TheSavior
Differential Revision: D15103116
fbshipit-source-id: cde94f61eaf6aa52ae4bd6f89082d18141d0da28
Summary:
It's easy to accidentally trigger this invariant when adding / moving around a component that relies on a FlatList.
There might be some unexpected behavior when this occurs, i.e. messed up virtualization / viewability logging. But to me, that is a better outcome than crashing the JS context.
Reviewed By: sahrens
Differential Revision: D14975295
fbshipit-source-id: 18015a780a153aae995723b120440be0e55d8e8b
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:
Makes sure `onViewableItemsChanged` fires ASAP when `waitForInterations` is false.
This also works around another deeper bug where updates scheduled with `InteractionManager` aren't firing at all in some cases, and thus instead of just firing late, `onViewableItemsChanged` isn't firing until scroll which is not what we want with `waitForInterations: false`. That bug will require more digging.
Differential Revision: D14984333
fbshipit-source-id: 718b39670307c6bc16268759bdb513682745265d
Summary:
Flow typing can be annoying because the `renderItem` prop for FlatList always has to specifically be of type `React.Element`.
Since really we just want to return something renderable, it should be fine to type this as `React.Node` instead.
I'm not sure if this is valid, but it seems like since we just need to implant the `key` property, we should be able to accomplish this with a `React.Fragment` wrapper instead of needing to call `cloneElement`. Looking for feedback on if this is a sensible fix.
Changelog:
[General][Changed] Updated FlatList's renderItem Flow type from React.Element<any> to React.Node
Reviewed By: sahrens
Differential Revision: D14814805
fbshipit-source-id: ce6793dea5a92619babe048dcfddee0e4519979c
Summary:
It seems (I used git history to confirm) that FlatList/VirtualizedList have ([since the begining](https://github.com/facebook/react-native/blame/c13f5d48cfe3e7c0f6c6d0b745b50a089d6993ef/Libraries/Lists/VirtualizedList.js#L79)) a `disableVirtualization` prop.
SectionList ([since it's begining](https://github.com/facebook/react-native/blame/abe737fe746406533798f9670e8e243cb18d5634/Libraries/Lists/VirtualizedSectionList.js#L98)) have a `enableVirtualization` prop, but since SectionList is VirtualizedSectionList which use VirtualizedList, this prop probably never did something. This fix just rename the prop properly so it can have an effect on the underlying VirtualizedList when you use a SectionList.
Since props are spread it's kind of working already, but the flow annotation are wrong (so it tells you it won't work/ you can't use it) which sucks.
(NB: I am doing this since I was trying to use a SectionList with react-native-web & server side rendering to get the all list, you can laugh).
[General] [Fixed] - VirtualizedSectionList/SectionList: replace enableVirtualization prop annotation by correct underlying disableVirtualisation of VirtualizedList
Pull Request resolved: https://github.com/facebook/react-native/pull/24312
Differential Revision: D14779449
Pulled By: cpojer
fbshipit-source-id: e51e1d639d2bb265b5b286786010d01ffd9d90e0
Summary:
This PR fixes the case where the content a VirtualizedList loads with a contentLength of 0, causing a crash in the `renderDebugOverlay` function. The result of that crash is a red screen when turning on debug on FlatList and other VirtualizedList components as described in #24053.
[LIST] [FIX] - Fix VirtualizedList debug mode crash
Pull Request resolved: https://github.com/facebook/react-native/pull/24058
Differential Revision: D14538317
Pulled By: cpojer
fbshipit-source-id: 7b17bf51c388561c517bab1f775a31200abdc5a9
Summary:
```
let index = params.itemIndex + 1;
```
to
```
let index = Platform.OS === 'ios' ? params.itemIndex : params.itemIndex - 1;
```
to fix an issue on iOS. Note however, how the sign for non iOS changed from `+` to `-` causing a crash on Android when trying to scroll to index 0 as that will be evaluated to -1 instead of 1 and thus be out of bounds.
[Android] [Fixed] - Fixed regression in SectionList caused by #21577 not being able to scroll to top on android
Pull Request resolved: https://github.com/facebook/react-native/pull/24034
Differential Revision: D14520796
Pulled By: cpojer
fbshipit-source-id: bb49619f49752fd3f343ef3b7bf1b86ac48af7f8
Summary:
@public
This bumps Prettier to v1.16.4
Only format source files were updated.
Reviewed By: mjesun
Differential Revision: D14454893
fbshipit-source-id: 72f9872fe764a79dbf0d9fab9bebb1456b039f2f
Summary:
SectionList accesses items outside of the array bounds.
This was discovered when using mobx, which warns you: `[mobx.array] Attempt to read an array index (${index}) that is out of bounds`. This is because `section.data[itemIndex + 1]` goes beyond array length.
This PR adds an array length check and simplifies the code a bit to avoid repetitive `this.props.`
Pull Request resolved: https://github.com/facebook/react-native/pull/23710
Differential Revision: D14298557
Pulled By: cpojer
fbshipit-source-id: fee3422ad5b053d91a097c5842f46e78a149c3d5
Summary:
This diff removes ListView and SwipeableListView from React Native:
* Removes the code and all examples
* Removes the exports on `react-native-implementation` but leaves an error message in dev mode only
* Uses `deprecated-react-native-listview` for `ListView` and `deprecated-react-native-swipeable-listview` for `SwipeableListView`
Both ListView and SwipeableListView are now fully removed from React Native in open source and we will continue to use the deprecated packages internally.
Reviewed By: TheSavior
Differential Revision: D14181708
fbshipit-source-id: 5030c33791f998567de058fee934449c16fa1d54
Summary:
Reverting this change since it broke some initial scroll positions. It seems the proper API to use to limit overscrolling should be overScrollMode='never'
Original commit changeset: 2ec5787218ec
Reviewed By: olegbl
Differential Revision: D13845053
fbshipit-source-id: 673aa529ef5171f26ce138573ee36f31f5d9799e
Summary:
When a list is updated to have fewer items and the user immediately
scrolls, the `ViewabilityHelper` `computeViewableItems` can be invoked
from the scroll and cause a crash.
This side effect *should* be relatively minor; the ViewabilityHelper shouldn't
cause a crash, as it generally would be used for analytics to see what users are viewing. I suggest changing this to a warning instead of a crash. Other react-native developers seem to [also be getting this occasionally](https://github.com/facebook/react-native/issues/20289).
Changelog:
----------
[General] [Fixed] - `Invalid render range` crash changed to warning when viewability helper detects an anomaly in list data.
Pull Request resolved: https://github.com/facebook/react-native/pull/22847
Differential Revision: D13750031
Pulled By: cpojer
fbshipit-source-id: 053d2baad208d1efe5b18b07ab10226032e665b8
Summary: Android scrolling performance is very poor with this disabled. iOS has some KP with this enabled, so disable it for iOS.
Reviewed By: sahrens
Differential Revision: D13363494
fbshipit-source-id: efab77b5db9676dd0521ae4193465d45ac34dda3
Summary:
Add key prop to renderHeader and renderFooter in ListViewMock.
Fix unique key error when using jest snapshots.
It closes#12762
Pull Request resolved: https://github.com/facebook/react-native/pull/14894
Reviewed By: TheSavior
Differential Revision: D13396721
Pulled By: cpojer
fbshipit-source-id: 5bbcb8157e3cd98fe07f2a037e1dbc06ab599c87