ListItem button onPress slow performance

[obykoo]

I am having performance issue with List and onPress. onPress is delayed too much. I do not know if there is problem on iOS , but there is on Android.

[obykoo]

Interesting => this issue go away if I use ListView from React instead of List from NativeBase

NativeBase is using ListView internally in List , but I wonder how is it detecting change in row?
When I fetch data from external API (therefore I do not have all data when first time rendering) and this API has pagination enabled so I can fetch only 20 items at once.

I have to update state more then once when user is scrolling down. So I do new fetch request in "onEndReached" and update state with fetched data like this:

const newState=update(this.state,{
       data: {$push: newData},
 });
this.setState(newState);

Therefore whole array of objects will not be same as old array in state , if you compare objects with "=="

[obykoo]

Ok I found out why this is happening.
If you wrap <List> in <Content></Content>, then onEndReached in List will keep firing to infinity......

[srhise]

Can you elaborate by what you mean wrap in ? Does that mean one should remove the container altogether?

[sankhadeeproy007]

Do not use List inside Content

[srhise]

So, one of the reasons to use native base is the nice setup of

where content scrolls and header and footer are pinned to the top and bottom, respectively.. When I remove from wrapping a list that breaks that layout. How should one address that pattern using a list, without using the wrapper?

[maotora]

@srhise did you solve this without using .. ?

I'm facing a similar situation and would like to get some feedback on possible solutions before I open another issue.

[SupriyaKalghatgi]

@cyclops24 Solution provided in above comment dd'nt work?

[mnlbox]

@SupriyaKalghatgi I also find this: facebook/react-native#11809
Maybe it's related to React-Native version. Now NativeBase is using version 0.43.0 but it seems performance issue for list fixed in React-Native version 0.44.0.

[shivrajkumar]

@mnlbox Check http://docs.nativebase.io/docs/Compatibility.html
And also It is not recommended to use Content inside List.

[srhise]

Wait, is it list inside content or content inside list??

Can you explain why that is not recommended, ie. what is the impact?

[mnlbox]

@srhise I think you right.
This issues is about List inside Content.

/CC: @shivrajkumar

[mnlbox]

Guys I have same issue. Please help me to fix this issue. 😢

/CC: @SupriyaKalghatgi , @obykoo

[SupriyaKalghatgi]

NativeBase List will be deprecated, very soon this will be documented
So please use React Native's FlatList in place of it
You can use ListItem for the necessary styling
#759

[grzjos]

@SupriyaKalghatgi Any update on NativeBase List? Will it be replaced by something else or should we stick to FlatList? Thanks!

[1c7]

getting same problem, Button(from NativeBase) in FlatList(from ReactNative) sometime could take 1 to 2 second to respond to onPress
still trying to solve the problem

using React Native 0.52, and develop for Android.

[SupriyaKalghatgi]

@grzjos Go on with FlatList

[Laurensdc]

@SupriyaKalghatgi Didn't help performance for me. It's like the TouchableOpacity blocks screen rendering.

[1c7]

update: I think the problem is FlatList from React Native, not the Button by NativeBase
I replace FlatList with LargeList: https://github.com/bolan9999/react-native-largelist
is work for me, performance get a lot better,

no idea why a third party lib have better performance then FlatList, but it work for me.

btw, I open a issue on official React Native: facebook/react-native#17801
(with demo app, video, detail)
the image in FlatList take up a lot memory, I think that also affect the button response time.

[SupriyaKalghatgi]

@Laurensdc Are you using FlatList or NativeBase List?

[Laurensdc]

@SupriyaKalghatgi I used both and had the same problems. I did keep the component from NativeBase in both scenarios, but I tried wrapping it in FlatList as suggested. This did not help performance unfortunately.

What was interesting is that the actual dispatch of the onPress() comes late. It's like the screen goes into 'pressed' state for a whole second, and only then starts to dispatch the function. The Redux actions for example are only dispatched after that second of delay.