Summary:
Makes compute call async from willReceiveProps and fixes crashes with proper bounds in render
function instead. This means that fast prop updates won't force rapid and synchronous row increments during
initial render.
Check `rowData` and `rowKey` explicitly so clients don't have to worry about preserving === rowData containers
around Relay data to prevent re-renders.
Also moves layout jump warning behind DEBUG since it's not a common issue any more.
Reviewed By: devknoll
Differential Revision: D3357710
fbshipit-source-id: ee2e5be04261d5722abd07a063b345960b0c5cbe
Summary:
- Replace some fixes that were accidentally lost in local rebase that prevent jumpiness when incremental is disabled.
- Require each row to have a key specified by the caller to prevent jumping because of accidental duplicates or unneeded/problematic row re-rendering because of legit re-ordering.
Reviewed By: steveluscher
Differential Revision: D3322006
fbshipit-source-id: 0019aab07cb1fe2b148a14b5818de53aa373eb50
Summary:
Incremental rendering is a tradeoff between throughput and responsiveness because it yields. When we have plenty of
buffer (say 50% of the target), we render incrementally to keep the app responsive. If we are dangerously low on buffer
(say below 25%) we always disable incremental to try to catch up as fast as possible. In between, we only disable
incremental while actively scrolling since it's unlikely the user will try to press a button while scrolling.
This also optimizes some things then incremental is switching back and forth.
I played around with making the render window itself adaptive, but it seems pretty futile to predict - once the user
decides to scroll quickly in some direction, it's pretty much too late and increasing the render window size won't help
because we're already limited by the render throughput at that point.
Reviewed By: ericvicenti
Differential Revision: D3250916
fbshipit-source-id: 930d418522a3bf3e20083e60f6eb6f891497a2b8
Summary:
Reduce re-renders by only looking at `props.data` that we're actually going to render and tracking if `this._rowFrames`
is dirty.
Differential Revision: D3195163
fb-gh-sync-id: 1e17ab410a312a37d4a93b84ea51ca32c3ede839
fbshipit-source-id: 1e17ab410a312a37d4a93b84ea51ca32c3ede839
Summary:`WindowedListView` is designed for memory efficient scrolling of
huge/infinite lists of variable height rows. It works by measuring row heights
with `onLayout` and caching the results, then unmounting rows that scroll
offscreen, replacing them with an equivalent offset in the spacer view. Care is
taken to render a constant number of rows, and to only render one new row per
tick to improve framerate and app responsiveness. WLV is also compatible with
<Incremental> used within the rows themselves.
`WindowedListView` is not a drop-in replacement for `ListView` - it doesn't
support many of the features of `ListView`, such as section headers, only
accepts a simple array of data instead of a datasource, and doesn't support
horizontal scrolling. This may change in the future.
This is still experimental - we haven't deployed this for any production apps
yet.
Differential Revision: D2791402
fb-gh-sync-id: 5f104e0903f6ba586d2d651bdf82863a231279d8
fbshipit-source-id: 5f104e0903f6ba586d2d651bdf82863a231279d8
Ian Childs
Jeff Morrison
Gerald Monaco
James
Spencer Ahrens
Basil Hosmer
glevi@fb.com
Steven Luscher