-
Notifications
You must be signed in to change notification settings - Fork 71
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
hotReload: true prevents page navigation #43
Comments
destroy is proxied through.. I'm not sure but I'll have a look. |
Think it might be to do with |
That sounds plausible... the navigation code is in https://github.com/sveltejs/sapper/blob/master/src/runtime/index.ts, specifically this function |
cheers, I'm on it right now, will keep you posted |
awesome, thank you |
I might need some help with svelte/sapper internals. For example (this is from sapper-template), there is a component |
If you go here https://svelte.technology/repl?version=1.55.0&example=nested-components and click the input/output toggle, you'll notice |
Thanks, makes a lot of sense... Is this snippet the self-mounting code?: if (options.target) {
if (options.hydrate) throw new Error("options.hydrate only works if the component was compiled with the `hydratable: true` option");
this._fragment.c();
this._fragment.m(options.target, options.anchor || null);
........
} |
yeah, sorry.. ignore me.. you pointed out the line number |
just to keep you updated... I have skirted around the self-mounting components issue. Still trying to figure out why |
Hi, Two problems:
I have fixed both in However, there are still some edge cases where hot-reload does not repaint top-level components after a change. If you can make it so that even top-level components also go through |
Everything seems to be working well with this, the latest Sapper (and sveltejs/sapper-template#40), so I'll close this. Thank you so much! |
I haven't looked into this at all yet, but it appears that
hotReload: true
is breaking page navigation in Sapper. My hunch is that it doesn't play nicely with components that have already been destroyed withcomponent.destroy()
. cc @ekhaledThe text was updated successfully, but these errors were encountered: