React-native: ListView onChangeVisibleRows Limitations

[tsteele2013]

Description

In a ListView, the onChangeVisibleRows function only works for the number of rows equal to initialListSize + pageSize. The visibleRows object returned by this function may also occasionally give bad data because of this limitation.

Reproduction

In a list view with 25+ rows, set initialListSize={10}, pageSize={10}, and onChangeVisibleRows={(visibleRows, changedRows) => console.log(visibleRows)}.

As you scroll past the 20th item, you will see that onChangeVisibleRows stops getting called and visibleRows is no longer logged. Also, when you begin to scroll back toward the top and onChangeVisibleRows starts to be called again, you should see that the ListView incorrectly believes that the 20th row is still visible no matter what.

Example output (20th row is NOT actually visible on the screen) :

{ Yesterday: 
   { '8': true,
     '9': true,
     '10': true,
     '11': true,
     '12': true,
     '20': true 
  } 
}

Workaround

I'm able to fix this issue by setting pageSize={1000} so that all (always <1000 in my use case) rows in the ListView are rendered each loop, but obviously this created blocky animations and isn't an ideal long term solution.

Solution

The onChangeVisibleRows function should be called every time a row is moved on/off the screen, regardless of the values in initialListSize and pageSize.

Additional Information

• React Native version: v0.37
• Platform: iOS
• Operating System: MacOS

[lacker]

Can you provide a sample app that reproduces this problem? rnplay.org is ideal.

[tsteele2013]

@lacker rnplay.org doesn't appear to support logging of any kind, so I'm not sure it'd be helpful. I'll try to put together a sample project this weekend.

[lacker]

OK. As simple as possible is ideal. Thanks!

[formatlos]

I'm experiencing the same issue. In my case it doesn't seem to be related to initialListSize or pageSize but it stops triggering at some point, sometimes it's at row 60, sometimes 293, seems to be totally random. It also just happens in production builds, in dev mode everything seems to be fine.

[tsteele2013]

@formatlos I've also experienced some randomness as well in production builds. Good to know I'm not crazy. The project I have implemented this in contains sensitive data, so it seems it's going to be more tedious than originally thought for me to create a sample project.

Is one still needed? Or is it unnecessary since you're a contributor and you've been able to recreate the problem?

[formatlos]

As I'll not have any time to look into the issues in deep, I'd still recommend creating a sample project. Actually I think it should be rather easy, the problems should occur without any data. I'll also try to put a sample project together ...

[heywarddai]

I encountered this issue as well and seemed to fixed it with the method in the pr above.

[hramos]

Closing as ListView is deprecated in 0.43. Use FlatList.