Open david-arteaga opened 1 year ago
Also wanted to mention that if initialScrollIndex
is set to 0
, then the list does render with the correct offset, respecting the header height. That's the only index that works though.
I have a similar issue. It actually does get close to the right index, but has a slight flicker for a second.
any solution guys ?
As a temporary workaround I’ve added an effect that scrolls to the initial index after a delay in mount.
I’m using with with a 200ms delay. The scroll view animates the last part of the scroll (around however much the header height is).
You could also set animate
to false but I think it looks better to make it look like the content actually scrolled to the desired element (at least the last part) than to make the content jump up.
function useScrollToInitialIndexOnce({
initialScrollIndex,
shouldScroll,
flashListRef,
afterMs,
}: {
/**
* Will only scroll once if this value is defined
*/
initialScrollIndex: number | undefined;
shouldScroll: boolean;
flashListRef: React.RefObject<FlashList<any>>;
afterMs: number;
}) {
const hasScrolled = useRef(false);
useEffect(() => {
if (isDefined(initialScrollIndex) && shouldScroll && !hasScrolled.current) {
const index = initialScrollIndex;
hasScrolled.current = true;
setTimeout(() => {
flashListRef.current?.scrollToIndex({
animated: true,
index,
});
}, afterMs);
}
}, [shouldScroll, initialScrollIndex, afterMs, flashListRef]);
}
I set the shouldScroll
param to whether the data in the list has already loaded, to make sure the scroll call runs after the list has rendered its content and has had a chance to measure its layout.
And I added the ref check because in our app the other params could change during the time that hook is mounted and that shouldn’t cause any additional scrolls.
@david-arteaga thanks, it seems to work fine. 🙂
This seems to be happening on iOS only but looks like a real issue. We'll try looking into this.
This seems to be happening on iOS only but looks like a real issue. We'll try looking into this.
It is also android issue
Same issue here. I have some custom insets and offsets, this seems to affect the position of the card when scrolled to as well.
@fortmarek I was wondering if you've had the opportunity to look into this matter. Your assistance would be greatly appreciated. Thanks!
Has anyone figured out a solution to this issue?
As a temporary workaround I’ve added an effect that scrolls to the initial index after a delay in mount. I’m using with with a 200ms delay. The scroll view animates the last part of the scroll (around however much the header height is). You could also set
animate
to false but I think it looks better to make it look like the content actually scrolled to the desired element (at least the last part) than to make the content jump up.function useScrollToInitialIndexOnce({ initialScrollIndex, shouldScroll, flashListRef, afterMs, }: { /** * Will only scroll once if this value is defined */ initialScrollIndex: number | undefined; shouldScroll: boolean; flashListRef: React.RefObject<FlashList<any>>; afterMs: number; }) { const hasScrolled = useRef(false); useEffect(() => { if (isDefined(initialScrollIndex) && shouldScroll && !hasScrolled.current) { const index = initialScrollIndex; hasScrolled.current = true; setTimeout(() => { flashListRef.current?.scrollToIndex({ animated: true, index, }); }, afterMs); } }, [shouldScroll, initialScrollIndex, afterMs, flashListRef]); }
I set the
shouldScroll
param to whether the data in the list has already loaded, to make sure the scroll call runs after the list has rendered its content and has had a chance to measure its layout.And I added the ref check because in our app the other params could change during the time that hook is mounted and that shouldn’t cause any additional scrolls.
I do not think it will be performant for a large list because the initial scroll can be too much. In my use case, I have paging enabled as well
I’ve used it with a list with about 5k images in rows of 3 (so about 1.6k rows) and it’s worked fine for that. At least I haven’t seen any visual jankyness. Haven’t profiled it though. I did provide heights for all elements (overrideItemLayout
).
But yeah, it’s a workaround, not a fix 🥲
Current behavior
When providing both
initialScrollIndex
andestimatedFirstItemOffset
, the content is not scrolled the right amount. TheestimatedFirstItemOffset
value is ignored.This is the recording from this snack: https://snack.expo.dev/@david.arteaga/faulty-initialscrollindex-with-estimatedfirstitemoffset The
initialScrollIndex
is set to3
, so theItem 3
item should be at the top of the list, but it's not.https://user-images.githubusercontent.com/7199015/200994419-7488c158-b8d5-4f7f-a784-c8d1999f282c.MP4
If the header is removed then
initialScrollIndex
behaves as expected.Expected behavior
The
estimatedFirstItemOffset
should be considered when calculating the initial offset wheninitialScrollIndex
is provided.To Reproduce
Run this snack on iOS: https://snack.expo.dev/@david.arteaga/faulty-initialscrollindex-with-estimatedfirstitemoffset
Platform:
I have not tested on Android.
Environment
1.1.0