React-native: Dynamic sticky headers crash natively (Android only)

Created on 5 Jun 2019  路  26Comments  路  Source: facebook/react-native

The FlatList crash natively when updating the stickyHeaderIndices prop.
The purpose of my component is to fetch items, and display them inside a flatlist. Some of the loaded items need to be sticky. It's possible to know which ones only once they are loaded.
The problem is that it crashes when stickyHeaderIndices is updated at the same render the new data is added to the flatlist.

See screenshot

Demo: https://snack.expo.io/SkfE8USRN

React Native version:
React Native Environment Info: System: OS: macOS 10.14.5 CPU: (4) x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz Memory: 410.81 MB / 8.00 GB Shell: 3.2.57 - /bin/bash Binaries: Node: 10.13.0 - ~/.nvm/versions/node/v10.13.0/bin/node Yarn: 1.16.0 - ~/.nvm/versions/node/v10.13.0/bin/yarn npm: 6.9.0 - ~/.nvm/versions/node/v10.13.0/bin/npm Watchman: 4.9.0 - /usr/local/bin/watchman SDKs: iOS SDK: Platforms: iOS 12.2, macOS 10.14, tvOS 12.2, watchOS 5.2 Android SDK: API Levels: 23, 25, 26, 27, 28 Build Tools: 23.0.1, 25.0.2, 26.0.2, 26.0.3, 27.0.0, 27.0.3, 28.0.2, 28.0.3 System Images: android-23 | Intel x86 Atom_64, android-23 | Google APIs Intel x86 Atom_64, android-27 | Google APIs Intel x86 Atom, android-27 | Google Play Intel x86 Atom IDEs: Android Studio: 3.4 AI-183.6156.11.34.5522156 Xcode: 10.2.1/10E1001 - /usr/bin/xcodebuild npmPackages: react: ^16.8.6 => 16.8.6 react-native: ^0.59.8 => 0.59.8 npmGlobalPackages: react-native-cli: 2.0.1

Steps To Reproduce

  1. Render a flat list with empty data array.
  2. Load your datas (or wait some seconds), and update your array state with the items you loaded.
  3. Compute headers indices for chosen items.

Describe what you expected to happen:
No crash.

Bug Android

Most helpful comment

I found a temporary workaround for this issue. You can set removeClippedSubviews to false and it should work as intended.

All 26 comments

I have the same issue after upgrade to RN 59

@changLiuUNSW The problem wasn't in a previous version ? Do you know since version it appeared ?

@yairopro I may only know which version is working fine, because the issue happened after upgrade from Expo 32 to Expo 33. Expo 32 is based on RN0.57.1.
So I assume it may break any versions after RN0.57.1

I just did some research, I believe the stickyHeaderIndices is totally not working for FlatList in Android. You can simply reproduce by creating a FlatList and set stickyHeaderIndices to any value

I was trying to debug this and here are my observations:
1) Issue was only reproducible only on Android phones and with RN version 0.59.*
2) Tested on iOS with RN 0.59.9 and tested on Android with RN 0.58.* and the ScrollView stickyHeader works fine.
3) Like @changLiuUNSW noted, any value set to stickyHeaderIndices is causing this crash

Let me take a look into source of RNAndroid to find more on what could have caused it.

I can back up the observations @yeswanth did share.

I found a temporary workaround for this issue. You can set removeClippedSubviews to false and it should work as intended.

@yeswanth: I stuck on this bug for 2 weeks, you've saved my life!!! Thanks

Thanks @yeswanth . Not sure why set removeClippedSubviews to false can fix this issue.

@trucnd do you find any performance issue after set removeClippedSubviews to false?

@changLiuUNSW, I don't see any performance issue still now, it looks faster on long FlatList.

@changLiuUNSW I should have mentioned it, you can set removeClippedSubviews to either true or false and this issue doesn't occur. I think the recommended value is true for Android platform (As commented here)

you can set removeClippedSubviews to either true or false and this issue doesn't occur.

This is very strange, because the default value for removeClippedSubviews has been set to true already in this PR:
https://github.com/facebook/react-native/commit/1a499f43b2d03cc27dd6c25c8f13a767862afba1

If you look at ScrollView code... You will see the following

const hasStickyHeaders =
      Array.isArray(stickyHeaderIndices) && stickyHeaderIndices.length > 0;

<ScrollView
 {...otherProps}           
  removeClippedSubviews={
          // Subview clipping causes issues with sticky headers on Android and
          // would be hard to fix properly in a performant way.
          Platform.OS === 'android' && hasStickyHeaders
            ? false
            : this.props.removeClippedSubviews
        }
/>

The problem (as I have observed) is occurring when removeClippedSubviews is determined by dynamic value of hasStickyHeaders, when it is not overridden by the prop set in the component removeClippedSubviews. This is causing the problem in Android.

@yeswanth I think you pretty much find the cause and can create a PR for them :)

@yeswanth Also I just tried set removeClippedSubviews to true, the issue still exists. Have to set it to false

Any solution for it? Because I don't want to set removeClippedSubviews to false.

Facing same issue after upgrading to react native 0.60.3. App works fine on iOS but crashes on android when having huge data in flatlist.

@yeswanth Thank you for the workaround. its working !!!

https://facebook.github.io/react-native/docs/flatlist#removeclippedsubviews
But documentation states both saying "use for scroll performance" and at same time has a note stating "use at your own risk"

Any other solution ? considering performance.

Faced with this.

Temp solution: on Android return loader instead FlatList while items count is zero.

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions.

It is still not working

I found a temporary workaround for this issue. You can set removeClippedSubviews to false and it should work as intended.

Maaaan Thaanks

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions.

no stale

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions.

no stale

Still reproduced

Was this page helpful?
0 / 5 - 0 ratings