Knowing if we are in a client side navigation or direct hit

[jycouet]

Describe the problem

Let's try to describe the Feature Request with a small graph:

flowchart TB
    b3-->a2
    subgraph Page Home
    a0[New visitor]-->a1[load server]-->a2[load browser]-->a3[Enjoy the home page]
    style a0 fill:#29B56A,color:#000
    style a3 fill:#254CA0,color:#000
    end
    subgraph Page About
    b0[New visitor]-->b1[load server]-->b2[load browser]-->b3[Enjoy the about page]
    style b0 fill:#29B56A,color:#000
    style b3 fill:#254CA0,color:#000
    end

Loading

As you can see, I have 2 routes: Home and About.
On a direct hit, the load function is executed 2 times once !browser once browser ✅
On navigation from About to Home, the load function of Home is executed 1-time browser ✅

The problem: how can I know in a load function if I'm in a client side navigation or direct hit?

Describe the proposed solution

The best to my mind would be to have something similar to browser like:

import { clientNavigation } from '$app/navigation';

export async function load() {
    console.log(`clientNavigation`, clientNavigation);
    return {};
}

When it's a direct hit, the 2 load functions would have clientNavigation to false.
When it's a client side navigation, the load function would have clientNavigation to true.

Alternatives considered

Workaround I use today:

I have a file clientNavigation.ts

export let clientNavigation = false;

export const setClientNavigation = () => {
	clientNavigation = true;
};

And in __layout.svelte I have

<script lang="ts">
	// Todo: https://github.com/sveltejs/kit/issues/4048#issuecomment-1073577686
	import { afterNavigate } from '$app/navigation';
	import { setClientNavigation } from '$lib/clientNavigation';

	afterNavigate(() => setClientNavigation());
</script>

And now I can use clientNavigation value to know if I'm in a client side navigation or direct hit.

Importance

would make my life easier

Additional Information

This would allow nice scenarios for my library https://github.com/jycouet/kitql awaiting or not to fill stores depending on the situation.

I would be happy to contribute (very happy actually!), just let me know:

• If I forgot some part of the use case, things to consider, ...
• Where to start?

[mrkishi]

I wonder how common a use-case this is? Since workarounds are possible and they aren't even that hairy, we should consider if it warrants a new feature.

As for the API, since load() lives in context module and doesn't have access to kit stores, it might be simpler to add a new property on LoadInput. Maybe even borrowing navigating's from (and possible future) semantics?

I'd love to hear others' thoughts.

[jycouet]

The workaround is not very complicated and works well yes. But it's one step that all my library users need to do to enjoy it fully. (BTW, I wrapped the 3 lines in a component to put in __layout so that it's even easier!)

For sure it's not a blocker 🙃, but I wanted to check before working on it if you would accept something in this direction or not.

Adding it to the LoadInput would not be so great on my side as developers using my lib would need to pass the property manually like 👇

export async function load({ clientNavigation }) {
    KitQL.query({ clientNavigation })
    return {};
}

Today, with the workaround, it's magic like 👇

export async function load() {
    KitQL.query()
    return {};
}

[mrkishi]

I'm actually not sure I follow your use-case after re-reading the proposal. If you only care about knowing whether or not it's the first time load has been called so you can fill some stores, couldn't you keep track of that from within your library?

Some well placed if (browser && !initialized) and initialization would be equivalent to the afterNavigate guard, no?

[jycouet]

I started to think... But why I didn't think about it earlier!!!
But in the end, I don't know where to place "well" the initialized. As it's not really "initialized", it's really: "I'm I in client side? or direct hit?"

Because, I can do:

export async function load({ fetch }) {
    await KitQL.query1({ fetch })
    await KitQL.query2({ fetch })
    return {};
}

And in both query1 & query2 I would need to know in what mode I'm in.
So I can't initialize after query1.

And I can't have

import { afterNavigate } from '$app/navigation';
afterNavigate(() => console.log('Hello you'));

Because it's telling me: Function called outside component initialization

[mrkishi]

I believe the explicit addition to load would be an easier buy for people than a globally available flag—that'd be equivalent to exposing the SvelteKit's client singleton, and I'm not sure there's interest in that.

Anyway, you can still have an equivalent guard for your scenario without user input with something like this:

import { browser } from '$app/env';

export let clientStarted = false;

if (browser) {
	addEventListener('sveltekit:start', () => {
		clientStarted = true;
	});
}

clientStarted would only be true after the first page was loaded and rendered.

[jycouet]

WoW, this works like a charm!
Thx a lot @mrkishi

It will improve usability of my lib 👍

[jycouet]

I found a case where the trick is not working.
=> When my lib is not used in the direct hit. The event sveltekit:start will never fire.

To avoid this, I have to put myLib.init() in the root __layout to make sure my lib is here from the start.

But coming back to the origin, it's where import { clientNavigation } from '$app/navigation'; would make sense. To have the platform providing this information.
Thoughts?

[CaptainCodeman]

I use this approach to handle switching from server-loaded Firestore data to client-side subscriptions, without re-fetching data twice when subsequently navigating between routes on the client (same deal - you want to know when the initial server -> client mode changeover has happened).

It would be convenient to have a flag, similar to dev and browser (hydrated?) especially as there isn't always a guaranteed root layout (if you have branches with resets, or in future "named" layouts).

Alternatively, some client side root hook / function would be somewhere it could go.

[jycouet]

Great new video: Rich Harris - The Road to SvelteKit 1.0 (Svelte Society NYC)
Talking about navigation types: https://youtu.be/s6a1pbTVcUs?t=1501

I didn't find another issue to link this one too.
I guess that use cases are really close.