showtime-tab-view
showtime-tab-view copied to clipboard
Blank space when scrolling to fast with TabFlashList
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.
https://github.com/showtime-xyz/showtime-tab-view/assets/80993895/20ed412c-d9ff-43c3-9fd0-04ed84a39abe
Here is occurred with flatlist on ios https://github.com/showtime-xyz/showtime-tab-view/assets/80993895/3c6607ee-f816-48e2-8035-9c0eb2736853
hey@ducnguyen4301 can you provide an example on https://snack.expo.dev/?
Hi @alantoa, here is example for this https://snack.expo.dev/@ducnguyen4301/example-tab-flashlist. You can try it !
@ducnguyen4301 you are using Reanimated v3, right?
@ducnguyen4301 try this latest version that i just released it
no im just use Reanimated v2
Have you tried to latest version that i just related?
@alantoa yes, i tried but problem still
@ducnguyen4301 hey, I think I understand your problem, you should make sure you are passing the correct index to your TabFlashList
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
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}
/>
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
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