Blank space when scrolling to fast with TabFlashList

[mduc-dev]

When using TabFlashList scrolling fast there will be blank space problem of FlashList, do you know how to fix this?. I have switched to TabFlatList but android works fine and ios fails in first time open app.

blank.space_android.webm

blank_space_ios.mp4

[mduc-dev]

Here is occurred with flatlist on ios
https://github.com/showtime-xyz/showtime-tab-view/assets/80993895/3c6607ee-f816-48e2-8035-9c0eb2736853

[alantoa]

hey@ducnguyen4301 can you provide an example on https://snack.expo.dev/?

[mduc-dev]

Hi @alantoa, here is example for this https://snack.expo.dev/@ducnguyen4301/example-tab-flashlist. You can try it !

[alantoa]

@ducnguyen4301 you are using Reanimated v3, right?

[alantoa]

@ducnguyen4301 try this latest version that i just released it

[mduc-dev]

no im just use Reanimated v2

[alantoa]

Have you tried to latest version that i just related?

[mduc-dev]

@alantoa yes, i tried but problem still

[alantoa]

@ducnguyen4301 hey, I think I understand your problem, you should make sure you are passing the correct index to your TabFlashList

[mduc-dev]

Hi @alantoa , i don't think problem in my index, this appear blank space from flash list when i scrolling and change tab to fast

[Fengweiyuu]

hello,i resolve thie problem,you can try it:
set "getItemType"

<TabFlashList
  index={tabIndex}
  data={items}
  estimatedItemSize={120}
  scrollEventThrottle={16}
  keyExtractor={(item, index) => `${item.articleId}_${index}`}
  renderItem={({ item, index }) => (
    <ArticleView
      key={`${item.articleId}_${index}`}
      style={styles.item}
      nowTime={nowTime}
      article={item}
      hideAvatarRow={true}
      onArticleContentPress={article => handleArticleItemPress({ navigation, article })}
    />
  )}
  getItemType={(item, index) => `${item.articleId}_${index}`}
  ItemSeparatorComponent={() => <Divider size="hair" wingHorizontal={dimensions.h} />}
  ListFooterComponent={footerView}
  onEndReached={onEndReached}
/>

[hirbod]

Hey, I have noticed an issue in your workaround. The getItemType method registers a new recycling pool for every single item. This approach is incorrect and can lead to crashes, especially with long lists. It should only be used to differentiate different item types (which vary significant in layout / dimensions)

The purpose of getItemType is to handle different layouts, like headlines, sections, or specific item types that differ from the one being recycled. This helps reduce the need for re-layout tasks. However, in your current implementation, you're registering a new pool for every item, which is not the right approach, totally disabled recycling and will skyrocket your memory. Correct behavior is to have a minimal set as possible (like 3-10 max, depending on the variation of your items).

So we need to fix this differently. Please revoke your changes. Your list consists of single item types, you don't need getItemType

[Fengweiyuu]

So we need to fix this differently. Please revoke your changes. Your list consists of single item types, you don't need getItemType

ok,i get it, thanks