Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45998
The exact `React.Element` type is deprecated and will be removed in a future version of Flow.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D61205640
fbshipit-source-id: a029a3a46c7d8d9f94b0b931b991b2ce461151b2
Summary:
Currently if the virtualized list content is small `onStartReached` won't be called initially when the list is mounted. This is because when the content is small `onEndReached` will be called initially preventing `onStartReached` from being called. In `_maybeCallOnEdgeReached` calling `onEndReached` and `onStartReached` are in the same conditional so they cannot both be triggered at once. To improve the consistency of `onStartReached` we should call both `onEndReached` and `onStartReached` if needed.
## Changelog:
[GENERAL] [FIXED] - Call onStartReached initially when list is small and `onEndReached` is called
Pull Request resolved: https://github.com/facebook/react-native/pull/42902
Test Plan:
I used this code to test in RN Tester (replace content of RNTesterAppShared.js)
```ts
import React, { useState, useEffect } from "react";
import { StyleSheet, FlatList, View, Text, TouchableOpacity } from "react-native";
function App() {
const [data, setData] = useState(generatePosts(4));
const [idCount, setIdCount] = useState(1);
const renderItem = ({ item }) => <Item data={item} />;
const keyExtractor = (item) => item.id.toString();
console.log("-------")
return (
<View style={{ flex: 1, marginVertical: 20 }}>
<FlatList
key={idCount}
data={data}
renderItem={renderItem}
keyExtractor={keyExtractor}
onEndReachedThreshold={0.05}
onEndReached={() => console.log("onEndReached")}
onStartReachedThreshold={0.05}
onStartReached={() => console.log("onStartReached")}
inverted
/>
<TouchableOpacity style={{height: 50, width: '100%', backgroundColor: 'purple'}} onPress={()=>{
setIdCount(state => state + 1)
setData(generatePosts(2))
}}><Text> Press</Text></TouchableOpacity>
</View>
);
}
function Item({ data }) {
return (
<View style={styles.item}>
<Text style={styles.title}>
{data.id} - {data.title}
</Text>
</View>
);
}
const styles = StyleSheet.create({
item: {
backgroundColor: "#f9c2ff",
padding: 20,
marginVertical: 8,
marginHorizontal: 16,
},
title: {
fontSize: 24,
},
});
const generatePosts = (count, start = 0) => {
return Array.from({ length: count }, (_, i) => ({
title: `Title ${start + i + 1}`,
vote: 10,
id: start + i,
}));
};
export default App;
```
Before the change only onEndReached is called, after the change both onStartReached and onEndReached is called.
Reviewed By: sammy-SC
Differential Revision: D53518434
Pulled By: cipolleschi
fbshipit-source-id: bc34e0d4758df6d5833be7290e5a66efaf252ffd
Summary:
The logic to constrain the last spacer size is incorrect in some cases where the spacer is the last spacer, but not the last section in the list.
For more context, the role of spacer constraining is explained in this comment:
```
// Without getItemLayout, we limit our tail spacer to the _highestMeasuredFrameIndex to
// prevent the user for hyperscrolling into un-measured area because otherwise content will
// likely jump around as it renders in above the viewport.
```
For example it is incorrect in the case where we have:
ITEMS
SPACER
ITEMS
In this case the spacer is not actually the tail spacer so the constraining is incorrectly appied.
This causes issues mainly when using `maintainVisibleContentPosition` since it will cause it to scroll to an incorrect position and then cause the view that was supposed to stay visible to be virtualized away.
## Changelog:
[GENERAL] [FIXED] - Fix last spacer constrain logic in VirtualizedList
Pull Request resolved: https://github.com/facebook/react-native/pull/41846
Test Plan:
Tested using https://gist.github.com/janicduplessis/b67d1fafc08ef848378263208ab93d4c in RN tester, before the change content will jump on first click on add items.
Tested using the same example and setting initial posts to 1000, then we can see our content view size is still constrained properly (see scrolling indicator as reference).
Reviewed By: yungsters
Differential Revision: D51964500
Pulled By: NickGerleman
fbshipit-source-id: 4465aa5a36c95466aef6571314973c1e2c9a0f2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41381
Noticed that when scrolling VirtualizedList's CellRenderer was re-rendering due to `onCellFocusCapture` not having a stable identify. Change the interface to CellRenderer to pass in the `cellKey` in the callback to save on creating new callbacks.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D51112928
fbshipit-source-id: 3fcb974d9b5585403895746fbc45f2cf5a9fa6b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41270
`scheduleCellsToRenderUpdate()` is called in response to new measurements, or component changes. It has logic to decide whether to immediately calculate new state, or to defer it until a later batched period.
It will not immediately update state if we don't yet have measurements for cells, but this condition is after another which calculates priority, relying on these measurements. These are garbage if we don't yet have measurements, and trigger an invariant violation in horizontal RTL.
This switches around the conditions, to avoid offset resolution if we don't yet have valid measurements.
I suspect some "hiPri" renders where cells shift are bugged right now when we update state in response to content size change, before we have new corresponding cell layouts.
Changelog:
[General][Fixed] - Bail on hiPri render on missing layout data before checking priority
Reviewed By: yungsters
Differential Revision: D50791506
fbshipit-source-id: 8dbffc37edd2a42f7842c0090d344dcd6f3e3c6d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41113
changelog: [internal]
We must prevent VirtualizedList._onContentSizeChange from being triggered by a conflicting bubbling onContentSizeChange event.
For TextInput, we change the event onContentSizeChange from bubbling to direct (https://github.com/facebook/react-native/commit/744fb4a0d23d15a40cd591e31f6c0f6cb3a7f06b). To make this safer, we need to filter out any `onContentSizeChange` event since we can't control 3rd party components from dispatching onContentSizeChange as bubbling event.
Reviewed By: NickGerleman
Differential Revision: D50451232
fbshipit-source-id: b7a446e4efc9c45024d37f35cb53f2fcbb28799f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39646
We can dramatically simplify this code and remove quirks/hacks, now that we can assume layout events are always fired top down.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D49628669
fbshipit-source-id: 7de5bbc4597eba1c59aaa7672c70e76d2786c7ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39335
In RTL we must have scrollview content length in order to resolve cell metrics. This means that on Paper, where layout events are bottom up, we cannot immediately calculate viewability in response to cell metric changes, as we may not yet have an accurate length of laid out list content.
This change makes us defer calculation of viewability changes in this case via `setTimeout()`, to run in a single batch after the next layout events are fired.
---
We need container dimensions to resolve the right-edge relative child directions. It is tricky to do this at a guaranteed right time with onLayout model on Paper.
When we are laying out children, the first layout on Paper looks like:
1. Child is laid out
2. Container is laid out
However, we will never see container onLayout if a child layout does not change the dimensions of the parent container. This will be the common case of subsequent child layouts, where the spacer size was accurate.
I.e. we may or may not ever see content laid out, but can only rely on having both offsets be up to date if we trigger calculation after the container layout would have happened. This is not an issue on Fabric where layout events are fired top-down, or for the most common cases of VirtualizedList, where we run calculations in idle batches that will happen after layout is set, but ends up causing problems for two scenarios I didn't originally account for:
We may recalculate cells to render immediately instead scheduling a later update if the list thinks blanking is immediate (high priority render). This means we cannot do an immediate update in response to cell layout, but we can in response to events batched after layout events are all dispatched, or in worst case delay in Paper RTL.
We do not batch/schedule viewability calculations in response to cell layout in the same wasy as we do for calculating cells to render, but do need them to trigger recalculation.
The way less hacky, but much more invasive solution, that would simplify a lot of this, would be to include parentWidth and parentHeight in onLayout events for Paper (and Fabric for consistency), so that we don't need to rely on event ordering, or sometimes not firing. I thought this would be too much at first, if we didn't have other use-cases, but am more and more tempted to tear down a lot of what we have here to do that instead, since this is not going to be able to rely on useLayoutEffect or IntersectionObserver in today's VirtualizedList because it will need to support Paper for the forseeable future..
Changelog:
[General][Fixed] - Fix invariant violation when using viewability callbacks with horizontal RTL FlatList on Paper
Reviewed By: yungsters
Differential Revision: D49072963
fbshipit-source-id: accd33e2c50935bb67700d94820f6418f130fe08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39031
`UIScrollView` `contentOffset` is flow-relative, so `x` is relative to the right edge of the screen. This coordinate space disagrees with layout events, `scrollTo` coordinates, and other platforms.
This applies the same logic we use for inverting `scrollTo` coordinates to invert `contentOffset` in scroll events, in both Paper and Fabric. We then remove the iOS specific workaround we have in VirtualizedList.
I did not test `contentInset` as part of this, whose structure has explicit edges like `left` and `right`.
Changelog:
[iOS][Fixed] - Fix inverted `contentOffset` in scroll events in RTL
Reviewed By: rozele
Differential Revision: D48379915
fbshipit-source-id: 8a9cbb01608e79ef3b179a76fbe3997a0cd23845
Summary:
The offset we record should be the one closest to the reference zero-point in the coordinate space. This makes scroller offset reference match the cell reference we keep in D47978631.
Changelog:
[General][Fixed] - Use right edge of ScrollView viewport for `scrollMetrics.offset` in RTL
bypass-github-export-checks
Reviewed By: lenaic
Differential Revision: D48132236
fbshipit-source-id: 3307081e5e859f1b4afbc15a84c5be1b33915206
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38737
This fixes up behavior on Android so that `scrollToIndex` aligns the right edge of the cell of the given index to the right edge of the scrollview viewport. We do not incorporate RTL on iOS which inverts x/y coordinates from scroller (but not layout).
Changelog:
[General][Fixed] - Right align scrollToIndex in RTL
Reviewed By: lenaic
Differential Revision: D47978637
fbshipit-source-id: 7786b5d97efaced318018409e2c7577a3d8f7402
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38736
`scrollToIndex` relies on cached layout information, so we should cache the results from `onContentSizeChange` before attempting the scroll. Otherwise we will fail to scroll in RTL.
Changelog:
[General][Fixed] Cache ScrollView content length before calling `scrollToIndex`
Reviewed By: lenaic
Differential Revision: D47978635
fbshipit-source-id: 27f2a4702650e8a73e8812128821ca03f36216dd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38648https://github.com/facebook/react-native/pull/38475 made this code no longer no-op on Android, which caused regressions documented in https://github.com/facebook/react-native/issues/38470#issuecomment-1639620459 due to VirtualizedList having more out-of-date information.
We are already coalescing scroll events on both Android and iOS, which will ensure we are not flooded with events. VirtualizedList also already inserts an artificial 50ms delay to new renders by default when high priority work is not happening (see `updateCellsBatchingPeriod`). This limits the heavy work done by VirtualizedList (no new renders or expensive math on scroll events), while letting the list still have the most recent events.
We can eventually remove this once VirtualizedList is able to use OffScreen universally.
Changelog:
[General][Changed] - Remove default 50ms Scroll Event Throttling in VirtualizedList
Reviewed By: ryancat
Differential Revision: D47823772
fbshipit-source-id: 55d22a1074235ccc1b2cf167f6b1758640c79edb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38655https://github.com/facebook/react-native/pull/35993 added logic in VirtualizedList to support `maintainVisibleContentPosition`. This logic makes sure that a previously visible cell being used as an anchor remains rendered after new content is added.
The strategy here is to calculate the difference in previous and new positions of the anchor, and move the render window to its new location during item change. `minIndexForVisible` is used as this anchor.
When an item change moves the anchor to a position below `minIndexForVisible`, shifting the render window may result in a window which starts before zero. This fixes up `_constrainToItemCount()` to handle this.
Changelog:
[General][Fixed] - Fix invariant violation when `maintainVisibleContentPosition` adjustment moves window before list start
Reviewed By: yungsters
Differential Revision: D47846165
fbshipit-source-id: 8a36f66fdad321acb255745dad85618d28c54dba
Summary:
This PR is a result of this PR, which got merged but then reverted:
- https://github.com/facebook/react-native/pull/37913
We are trying to implement a workaround for https://github.com/facebook/react-native/issues/35350, so react-native users on android API 33+ can use `<FlatList inverted={true} />` without running into ANRs.
As explained in the issue, starting from android API 33 there are severe performance issues when using scaleY: -1 on a view, and its child view, which is what we are doing when inverting the ScrollView component (e.g. in FlatList).
This PR adds a workaround. The workaround is to also scale on the X-Axis which causes a different transform matrix to be created, that doesn't cause the ANR (see the issue for details).
However, when doing that the vertical scroll bar will be on the wrong side, thus we switch the position in the native code once we detect that the list is inverted, using the newly added `isInvertedVirtualizedList` prop.
This is a follow up PR to:
- https://github.com/facebook/react-native/pull/38071⚠️ **Note:** [38071](https://github.com/facebook/react-native/pull/38071) needs to be merged and shipped first! Only then we can merge this PR.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [FIXED] - ANR when having an inverted FlatList on android API 33+
Pull Request resolved: https://github.com/facebook/react-native/pull/38073
Test Plan:
- Check the RN tester app and see that scrollview is still working as expected
- Add the `internalAndroidApplyInvertedFix` prop as test to a scrollview and see how the scrollbar will change position.
Reviewed By: cortinico
Differential Revision: D47848063
Pulled By: NickGerleman
fbshipit-source-id: 4a6948a8b89f0b39f01b7a2d44dba740c53fabb3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38529
VirtualizedList internally represents metrics along the scrolling axis using `offset` (x, y), and `length` (width, height). This one dimensional representation allows the list to be generic to being horizontal or vertical.
Right now offset conversion directly takes the `x` or `y` axis value, but this is not correct when we are using a horizontal FlatList in RTL.
This change converts most VirtualizedList code handling `offset,length` coordinates consistently flow from start to end, including in horizontal RTL and in inverted FlatList.
This is paired with a fix to Android native code in D47627115. With these together, basic Horizontal FlatList scenarios should work correctly when laid out in RTL.
Changelog:
[General][Fixed] - Fix virtualization logic with horizontal RTL lists
Reviewed By: vincentriemer
Differential Revision: D46586420
fbshipit-source-id: 79594e197d21871bb493399999e91fc0d6c7b050
Summary:
As explained in this issue:
- https://github.com/facebook/react-native/issues/35350
starting from android API 33 there are severe performance issues when using `scaleY: -1` on a view, and its child view, which is what we are doing when inverting the `ScrollView` component (e.g. in `FlatList`).
This PR adds a workaround. The workaround is to also scale on the X-Axis which causes a different transform matrix to be created, that doesn't cause the ANR (see the issue for details).
However, when doing that the vertical scroll bar will be on the wrong side, thus we switch the position in the native code once we detect that the list is inverted.
The goal of this PR is that react-native users can just use `<FlatList inverted={true} />` without running into any ANRs or the need to apply manual hot fixes 😄
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID] [FIXED] - ANR when having an inverted `FlatList` on android API 33+
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [FIXED] - ANR when having an inverted `FlatList` on android API 33+
Pull Request resolved: https://github.com/facebook/react-native/pull/37913
Test Plan:
- The change is minimal, and only affects android.
- Run the RNTesterApp for android and confirm that in the flatlist example the inverted list is still working as expected.
Reviewed By: rozele
Differential Revision: D46871197
Pulled By: NickGerleman
fbshipit-source-id: 872a2ce5313f16998f0e4d2804d61e4d8dca7bfd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37777
This extracts the state and logic VirtualizedList uses to query information related to cell metrics. We will need to modify this (and other places) when fixing up RTL support for horizontal FlatList.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D46427052
fbshipit-source-id: 0a23f6c726447de0f20c583b4d507003efd6a754
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37778
These functions describe how to get the metrics of a specific cell. "Frame" here seems non-descriptive and redundant to the "Metrics" part. Renaming this before a larger refactor.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D46427058
fbshipit-source-id: e9ad9cf15e1adfd07604eb11526de0ed8cf99000
Summary:
`maintainVisibleContentPosition` is broken when using virtualization and the new content pushes visible content outside its "window". This can be reproduced in the example from this diff. When using a large page size it will always push visible content outside of the list "window" which will cause currently visible views to be unmounted so the implementation of `maintainVisibleContentPosition` can't adjust the content inset since the visible views no longer exist.
The first illustration shows the working case, when the new content doesn't push visible content outside the window. The red box represents the window, all views outside the box are not mounted, which means the native implementation of `maintainVisibleContentPosition` has no way to know it exists. In that case the first visible view is https://github.com/facebook/react-native/issues/2, after new content is added https://github.com/facebook/react-native/issues/2 is still inside the window so there's not problem adjusting content offset to maintain position. As you can see Step 1 and 3 result in the same position for all initial views.
The second illustation shows the broken case, when new content is added and pushes the first visible view outside the window. As you can see in step 2 the view https://github.com/facebook/react-native/issues/2 is no longer rendered so there's no way to maintain its position.
#### Illustration 1
#### Illustration 2
To fix `maintainVisibleContentPosition` when using `VirtualizedList` we need to make sure the visible items stay rendered when new items are added at the start of the list.
In order to do that we need to do the following:
- Detect new items that will cause content to be adjusted
- Add cells to render mask so that previously visible cells stay rendered
- Ignore certain updates while scroll metrics are invalid
### Detect new items that will cause content to be adjusted
The goal here is to know that scroll position will be updated natively by the `maintainVisibleContentPosition` implementation. The problem is that the native code uses layout heuristics which are not easily available to JS to do so. In order to approximate the native heuristic we can assume that if new items are added at the start of the list, it will cause `maintainVisibleContentPosition` to be triggered. This simplifies JS logic a lot as we don't have to track visible items. In the worst case if for some reason our JS heuristic is wrong, it will cause extra cells to be rendered until the next scroll event, or content position will not be maintained (what happens all the time currently). I think this is a good compromise between complexity and accuracy.
We need to find how many items have been added before the first one. To do that we save the key of the first item in state `firstItemKey`. When data changes we can find the index of `firstItemKey` in the new data and that will be the amount we need to adjust the window state by.
Note that this means that keys need to be stable, and using index won't work.
### Add cells to render mask so that previously visible cells stay rendered
Once we have the adjusted number we can save this in a new state value `maintainVisibleContentPositionAdjustment` and add the adjusted cells to the render mask.
This state is then cleared when we receive updated scroll metrics, once the native implementation is done adding the new items and adjusting the content offset.
This value is also only set when `maintainVisibleContentPosition` is set so this makes sure this maintains the currently behavior when that prop is not set.
### Ignore certain updates while scroll metrics are invalid
While the `maintainVisibleContentPositionAdjustment` state is set we know that the current scroll metrics are invalid since they will be updated in the native `ScrollView` implementation. In that case we want to prevent certain code from running.
One example is `onStartReached` that will be called incorrectly while we are waiting for updated scroll metrics.
## Changelog
[General] [Fixed] - Fix VirtualizedList with maintainVisibleContentPosition
Pull Request resolved: https://github.com/facebook/react-native/pull/35993
Test Plan:
Added bidirectional paging to RN tester FlatList example. Note that for this to work RN tester need to be run using old architecture on iOS, to use new architecture it requires https://github.com/facebook/react-native/pull/35319
Using debug mode we can see that virtualization is still working properly, and content position is being maintained.
https://user-images.githubusercontent.com/2677334/163294404-e2eeae5b-e079-4dba-8664-ad280c171ae6.mov
Reviewed By: yungsters
Differential Revision: D45294060
Pulled By: NickGerleman
fbshipit-source-id: 8e5228318886aa75da6ae397f74d1801d40295e8
Summary:
Hey,
`adjustCellsAroundViewport` function was checking if `props.initialScrollIndex` is truthy and -1 was returning true. This caused bugs with rendering for tvOS: https://github.com/react-native-tvos/react-native-tvos/pull/485 There are warnings in the code about `initalScrollIndex` being smaller than 0 but this if statement would still allow that.
## Changelog:
[General] [Fixed] - Make sure initialScrollToIndex is bigger than 0 when adjusting cells
Pull Request resolved: https://github.com/facebook/react-native/pull/36844
Test Plan: Pass -1 as initialScrollToIndex. Check that this code is executed.
Reviewed By: cipolleschi
Differential Revision: D44856266
Pulled By: NickGerleman
fbshipit-source-id: 781a1c0efeae93f00766eede4a42559dcd066d7d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36541
We only know where the last focused cell lives after it is rendered. Apart from dead refs handled in D43835135, this means items added or removed before the focused cell will lead to a stale last index for the next state update.
We don't have a good way to correlate cells after data change. This effects the implementation for [`maintainVisibleContentPosition`](https://github.com/facebook/react-native/pull/35993) as well, but needs some thought on the right way to handle it. For now, we bail when we don't know where the last focused cell lives.
Changelog:
[General][Fixed] - Bail on realizing region around last focused cell if we don't know where it is
Reviewed By: yungsters
Differential Revision: D44221162
fbshipit-source-id: 8fc7e726fe13c62b98870600563857bb89290280
Summary:
CellRendererComponent can be given a more useful description, and more constrained type, to ensure it is used more correctly.
Changelog:
[General][Fixed] - Fix types + documentation for CellRendererComponent
Reviewed By: yungsters
Differential Revision: D43925572
fbshipit-source-id: 26aae6a2df989993c97709ffbf1544df7cbae036
Summary:
The contract here is that `initialScrollIndex` only applies once, right after the components mount. There is other code still relying on live `initialScrollIndex`, which is allowed to become stale. E.g. after removing items.
I looked at a larger change of only ever using `initialScrollIndex` in the start, so we have a consistent value. We also ideally should fix up the logic relying on it for the scroll to top optimization.
That series of changes is more involved than I want to spend time on, so this just avoids the check once we have triggered a scroll, where the rest of the code is UT'd to be permissive if it drifts out of allowed.
Changelog:
[General][Fixed] - Allow out-of-range initialScrollIndex after first scroll
Reviewed By: yungsters
Differential Revision: D43926656
fbshipit-source-id: bd09bd9a9aa6b3b5f07209dac8652c9374a762c4
Summary:
VirtualizedList today will keep refs to cells around, long after they have been unmounted. This leaks memory, and is not needed.
Changelog:
[General][Fixed] - Delete refs to unmounted CellRenderers
Reviewed By: yungsters
Differential Revision: D43835135
fbshipit-source-id: 2104cae977a4e2e9e1a2738e1523ac1796293b4f
Summary:
VirtualizedList refactoring moved [a call of `_updateViewableItems`](https://www.internalfb.com/code/fbsource/[a9d4ad3cf149][history][blame]/xplat/js/react-native-github/Libraries/Lists/VirtualizedList.js?lines=1431-1447) to the inside of a state update.
This call may trigger an `onViewableItemsChanged`, which is normally not an issue (minus changing timing), but creates problems if the users callback then calls imperative methods on the VirtualizedList, since the batched state update may be in the process of changing the props/state the imperative method is reading. See https://github.com/facebook/react-native/issues/36329 for what I suspect is an example of this.
This moves the `_updateViewableItems` call to before the state update, like the previous version of VirtualizedList.
Changelog:
[General][Fixed] - Avoid VirtualizedList viewability updates during state updates
Reviewed By: javache
Differential Revision: D43665606
fbshipit-source-id: 9398273c5209e371e69aafb02bac173c69874273
Summary:
Fix typo in the initialNumToRenderOrDefault description's comment : function's parameter should be this.props.initialNumToRender instead of this.props.initialNumToRenderOrDefault
## Changelog
[GENERAL] [FIXED] - Fixed typo in the initialNumToRenderOrDefault description's comment
Pull Request resolved: https://github.com/facebook/react-native/pull/36110
Test Plan: Typo in a comment - no testing required
Reviewed By: christophpurrer
Differential Revision: D43160548
Pulled By: cortinico
fbshipit-source-id: 0555c7752102f431fb327b920434faaf4de4ff81
Summary:
State updates can be batched together idependent of `this.state`, so we should do any calculation deriving state from state within a `setState()` callback. This fixes a bug where we were relying on potentially stale state, a RenderMask derived from `this.state` instead of the `state` callback parameter, when triggering updates from focus.
Note that this is not exercised on Android/iOS, but it on desktop/web. I noticed this a while back while making another change, but that change got abandoned, so this is the independent fix.
Changelog:
[General][Fixed] - Calculate VirtualizedList render mask for focused cell during batched state updates
Reviewed By: javache
Differential Revision: D43073415
fbshipit-source-id: dee4197ec925a6d8d427b63fb063aa4e3b58c595
Summary:
This change reverts D41745930 (https://github.com/facebook/react-native/commit/2e3dbe9c2fbff52448e2d5a7c1e4c96b1016cf25) as part of a stack to splice back source history which was lost (Git registered the file moves as additions).
It is expected this diff will individually fail. The entire stack should be applied at once.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D43068113
fbshipit-source-id: c8398629fe5dcc1ca4bf02f550adc00c78a8487a
