Skip to content
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

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

anandaroop
Copy link
Member

@anandaroop anandaroop commented Nov 14, 2024

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:

  1. A lighter home view prefetch is initiated from the splash screen
    • can be avoided by checking if we are following a deep link
  2. A heavier prefetch for a subset of home view sections’ content
    • can also be avoided by declining to render the home view at all when launching via deep link
  3. Content for other tabs is initiated from the home view
    • can be avoided thanks to the previous point

After this change

Case Behavior Screencap
Launching the app normally Performs prefetching, as before
regular-launch1080.out.mov
Launching via deep link Avoids prefetching
deep-link1080.out.mov
Launching via deep link, then returning to home Fetches the content just-in-time rather than prefetch. This is the necessary de-optimization that allows us to avoid the stampede of API requests
deep-then-home1080.out.mov
Launching via link to / Performs prefetching, as before
home-link1080.out.mov

PR Checklist

  • I have tested my changes on iOS and Android.
  • I hid my changes behind a feature flag, or they don't need one.
  • I have included screenshots or videos, or I have not changed the UI.
  • I have added tests, or my changes don't require any.
  • I added an app state migration, or my changes do not require one.
  • I have documented any follow-up work that this PR will require, or it does not require any.
  • I have added a changelog entry below, or my changes do not require one.

To the reviewers 👀

  • I would like at least one of the reviewers to run this PR on the simulator or device.
Changelog updates

Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

Dev changes

  • Avoids prefetching home view content when opening a deep link

Need help with something? Have a look at our docs, or get in touch with us.

MounirDhahri
MounirDhahri previously approved these changes Nov 15, 2024
Copy link
Member

@MounirDhahri MounirDhahri left a 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

@MounirDhahri MounirDhahri force-pushed the anandaroop-brainbicycle/ONYX-1392-conditional-prefetching branch from ca7936d to 4ea8724 Compare November 15, 2024 16:56
@MounirDhahri

This comment was marked as outdated.

src/app/utils/hooks/useIsDeepLink.tests.ts Outdated Show resolved Hide resolved
src/app/utils/hooks/useIsDeepLink.tests.ts Outdated Show resolved Hide resolved
src/app/Scenes/Home/HomeContainer.tsx Outdated Show resolved Hide resolved
@anandaroop anandaroop force-pushed the anandaroop-brainbicycle/ONYX-1392-conditional-prefetching branch from e7f4dc4 to d151919 Compare November 19, 2024 18:05
@anandaroop anandaroop marked this pull request as ready for review November 19, 2024 18:51
@ArtsyOpenSource
Copy link
Contributor

ArtsyOpenSource commented Nov 19, 2024

This PR contains the following changes:

  • Dev changes (Avoids prefetching home view content when opening a deep link - anandaroop)

Generated by 🚫 dangerJS against 8bdb4f8

Copy link
Contributor

@brainbicycle brainbicycle left a 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!

@anandaroop anandaroop force-pushed the anandaroop-brainbicycle/ONYX-1392-conditional-prefetching branch from d151919 to 4bf5896 Compare November 20, 2024 23:31
@anandaroop
Copy link
Member Author

anandaroop commented Nov 20, 2024

Brian and I paired on switching the detection back to matchRoute in 4bf5896 since it will be more reliable in the edge cases noted above. (h/t @MounirDhahri for suggesting that originally)

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:

brainbicycle
brainbicycle previously approved these changes Nov 21, 2024
Copy link
Contributor

@brainbicycle brainbicycle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you!

src/app/utils/hooks/useIsDeepLink.ts Outdated Show resolved Hide resolved
* @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)
Copy link
Contributor

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)
Copy link
Contributor

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) => {
Copy link
Contributor

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?

Copy link
Member Author

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?

Copy link
Contributor

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 :)).

simulator_screenshot_525B6452-2BB9-4C58-8F34-47B09C50ACD0

Copy link
Contributor

@brainbicycle brainbicycle Nov 21, 2024

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

Copy link
Contributor

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 🤔

Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Contributor

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 👍

Copy link
Member Author

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.

@anandaroop anandaroop force-pushed the anandaroop-brainbicycle/ONYX-1392-conditional-prefetching branch from 716ed41 to eff1785 Compare November 25, 2024 19:01
anandaroop and others added 5 commits November 25, 2024 14:40
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]>
@anandaroop anandaroop force-pushed the anandaroop-brainbicycle/ONYX-1392-conditional-prefetching branch from eff1785 to aeb8d74 Compare November 25, 2024 22:12
@anandaroop
Copy link
Member Author

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…

@anandaroop anandaroop added the Squash On Green A label to indicate that Peril should squash-merge this PR when all statuses are green label Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Jira Synced Squash On Green A label to indicate that Peril should squash-merge this PR when all statuses are green
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants