-
Notifications
You must be signed in to change notification settings - Fork 326
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: image gallery issues #2835
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -72,12 +72,12 @@ export const useAnimatedGalleryStyle = ({ | |
{ scaleX: -1 }, | ||
{ translateY: yScaleOffset }, | ||
{ | ||
translateX: -translateX.value - xScaleOffset, | ||
translateX: -xScaleOffset, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Translating by |
||
}, | ||
{ scale: oneEighth }, | ||
], | ||
}; | ||
}, []); | ||
}, [index]); | ||
|
||
return [animatedGalleryStyle, animatedStyles]; | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It appears that with at least Expo 52 (and new architecture enabled), the native
Image
component'sonLoadStart
andonLoadEnd
began behaving weirdly.Namely, Expo's caching strategies for images try to enforce an image with a specific url being returned from the cache whenever possible. This however (maybe in conjunction with some of our code), causes
onLoadEnd
andonLoadStart
to happen seemingly at the same time, producing something along the following lines as logs:This in turn causes
onLoadStart
to be called afteronLoadEnd
and thus the loading indicator never disappearing. I realize the fix is quite hacky, but this way we guarantee the order by forcingonLoadEnd
to go in the JS task queue.A proper solution would be something along the lines of having a
Set()
of trace IDs (each trace being created during a render) and invokingonStartReached
only if the current trace ID doesn't exist in theSet
(i.e bypassing the situation whereonEndReached
might've been called inbetween). However, this is currently not needed and we'll keep it in mind in case it does become a problem.