discussions-and-proposals
discussions-and-proposals copied to clipboard
react-native-community
Keyboard-friendly List Virtualization Behavior
VirtualizedList virtualizes away items based on proximity to the lists viewport, without consideration for other inputs such as focus or selection. This strategy limits the ability to correctly implement some common keyboard interactions. This especially impacts desktop platforms (react-native-web, react-native-windows, react-native-macos), but also impacts the tablet with keyboard form-factor on iPadOS/Android.
This proposal outlines these issues, proposing a set of behavior changes and new APIs to address them. It does not address concrete implementation.
This has some intersection with existing functionality, where users can mark stickyIndices for sticky headers which are kept realized. This solely keeps sticky headers realized though, without additional cells around them.
Pushed out a new commit with a few updates:
- Focus tracking via capture phase
- Smaller realization windows
- Focused -> "most recent focused"
- Talk about home intersection with initial render
- Talk about batch rendering behavior
Perhaps somewhat related, I was considering if it might be possible to reduce the number of onLayout events emitted made by items in a FlatList, especially in inverted scenarios where content is refreshed from the top.
From what I could tell, there are at least two uses for onLayout events that aren't in the fixed start/end realization windows. One is for calculating the height of the spacers and the other is for implementing scrollToIndex.
If the native platform offered something to scroll a given component into view, e.g., BringIntoView on XAML or scrollIntoView on Web, we would only need to capture the size metrics of the virtualization candidates, which are significantly less likely to change (but we'd need to add some onSizeChanged or similar event to complement onLayout that could fire less frequently).
In order for something like native scrollToIndex to work, we'd need the ability to realize a window around that view prior to invoking a command, so I'm curious if what you have proposed here would be compatible with this theoretical optimization 😀
PRs for internal refactoring of VirtualizedList state representation are now out. This should let us start realizing discontiguous regions.