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

Calling goto directly causes server side navigation #1764

Closed
zeckon opened this issue Jun 26, 2021 · 5 comments · Fixed by #2089
Closed

Calling goto directly causes server side navigation #1764

zeckon opened this issue Jun 26, 2021 · 5 comments · Fixed by #2089
Labels
bug Something isn't working router
Milestone

Comments

@zeckon
Copy link

zeckon commented Jun 26, 2021

Calling goto directly causes page refresh and server-side navigation.

To Reproduce
I prepared a skeleton project at https://github.com/zeckon/sveltekit-goto

there are 3 routes:
/test1
/test2
/test3

all directly call goto('/') (index.svelte)

inside index.svelte it console.logs browser or ssr based on env

test1.svelte:

<script>
import { browser } from '$app/env'
import { goto } from '$app/navigation'
    if (browser) {
        goto('/')
    }
</script>

index.svelte:

<script context="module">
import { browser } from '$app/env'
export async function load() {
    browser ? console.log('client') : console.log('ssr')
    return {}
}
</script>

Expected behavior
Expectation is to see only client on browser logs, and nothing in server console.

❌ /test1 and /test2 also run on server (because of page refresh) and outputs ssr to console
✔️ /test3 wraps goto inside setTimeout only does client-side navigation outputs only client in browser as expected

Additional context
❔ can this be happening because client side router was not ready yet when goto was called.
✔️ calling goto after a fetch, or with user interaction (e.g. onClick) also triggers only client side navigation.

@benmccann benmccann added bug Something isn't working router labels Jun 26, 2021
@benmccann benmccann added this to the 1.0 milestone Jun 26, 2021
@mohe2015
Copy link
Contributor

mohe2015 commented Jun 27, 2021

grey_question can this be happening because client side router was not ready yet when goto was called.

yes pretty sure this is the problem.

I'm too lazy to test it but you could try listening for the sveltekit:start event and goto then. I'm not sure though if if waits for the router.

Also why do you not unconditionally goto (so don't check for browser). I haven't tested that either though.

@mohe2015
Copy link
Contributor

If you want to immediately redirect the load function seems to be able to return a "redirect" property. I didn't test it but it may work better.

@zeckon
Copy link
Author

zeckon commented Jun 28, 2021

you could try listening for the sveltekit:start event and goto then.
Also why do you not unconditionally goto (so don't check for browser). I haven't tested that either though.
If you want to immediately redirect the load function seems to be able to return a "redirect" property. I didn't test it but it may work better.

Thanks for the feedback and suggestions,

For my particular use-case, I need to ensure client-side redirection.

Apart from my use-case, I think goto should trigger client-side navigation when called directly, and I was not sure why it is causing a refresh on some cases, thus I created the issue.

@zeckon
Copy link
Author

zeckon commented Jun 28, 2021

could try listening for the sveltekit:start event and goto then.

Thanks for the suggestion, I added another test with sveltekit:start to the test repo, it is also triggering page refresh.

@benmccann
Copy link
Member

benmccann commented Aug 4, 2021

It's because rendering starts before the router is initialized:

	if (hydrate) await renderer.start(hydrate);
	if (route) router.init(renderer);

Rendering the component calls goto

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working router
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants