SvelteKit v2: $page not reevaluated after invalidateAll

[peterpeterparker]

Describe the bug

In SvelteKit v2, the $page derived store is not reevaluated after triggering invalidateAll. For example, modifying the URL using replaceState and then calling invalidateAll to propagate the new URL parameters does not work as expected.

This behavior is different from SvelteKit v1, and I assume it's not an intentional breaking change.

---

Snippet:

+page.svelte

<script lang="ts">
	import { page } from '$app/stores';
	import { invalidateAll, replaceState } from '$app/navigation';

	const updateUrl = async () => {
		const url = new URL(window.location.href);
		url.searchParams.set('network', `${Math.random()}`);
		replaceState(url, {});

		await invalidateAll();
	}
</script>

<output>{$page.data.network}</output>

<button on:click={updateUrl}>Update URL</button>

+page.ts

import type { LoadEvent } from '@sveltejs/kit';

const loadRouteParams = ($event: LoadEvent) => {
	const {
		url: { searchParams }
	} = $event;

	return {
		network: searchParams?.get('network'),
	};
};

export const load = ($event: LoadEvent) => loadRouteParams($event);

Reproduction

git clone https://github.com/peterpeterparker/invalidate
cd invalidate
npm ci
npm run dev

Logs

No response

System Info

System:
    OS: macOS 14.1.1
    CPU: (8) arm64 Apple M2
    Memory: 125.02 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.16.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 9.6.1 - /opt/homebrew/bin/npm
  Browsers:
    Brave Browser: 120.1.61.104
    Chrome: 120.0.6099.109
    Firefox: 121.0
    Safari: 17.1
  npmPackages:
    @sveltejs/adapter-auto: ^3.0.1 => 3.0.1 
    @sveltejs/kit: ^2.0.4 => 2.0.4 
    @sveltejs/vite-plugin-svelte: ^3.0.1 => 3.0.1 
    svelte: ^4.2.8 => 4.2.8 
    vite: ^5.0.3 => 5.0.10

Severity

blocking an upgrade

Additional Information

No response

[mostrecent]

I've faced something similar, not sure if it is related: #11415

[PatrickG]

pushState and replaceState are for shallow routes only.
After using them, Sveltekits point of view is still the previous page. Only $page.state is updated.

You can use goto with { replaceState: true } like in Sveltekit v1.

[peterpeterparker]

@PatrickG I use replaceState because SvelteKit v2 throws a warning otherwise. In v1, I do it manually with window.history.replaceState({}, '', url);.

goto doesn't fit the use case that requires replacing the history without executing navigation. This is especially important in one of my apps where the selector is in the middle of the page. Using goto would reset the scroll to the top.

But again, works fine in v1, so maybe it's a breaking change of v2?

[iolyd]

@peterpeterparker, a bit out of subject, but concerning your point of losing the scroll position: have you tried

goto(..., {
  replaceState: true,
  noScroll: true
})

[peterpeterparker]

@iolyd yeah I did but it did not work as excepted, I might have screw something. Let me try again...

[peterpeterparker]

of course it works now! Never try stuff late at night, I guess issue was between screen and keyboard.

I'll do a await goto(url, { replaceState: true, noScroll: true }) and I'll be fine, so I can close this issue.

Thanks @iolyd and my bad then @PatrickG that was a false assumption on the scroll.

[PatrickG]

of course it works now! Never try stuff late at night, I guess issue was between screen and keyboard.

I'll do a await goto(url, { replaceState: true, noScroll: true }) and I'll be fine, so I can close this issue.

Thanks @iolyd and my bad then @PatrickG that was a false assumption on the scroll.

Glad you could solve your issue.
I would suggest adding keepFocus: true as well.