Summary:
This diff regenerates all Jest inline snapshots (`expect().toMatchInlineSnapshot()`) now that we use Jest 24.9.0 which fixes a longstanding [formatting instability bug](https://github.com/facebook/jest/issues/8424).
This is strictly a formatting change.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D19684238
fbshipit-source-id: 77c1e5fe9d2dfef85dffdcc00056fb439d7d7f84
Summary:
## Context
When a `VirtualizedList` contains a cell which itself contains more than one `VirtualizedList` of the same orientation as the parent list, we log an error if sibling lists in a cell don't have unique `listKey`s (e.g. when the `listKey` prop isn't explicitly set). In release builds, this error does not have a component stack - nor a useful call stack - so it can be hard to track down the true source of the error in complex applications.
## This diff
Here, in addition to the generic error message, we also print the `listKey`, `cellKey` and orientation of each `VirtualizedList` in the hierarchy, from the child list upwards. This is done without significant overhead, by reusing the already-in-place context that `VirtualizedList`s use to manage nesting.
The assumption is that common strategies for deriving `listKey`s and `cellKey`s will make it possible to identify at least some lists in the hierarchy in common cases, and therefore help narrow down the search space even when component stacks are not available.
## Example
(See code in unit test)
```
A VirtualizedList contains a cell which itself contains more than one VirtualizedList of the same orientation as the parent list. You must pass a unique listKey prop to each sibling list.
VirtualizedList trace:
Child (horizontal):
listKey: level2
cellKey: cell0
Parent (horizontal):
listKey: level1
cellKey: cell0
Parent (vertical):
listKey: level0
cellKey: rootList
```
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D19600366
fbshipit-source-id: 73f29507ec58a6a3f9b3f6b174a32b21dcd237a1
Summary:
Fixes https://github.com/facebook/react-native/issues/16067
The issue is due to a race between `onLayout` and `onContentSizeChange`, which in general should be fine because there is no expectation of ordering between the two, and only causes issues with certain configurations.
The bug can be triggered if `initialNumToRender` is smaller than needed to fill past the `onEndReachedThreshold` (say the default, 10, is only 580px tall, but it takes 15 to reach the threshold). This will cause an incrementally render of more items to try and fill the viewport. The problem is that if the `onLayout` comes back before the first `onContentSizeChange`, it will first do the state increment to render 20 items and then the stale `onContentSizeChange` callback from 10 items will fire and we'll think that the content size for 20 items is 580px when in fact it's 1160px (which is past the threshold). If those 20 items are also all of our available data, then we'll call `onEndReached` because we think we've rendered everything and are still within the `onEndReachedThreshold`.
The fundamental problem here is the system getting confused when a stale async `onContentSizeChange` comes in after increasing `state.last`. I wish there was a concrete timeframe, but Fabric will give us more flexibility to do things synchronously so hopefully we can avoid class of issues once that roles out.
The fix here simply adds a check to make sure `contentLength` has been set before adjusting the render window so it's not possible to increase the window size before the initial `onContentSizeChange` callback fires.
For completeness, there are a few user-code workarounds to avoid this issue entirely:
1) Provide the `getItemLayout` prop so the list doesn't have to rely on async layout data (you should do this whenever possible anyway for better perf). e.g. for the original snack example, you can just add `getItemLayout={(d, index) => ({length: 58, offset: 58 * index, index})}` since all the rows are height 58 and the issue will no longer repro. Note this is fragile and must be kept in sync with UI changes, a11y font scaling, etc - a more robust approach could be to render a single representative row offscreen and measure it with `onLayout` then use that value.
2) If `getItemLayout` is not feasible to compute for your UI, increase `initialNumToRender` to cover the `onEndReachedThreshold`.
3) And/or add your own logic to protect against extra calls to `onEndReached` as others have suggested.
Changelog:
[General][Fixed] - Fix sporadic issue with onEndReached called on load when not needed
# Test Plan
Adds a new jest test that fails without this fix and succeeds with it.
Reviewed By: TheSavior
Differential Revision: D18966721
fbshipit-source-id: de05d9f072e24a2faf351e7f5d60578a31def996
Summary:
Add a method to get the underlying host component of `FlatList`. Fix flow types in `FlatList` and `VirtualizedList`. Add test cases to test the behavior of the new function in all cases.
Changelog: [General] [Added] - Add getNativeScrollRef method to FlatList component
Reviewed By: TheSavior
Differential Revision: D18302202
fbshipit-source-id: 7005a2bc1dab207434be3f1f4d8fde0b11b3bb4d
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:
Generating this diff was difficult. We _will_ fix the issues with jscodeshift, but i don't want to block the syntax change on that.
To get this diff, I first codemodded all of xplat to use exact-by-default. Then i turned on implicit-inexact-object:error enforcement to get a list of errors showing places that violated the lint. With that, I used this to generate a list of `sed` commands to add `...`:
```
flow --json | jq '.errors | .[] | .message | .[] | .loc | {source, "line": .end."line", "column": .end."column"} | "\(.column),\(.line),\(.source)"' | sort -n -r | sed 's/"//g' | while read -r line; do echo $line; awk -F',' "{ print \"sed -i '\"\$2\"s/./...&/\"\$1\"' \" \$3 }"; done
```
Then I ran prettier, reverted generated files, and manually fixed up suppressions that got messed up.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D18516431
fbshipit-source-id: 6cf940dce411fb179e7ebaff764bd5113a07989f
Summary:
still some generated files in www that need to land before we can release 0.111 here.
drop-conflicts
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: dsainati1
Differential Revision: D18278838
fbshipit-source-id: b20c3fefb3aab7c5fb614b33d846c7548184f49a
Summary:
Cleans up all the Jest tests to minimize spurious console output.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D18289690
fbshipit-source-id: cdcecca879b3b85d3dccf9e0ab617ea7dc1e0777
Summary: These types are more accurate
Reviewed By: lunaleaps
Differential Revision: D17862010
fbshipit-source-id: 84dfcade35c21b7be49db46ae021819dda020c98
Summary:
These components had props that were poorly typed and let many things through. This diff tightens that all up.
The main difference in this diff is using `{...BaseProps, ...LocalProps }` instead of `BaseProps & LocalProps`.
The majority of the changes in this diff is reducing duplicated prop definitions. For example, FlatList defines a bunch of props that VirtualizedList also defines. Since FlatList extends those props, using spread now means that FlatList can't duplicate those props. So I've moved the definitions to the correct base file and deleted the duplicates.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D17824459
fbshipit-source-id: 089ac4c58c3c9f70a9f28e517f2e9ecd8aab1a50
Summary:
Data doesn't have to be an array. data and getItemCount can take any arbitrarty data, as long as they expect the same thing. This should probably be parameterized with a generic but that is an improvement for another day.
It is worth noting the comment explanation for the defintion of `data` and `getItem` in VirtualizedList: https://fburl.com/u7ldzaa8
```
/**
* The default accessor functions assume this is an Array<{key: string} | {id: string}> but you can override
* getItem, getItemCount, and keyExtractor to handle any type of index-based data.
*/
data?: any,
/**
* A generic accessor for extracting an item from any sort of data blob.
*/
getItem: (data: any, index: number) => ?Item,
/**
* Determines how many items are in the data blob.
*/
getItemCount: (data: any) => number,
```
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D17863130
fbshipit-source-id: 40a1d57e3b4dd1e38c84d5907fe88f6b665287ae
Summary:
This is a tighter type that matches the actual prop as defined on line 100
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D17863133
fbshipit-source-id: 97f966ff13aa2ce36ef936a9a154fdd137191c6b
Summary: This change surprisingly fixes a Flow error because these types weren't compatible with the prop types these were passed into that had `info: `. Flow passes now though!
Reviewed By: lunaleaps
Differential Revision: D17863131
fbshipit-source-id: 094f1d97e96686d16bb69732b8a4b319492b5780
Summary: These comments existed for other components that had these props. Putting them here as this is the proper base of those other components. Also adding `ItemSeparatorComponent` as it is used in this component.
Reviewed By: lunaleaps
Differential Revision: D17860495
fbshipit-source-id: b7b60058d37e90699b28419af27d488bd46d3ebd
Summary:
`?React.Element<any>` allows passing in `undefined`, an invalid value to render into a React component. Changing these types to be `null | React.Element<any>`.
The issues that this caught were fixed in a previous diff.
Reviewed By: lunaleaps
Differential Revision: D17859220
fbshipit-source-id: 71438cb357b44bca0bf3437aea99ece99a616f7d
Summary:
Moving this to the class lets the first argument be typed as `Props<SectionT>` instead of `Props<SectionBase<any>>`. This is consistent with the structure of FlatList
Changelog:
[Internal]
Reviewed By: zackargyle
Differential Revision: D17841258
fbshipit-source-id: 3e0e6c2f6b21cbce0e662647cb43a012e062c4bc
Summary:
These props are unusupported by the component they were being passed to.
Changelog:
[Internal]
Reviewed By: zackargyle
Differential Revision: D17839765
fbshipit-source-id: 13c80a07da2026b61070ffc93f26194b979ee8fc
Summary:
Fixing up some of the FlowFixMes in VirtualizedList
Changelog:
[Internal]
Reviewed By: zackargyle
Differential Revision: D17839611
fbshipit-source-id: c763a799efca63fd7110cfaed87afde80995b8aa
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:
I know StyleSheet.create doesn’t do anything special on react-native yet but it does on react-native-web and possibly other targets.
This small change is mainly so react-native-web don’t need to keep making this change on their code base when updating the rn version.
## Changelog
[Internal] [Changed] - Move inline static styles at VirtualizedList to StyleSheet.create
Pull Request resolved: https://github.com/facebook/react-native/pull/25501
Test Plan:
It’s basically the same code, just moved.
Also it’s the same change that it’s on react-native-web project: 45f94eb43d/packages/react-native-web/src/vendor/react-native/VirtualizedList/index.js (L1650-L1654)
Differential Revision: D16130700
Pulled By: cpojer
fbshipit-source-id: 20639e2e1a795ff4819c16af15569bf12759a62c
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
Moti Zilberman
Spencer Ahrens
Kacie Bawiec
George Zahariev
Jordan Brown
Tim Yung
david
Panagiotis Vekris
Andres Suarez
Eli White
Mike Vitousek
André Krüger
ifsnow
Vojtech Novak
Logan Daniels
Min ho Kim
Abhishek Ghosh
Bruno Lemos
Sam Goldman
Alan Kenyon
James Ide
Danilo Bürger
David Vacca
