Summary: VirtualizedList would more gracefully handle out of range cells than VirtualizedList_EXPERIMENTAL, which treats it as an invariant violation. This attempts to fix an issue where recalculation of cells around viewport can include out of range cells.
Reviewed By: rshest
Differential Revision: D39244112
fbshipit-source-id: 20fe6ea552035061d9d00720fcab77b29a785771
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
This forwards props to `__getFrameMetricsApprox()` and `_getFrameMetrics()` . This is called in a variery of places, so we need to pass `FrameMetricProps` through more places, and update public/test usage.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Fixed] - Thread props to __getFrameMetrics()
Reviewed By: genkikondo
Differential Revision: D38293591
fbshipit-source-id: c1499d722b69eb4b5953124ee8b8c3d15e912d93
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
Use passed props in `computeWindowedRenderLimits()`, which is called during a state update.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Fixed] - Thread props to computeWindowedRenderLimits()
Reviewed By: genkikondo
Differential Revision: D38293588
fbshipit-source-id: 1330a003c1354bbd63c0b7b33a013e85e96fdc64
Summary:
# This Change
https://github.com/react-native-community/discussions-and-proposals/pull/335 discussed a set of problems with VirtualizedList and focus. These were seen as severe externally for a11y on desktop. The issues center on users of keyboard and accessibility tools, where users expect to be able to move focus in an uninterrupted loop.
The design and implementation evolved to be a bit more general, and without any API-surface behavior changes. It was implemented and rolled out externally as a series of changes. The remaining changes that were not upstreamed into RN are rolled into https://github.com/facebook/react-native/pull/32646
This diff brings this change into the repo, as a separate copy of VirtualizedList, to measure its impact to guardrail metrics, without yet making it the default implementation. The intention is for this to be temporary, until there is confidence the implementation is correct.
## List Implementation (more on GitHub)
This change makes it possible to synchronously move native focus to arbitrary items in a VirtualizedList. This is implemented by switching component state to a sparse bitset. This was previously implemented and upstreamed as `CellRenderMask`.
A usage of this is added, to keep the last focused item rendered. This allows the focus loop to remain unbroken, when scrolling away, or tab loops which leave/re-enter the list.
VirtualizedList tracks the last focused cell through the capture phase of `onFocus`. It will keep the cell, and a viewport above and below the last focused cell rendered, to allow movement to it without blanking (without using too much memory).
## Experimentation Implementation
A mechanism is added to gate the change via VirtualizedListInjection, mirroring the approach taken for Switch with D27381306 (https://github.com/facebook/react-native/commit/683b825b327e7fa71e87e3d613cb9acd37c24288).
It allows VirtualizedList to delegate to a global override. It has a slight penalty to needing to import both modules, but means code which imports VirtualizedList directly is affected the changes.
Changelog:
[Internal][Added] - Add VirtualizedList_EXPERIMENTAL (CellRenderMask Usage)
Reviewed By: lunaleaps
Differential Revision: D38020408
fbshipit-source-id: ad0aaa6791f3f4455e3068502a2841f3ffb40b41
Summary:
elementsThatOverlapOffsets was quite inefficient as it was doing a linear scan over all items without an early out for each input offset.
The number of items can be large, so we'd want to use binary search here.
Before: O(MN), where M is the # offsets and N is the # items
After: O(MlogN)
As a utility method, elementsThatOverlapOffsets should not be responsible for checking that the offsets are in increasing order
'binary-search' dep added via https://www.internalfb.com/intern/wiki/React_Native/Building_Product_Experiences/Third_Party_Packages_(npm)/
Changelog:
[Internal] - Modify VirtualizeUtils.elementsThatOverlapOffsets to use binary search
Reviewed By: javache
Differential Revision: D36292326
fbshipit-source-id: 5f22eb5533b69e2ebe5c1cb34e4f82605838f0a7
Summary:
During debugging of undesired behavior using VirtualizedList with initialScrollIndex, it was found that zoomScale was sometimes undefined, which resulted in elementsThatOverlapOffsets returning not being able to find the frame at the given offsets.
This does not cause any unexpected behavior when scrolling from the top, as the first item index in VirtualizedList is always calculated to be 0; however, when we set initialScrollIndex, the frame calculations are incorrect, resulting in wasteful re-renders of the VirtualizedList as it renders every frame (row) from the top.
Changelog:
[Internal][Fixed] - Default zoomScale to 1 for computeWindowedRenderLimits and elementsThatOverlapOffsets in order to fix render limit calculation.
Differential Revision: D36294426
fbshipit-source-id: 1e1abec1c95f58a1913bafa2c9680e51e2dc26fa
Summary:
Changelog:
[Internal][Changed] - Remove keyExtractor from defaultProps as part of larger effort to remove defaultProps from VirtualizedList
[General][Changed] - Remove data as a prop for VirtualizedSectionList. In the reactnative.dev docs it mentions that sections is the equivalent for *SectionList: https://reactnative.dev/docs/sectionlist#sections
[General][Changed] - Change export type of VirtualizedSectionList and wrap component updates in act in test.
[Internal] - Remove FlowFixMe from VirtualizedSectionList
Reviewed By: kacieb
Differential Revision: D27271493
fbshipit-source-id: f83bdcce9c71c140c8a8fb6f0ecd9bb520fcb85b
Summary:
Changelog:
[Internal][Changed] -Remove keyExtractor from defaultProps as part of larger effort to remove defaultProps from VirtualizedList
Reviewed By: nadiia
Differential Revision: D26969588
fbshipit-source-id: b00922a339cbe471fcbf560ab4abdd9e48eda1fc
Summary:
Changelog:
[General][Changed] - Change VirtualizeUtils to use ESM and change function signature on `computeWindowedRenderLimits` as part of larger effort to remove defaultProps from VirtualizedList
Reviewed By: nadiia
Differential Revision: D26969586
fbshipit-source-id: cd1961a2088d37543dbc9bca8c4a062cdb426a35
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: This is one more step to remove `fbjs` from `react-native-github`. This changes both the internal and external code to use `invariant` from zertosh instead of the copy in fbjs.
Reviewed By: yungsters
Differential Revision: D13195941
fbshipit-source-id: 73564ca1715110e7da9c7ef56dc57374d61377e0
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
This PR removes the need for having the `providesModule` tags in all the modules in the repository.
It configures Flow, Jest and Metro to get the module names from the filenames (`Libraries/Animated/src/nodes/AnimatedInterpolation.js` => `AnimatedInterpolation`)
* Checked the Flow configuration by running flow on the project root (no errors):
```
yarn flow
```
* Checked the Jest configuration by running the tests with a clean cache:
```
yarn jest --clearCache && yarn test
```
* Checked the Metro configuration by starting the server with a clean cache and requesting some bundles:
```
yarn run start --reset-cache
curl 'localhost:8081/IntegrationTests/AccessibilityManagerTest.bundle?platform=android'
curl 'localhost:8081/Libraries/Alert/Alert.bundle?platform=ios'
```
[INTERNAL] [FEATURE] [All] - Removed providesModule from all modules and configured tools.
Closes https://github.com/facebook/react-native/pull/18995
Reviewed By: mjesun
Differential Revision: D7729509
Pulled By: rubennorte
fbshipit-source-id: 892f760a05ce1fddb088ff0cd2e97e521fb8e825
Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
Summary:
Setting `windowSize = 0` doesn't make sense. Let's make sure we catch this problem in the constructor so that it doesn't cause inexplicable list behavior.
Also fixed an invariant in `VirtualizeUtils` that is meant to prohibit non-monotonically-increasing offset arrays. As written, the invariant condition can never actually be violated.
Reviewed By: sahrens
Differential Revision: D6625302
fbshipit-source-id: b2a983cbe7bb5fbe0aed7c5d59e69a8a00672993
Summary:
These got smashed together with some weird rebase snafu. They are pretty intertwined anyway so the value of
separate commits is minimal (e.g. separate commits would not revert cleanly anyway).
== [lists] better fill rate logging (previously D4907958)
After looking through some production data, I think this will address all the issues we're seeing. Now:
- Header/Footer getting no longer counted as blank.
- Avoid floating point for Scuba.
- Compare actual time of blankness, not just samples.
- Include both "any" vs. "mostly" blank (similar to 1 and 4 frame drops).
- Include events where there is no blankness so we have a baseline.
- Remove events with too few samples
**Test Plan: **
A bunch of scrolling in FlatListExample
T17384966
== [Lists] Update SectionSeparatorItem docs (previously D4909526)
Forgot to update the language here when we modified the behavior with the introduction of separator
highlighting support.
** Test Plan: **
nope.
== [Lists] Add renderSectionFooter prop to SectionList (previously D4923353)
Handy for things like "see more" links and such.
The logic here is to render the footer last, *after* the bottom section separator. This is to preserve
the highlighting behavior of the section separator by keeping it adjacent to the items.
**Test Plan: **
Added to snapshot test and example:
{F66635525}
{F66635526}
== [SectionList] Add a bunch more info for rendering items and separators (previously D4923663)
This extra info can be helpful for rending more complex patterns.
**Test Plan: **
Made snapshot test more comprehensive and inspected the output.
== [Lists] reduce render churn (previously D4924639)
I don't think the velocity based leadFactor is helping and might actually be hurting because
it causes a lot of churn in the items we render.
Instead, this diff introduces fillPreference which biases the window expansion in the direction of scroll,
but doesn't actually affect the final bounds of the window at all, so items that are already rendered are
more likely to stay rendered.
**Test Plan: **
Played around in debug mode and watched the overlay - seems better. Also tests all pass.
T16621861
== [Lists] Add initialScrollIndex prop
Makes it easy to load a VirtualizedList at a location in the middle of the content without
wasting time rendering initial rows that aren't relevant, for example when opening an infinite calendar
view to "today".
**Test Plan: **
With debug overlay, set `initialScrollIndex={52}` prop in `FlatListExample` and
and see it immediately render a full screen of items with item 52 aligned at the top of the screen. Note
no initial items are mounted per debug overlay. Scroll around a bunch and everything else seems to work
as normal.
No SectionList impl since `getItemLayout` isn't easy to use there.
T17091314
Reviewed By: bvaughn
Differential Revision: D4907958
fbshipit-source-id: 8b9f1f542f9b240f1e317f3fd7e31c9376e8670e
Nick Gerleman
Genki Kondo
islandryu
Andres Suarez
Tim Yung
Luna Wei
Jimmy Zhang
George Zahariev
Christoph Nakazawa
Héctor Ramos
Rubén Norte
Sophie Alpert
Semen Zhydenko
Logan Daniels
Christopher Chedeau
Spencer Ahrens
Eric Vicenti