-
Notifications
You must be signed in to change notification settings - Fork 577
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: avoid prefetching when following deeplinks #11097
base: main
Are you sure you want to change the base?
fix: avoid prefetching when following deeplinks #11097
Conversation
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.
Nice! thanks for the fix
ca7936d
to
4ea8724
Compare
This comment was marked as outdated.
This comment was marked as outdated.
e7f4dc4
to
d151919
Compare
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.
i think we need a little more nuance in our home deeplink detection, happy to pair tomorrow if it would be helpful!
d151919
to
4bf5896
Compare
Brian and I paired on switching the detection back to I confirmed that the screengrabs above still work the same after these changes, and we also ran through the various cases in this gist, which may also come in handy at Mobile QA time: |
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.
thank you!
* @returns {isDeepLink: boolean | null} isDeepLink is true if the user came from a deep link | ||
*/ | ||
export const useIsDeepLink = () => { | ||
const [isDeepLink, setIsDeepLink] = useState<boolean | null>(null) |
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.
very minor: Shouldn't the initial value be undefined
instead of null
because it's not yet defined (null vs undefined)?
}) | ||
.catch((error) => { | ||
console.error("Error getting initial URL", error) | ||
setIsDeepLink(false) |
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.
also very minor: Setting the value to false
when retrieving the URL fails does not seem 100% correct. However, setting it to another value (undefined
or null
) or adding an error state will probably make this hook very complicated. 🤷
@@ -20,14 +21,18 @@ export const useHideSplashScreen = () => { | |||
|
|||
if (isHydrated) { | |||
if (isLoggedIn && isNavigationReady) { | |||
prefetchUrl("/", homeViewScreenQueryVariables(), { | |||
force: false, | |||
Linking.getInitialURL().then((url) => { |
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.
Couldn't we use the new hook useIsDeepLink
here as well?
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.
I had the same thought and tried this out briefly, but got some errors that suggested this wouldn't work. Do you want to give it a try @olerichter00?
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 looks like useIsFocused
(which is used by useIsDeepLink
) is causing the error because it cannot be used outside of a NavigationContainer
.
But I wonder whether we need the deep link check here at all. Even when following a deep link, prefetching the home view query would make sense because it's likely that the user will navigate to the home screen within the same session. Removing the check could have performance implications, but I don't think they are significant (which we should check :)).
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.
the motivation here is that eigen is very chatty when first launched and this has led to incidents in the past: https://artsy.slack.com/archives/CA8SANW3W/p1731531969773739
but yeah it is a balance between performance for users and not overloading our systems.
It does occur to me though that the concern is more around push notifications and in app messages specifically as these will result in large groups of users launching the app in a small time frame and causing spikes on our servers
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.
we could possibly distinguish that case specifically 🤔
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.
in app messages I would need to look at, there should be some braze callbacks we can get hopefully in js land.
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.
I'll timebox an attempt at this^ (happy to pair also) — but if that doesn't pan out quickly how would we feel about merging this as-is, and then following up with this further refinement?
If I'm understanding correctly, the only risk right now is a non-optimized home screen load for people who following an email deeplink, then navigate back to home.
If that's right I think we stand to gain more than we lose with this current version, since we are still open to this stampede problem, even as we speak.
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.
I am fine with that personally, I think the more risky thing is the check in the HomeContainer, if we get that wrong we get dead home screens. I will create a ticket to follow up so if you want to timebox fine but fine also to leave it for the time being.
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.
+1 merging this PR as is 👍
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.
Ok, let's go with that. (My timebox didn't really yield anything).
One more rebase and I'll merge this.
716ed41
to
eff1785
Compare
Co-authored-by: Ole <[email protected]> Co-authored-by: Anandaroop Roy <[email protected]>
Prior to this change we were rendering a blank home screen in the event of navigating directly to /
This will be more reliable in the case of various edges cases that might bring the user to the home screen
Co-authored-by: Ole <[email protected]> Co-authored-by: Mounir Dhahri <[email protected]>
eff1785
to
aeb8d74
Compare
The rebase was a bit trickier due to #11184 getting merged this morning — but all good now, and I've run through all the above cases again on iOS and Android. Going for the merge on green… |
This PR resolves ONYX-1392
Co-authored-by: @brainbicycle
Co-authored-by: @MounirDhahri
Co-authored-by: @olerichter00
Description
The goal here is to avoid prefetching when following a deep link, in order to avoid an unnecessary stampede that results in API latency.
We observe that prefetching happens in a few ways:
After this change
regular-launch1080.out.mov
deep-link1080.out.mov
deep-then-home1080.out.mov
/
home-link1080.out.mov
PR Checklist
To the reviewers 👀
Changelog updates
Changelog updates
Cross-platform user-facing changes
iOS user-facing changes
Android user-facing changes
Dev changes
Need help with something? Have a look at our docs, or get in touch with us.