Resetting components on navigation

[Rich-Harris]

A page like /photos/1 can be represented like this:

<RootLayout>
  <PhotosLayout>
    <Photo photo={props.photo}/>
  </PhotosLayout>
</RootLayout>

This is pseudo-code — in reality it's a bit more complicated — but it's basically what happens if you have a root __layout.svelte and a photos/__layout.svelte file in addition to your photos/[id].svelte.

If the user navigates from /photos/1 to /photos/2, then the component tree is unchanged — SvelteKit just updates props.post. This is deliberate, for two reasons:

• Performance-wise, it's better to update a component in place rather than destroy and recreate it
• Preserving the component makes it much easier to do interesting transitions, like a carousel effect or a cross-fade between photos

But this has an impact on application design — the internal state of <Photo> is preserved. For example if the photo page has a collapsible 'detail' box showing the photo's EXIF data, the collapsed state will persist across navigations. If that's not what you want, you can reset the state in an afterNavigate function, but you need to make sure that any new non-persisted state added later on is also reset.

For some people, this is confusing:

• Svelte is reusing component with its state on different pages using the same route #3506
• <script> is not executed when browsing from a [slug].svelte route to itself even with a different slug #4895
• Add option to always reinstantiate a component on navigation #4941

Proposed solution

Personally I'm inclined to argue that the afterNavigate solution is totally fine, as long as we do a good enough job of documenting what happens when the user navigates. We don't normally expect components to be destroyed and remounted on state changes, and navigation is arguably just a kind of state change.

But since this has been a source of confusion, it's worth considering what a solution might look like. One suggestion was to provide a 'key' that could be used to determine whether a component should be preserved:

<script context="module">
  export function key({ url, routeId }) {
    // always destroy and remount
    return url.pathname;

    // preserve component when navigating to the same route (current behaviour)
    return routeId;
  }
</script>

This is an interesting idea, but it wouldn't work in the case where you click a link to the page you're currently on (which should result in a reset if the route would normally result in a reset when you navigate between pages that belong to it). You could maybe return Math.random(), but... no.

I'm therefore proposing an alternative approach — returning a preserve key from load:

<script context="module">
  export function load() {
    // always destroy and remount
    return {
      preserve: false
    };

    // preserve component when navigating to the same route (current behaviour)
    return {
      preserve: true
    };
  }
</script>

On navigation, the node closest to the root with preserve: false (whether that's the page component — the 'leaf' — or a layout component) would be briefly removed from the tree...

<RootLayout>
  <PhotosLayout>
    <-- this space left intentionally blank -->
  </PhotosLayout>
</RootLayout>

...then put back:

<RootLayout>
  <PhotosLayout>
    <Photo photo={props.photo}/>
  </PhotosLayout>
</RootLayout>

Defaults

Assuming people a) think this is an important problem to solve, and b) like the proposed API, we need to talk about defaults. As I see it there are three options:

preserve: true, the status quo

Pros:

• Performance by default
• Consistency with how state changes generally work in Svelte
• Ease of explanation

Cons:

• Persistent state that you don't always want

preserve: false

Pros:

• Consistency with what happens normally on the web when you navigate

Cons:

• Bad for performance
• It's very rare that you want to reset layouts. For example on https://kit.svelte.dev/docs, you don't want to reset scroll state in the sidebar when you click

preserve: false for leaves, preserve: true for layouts

Pros:

• Matches (at least some) people's intuition of what the 'correct' behaviour should be
• Balances performance and pragmatism

Cons:

• It feels like a really confusing thing to explain
• It's not coherent. On what basis do we want to reset the page, but not all of the page?

Prior art

I looked at other popular frameworks that have nested routes:

• Remix has the same behaviour we do — state is preserved across components at all levels of the tree
• Nuxt has the hybrid behaviour — pages are reset, layouts are preserved. There is a key mechanism, but I couldn't get it to work

[babichjacob]

I find it to be enough to initialize the page's state through props in load. They get reset on navigation to any page that uses this page component (including a navigation to itself):

<!-- src/routes/[whatever].svelte -->
<script context="module">
	export const load = async (args) => {
		return {
			props: {
				// Initial page state (gets mutated during page lifespan)
				open: false,
				
				// ... Other props that you don't mutate
			}
		};
	};
</script>

<script>
        // People would otherwise write `let open = false;` and run into the described problem
	export let open;

	// Mutate state
	const toggle = () => {
		open = !open;
	}
</script>

<button on:click={toggle}>Toggle</button>

{#if open}Expanded text{/if}

When components are used in the page, props should be passed (perhaps via binding) to them instead of them having state that the parent can't control.

Can anyone who has the described problem share an example so I / we can try to solve it with a variation of this technique?

[benwoodward]

Instantiating a new component on navigate is a lot easier to reason about. SvelteKit is becoming quite a complex beast, I'm inclined towards making things easier to reason about over performance. So long as the performance difference is small.

I like the idea of instantiation by default, but possible to disable this default behaviour via a function.

[vishalbiswas]

I have a problem with this approach. There can't be any "dumb" pages i.e. with just component logic, no explicit network calls or load. I would like to use page endpoints wherever possible to pass data onto pages. But with this approach, I will need to have an extra script tag with context="module".

I would suggest having a special function / store that will receive a callback. This callback will return an object containing any derived properties of the route. Only the value return by this function will be re-evaluated on route params / props change.

const state = derive(() => {
  return {
    stats: getStats()
  };
});

[johnnysprinkles]

I'm thinking about the case where you only want to consider certain params, say something major can change, but something minor can also change where you want to preserve:

/routes/catalog/[id]/page/[pagenumber].svelte

I think "navigating" will have a value at this point? So you could do this?

<script context="module">
  import { navigating } from '$app/stores';
  export function load() {
    let { from, to } = $navigating;
    let m1 = from.pathname.match(/^\/catalog\/(\d+)/);
    let m2 = to.pathname.match(/^\/catalog\/(\d+)/);
    return {
      preserve: m1 && m2 && m1[1] === m2[1]
    };
</script>

[Rich-Harris]

No, that won't work — $navigating only has a value inside the component instance (that's just how stores work). You could do get(navigating) but it's kinda hacky. But moreover, unnecessary, I think? We'd only want preserve to mean anything when we were navigating (i.e. not when load was re-running for some other reason, like a session change or an explicit invalidation).

[dominikg]

hmm, can you do

{#key photo.id}
<Photo {photo}/>
{/key}

to selectively force recreating components on data-only changes?

[benmccann]

This is about resetting the page component, not components within the page, so I'm not sure the user has any ability to affect it currently, which is why Rich is proposing a new preserve option

[ramiroaisen]

You can wrap the final component in a page component like that

[ric2b]

as long as we do a good enough job of documenting what happens when the user navigates.

As someone who found the native behavior unintuitive I think this is the most important part, regardless of the proposed solution. I'm not an experienced front-end developer and it wasn't obvious to me that navigating between pages was being handled as an SPA instead of a browser navigation, and I think that's where the confusion tends to come from.

In my opinion it would be very useful to have a note about this behavior on the dynamic parameters section of the documentation and a recommended workaround/solution.

[paulopes]

When the component doesn't take any props, such as when using MDsveX, a workaround would be to reference the component in a svelte:component tag.

In other words, this:

<Post />

Becomes this:

<svelte:component this={Post} />

It forces the re-rendering of the Post component, even when clicking on links to itself, which can happen frequently when a user is navigating inside of an MDsveX blog.

[johnnysprinkles]

I think flipping the default around to assume preserve: false would be a bold move. I like it.

If you think about it, whatever we do now for navigating around the tree must be a good experience, so why isn't that good enough also for sideways navigation among the same route? Concerns about performance seem more theoretical than everyday practical.

Not sure about layouts though, can we just do whatever we do today when navigating between route A and route B that both share a layout? Just match that behavior? I suppose this would be "preserve layouts, reset leaves".

Also I had an idea about my "conditional preserve" use case... can we take inspiration from HTTP etags and offer a second option, something like:

return {
  preserveIfMatch: {
    params: ['id']
  }
};

One common case I imagine is preserving when only the query string changes, otherwise reset, which you could do with:

return {
  preserveIfMatch: {
    params: ['id', 'pagenum'], // or '*' maybe for all?
  }
};

Where preserveIfMatch would be an object having two fields, params and searchParams, each being an array of key names. I can't think of a case where you'd need any arbitrary logic or inputs other than params/searchParams, like "preserve if it's an odd day of the month" or anything.

[itssumitrai]

Wait why do people expect component would be destroyed and re-mounted on navigation ? I have used several client side navigation libraries over the years, and I see the same behavior what Sveltekit is using at the moment, very baffling 🤔

[benwoodward]

so the lifecycle events are triggered. that's the benefit, not really an expectation because it's up for debate.

[natevaughan]

Registering my vote for "preserve: false for leaves, preserve: true for layouts"

Thanks for treating this issue like it matters. I think it's really important to get right.

Just a note on the performance benefit: I've always been a fan philosophically of write first, optimize later. So having preserve:false for leaves is what I would expect to use 90%+ of the time. If I need a nice transition or I'm running into a performance bottleneck, I have the ability to optimize later.

[johnnysprinkles]

[PatrickG]

Regardless of whether the page component will be reset or not, the "stale data/blank it out/show spinner problem" remains. Thus, your argument is invalid.

[johnnysprinkles]

Yeah, this point isn't very coherent, deleting this to clean up the thread.

[AlessioGr]

If the user navigates from /photos/1 to /photos/2, then the component tree is unchanged — SvelteKit just updates props.post. This is deliberate, for two reasons:

You probably mean props.photo there, not props.post.

Generally I really like having a "preserve" option. Caused quite some confusion for me as well, when my "locale" prop on my Header changed, but the navbar didn't update (I had the link labels in a map, and had to wrap the creation of the map into a $: to make it reactive and update when the locale changed). Really confused me until I found out this was caused by that, so I can see how having preserve: false as default would be helpful.
I personally think it's better to leave that to true, though, and just explain it better in the docs - and make sure everyone sees this :P

Another idea: what about having an option to restructure / "fake an update" for only some variables, or only restructure them / the component if only a certain variable (which can be configured) has changed?

[johnnysprinkles]

It'll be interesting to revisit this discussion after the dust settles on #5748

[FeldrinH]

I personally also support preserve: false for leaves and preserve: true for layouts as defaults. (Regardless of what the defaults end up being, I very strongly support the idea that there should be some way to control whether page components are preserved or not.)

My reasons are as follows:

1] preserve: false for leaves and preserve: true for layouts feels intuitively correct and consistent. With how most websites work, it makes a lot of sense to me that a navigation to a different url should always correspond to the page component being recreated.

On a typical website (or at least most websites I can think of) pages like /photos/1 and /photos/2 would be two different distinct pages with different content and as such it seems right the page component should not be preserved and shared between them, whereas the layout between them would be the same (because layouts generally do not depend on dynamic route parameters), so it makes sense that the layout component is preserved.

This is also sort of a counterargument to these cons:

• It feels like a really confusing thing to explain
• It's not coherent. On what basis do we want to reset the page, but not all of the page?

Pages should be reset because the pages generally depend on the dynamic parameters which changed, whereas layouts generally do not depend on the dynamic parameters and therefore stay the same and should not be reset.

Obviously this reasoning does not apply for all websites and you could construct a counterexample, however at least a cursory glance at websites I commonly use makes me reasonably confident that it does apply for a majority of websites. And for those where it does not apply, the option to override the default could be used.

2] The current system makes it more error prone and complicated to deal with data that the user can edit, especially when saving data to the server is involved.

I find that it is annoyingly easy to accidentally leak state between two different pages when the component is preserved during navigation. Preserving components adds another layer to the page component's lifecycle which makes reasoning about things more complex and error prone.

For example, let's say you have a form that allows the user to edit a photo's details at /photos/[id]. Then you want to ensure that a) no unsaved data is accidentally discarded and b) when navigating from one photo to another, all relevant state, including user editable data and change tracking, should be reset.

As I understand it, the current approach is to use afterNavigate to explicitly update the data after each navigation, which makes fulfilling a) fairly easy, because you can be confident that only navigation, which you can block in beforeNavigate, could ever overwrite the data, but it makes fulfilling b) tricky, because you have to be careful that you always clear all relevant state when navigating.

For example, let's say you have a variable on your photos page that tracks the last saved version of the data and the user navigates from /photos/1 to /photos/2 while changes to photo 1's details are being saved (with an async call to the server). Then after saving finishes the last saved version variable would be set to the details of photo 1, while the user is on the page for photo 2, which would cause unexpected behavior.

[FeldrinH]

Some more prior art based on what I could figure out about Angular and Next.js:

• Next.js as far as I can tell does the equivalent of preserve: true by default for both pages and layouts, however you can add a key on the page or layout component in your app declaration to force a remount, effectively allowing you to achieve preserve: false, but without remounting when navigating to the same page, for both pages and layouts if needed.
• Angular also seems to do the equivalent of preserve: true by default for both pages and layouts, at least based on experimenting with the Tour of Heroes example app. However, Angular has so many modules and configuration options that I am not sure if/where this can be configured or if this is in fact the default in all configurations.

So overall it seems that Nuxt is the odd one out here in preferring the hybrid approach, however Next does offer the option to remount based on a key if you want to and I suspect Angular has the relevant configuration somewhere, but I don't know where.

[FeldrinH]

Also worth noting:

Nuxt3 appears to only remount the page if the path changes. If the query string or fragment changes, the component is preserved. So navigating from /photos/1 to /photos/1?info=1#details does not remount, but navigating from /photos/1 to /photos/2 does.

So it appears that Nuxt3 behavior for pages is equivalent to

export function key({ url }) {
    return url.pathname;
}

rather than preserve: false.

As such it seems there is actually no precedent among popular frameworks for remounting the component when navigating to the same page and both Nuxt and Next favor the key-based approach.

[FeldrinH]

Even more prior art:

Routify has param-is-page and query-params-is-page metadata, which allows you to mark pages or layouts where you want the component to be remounted if the path params or query params respectively change (see https://www.routify.dev/docs/metadata). As far as I can tell no way to make navigating to the same page remount, though there does seem to be some function you can call to explicitly remount the page (see roxiness/routify#344, couldn't find it in the docs).

Overall it seems that most frameworks have options for remounting if the path or query params change, but not when navigating to the same page and I am inclined to agree that for clientside rendering it does make intuitively more sense to remount only when something in the url changes. This also allows for more seamlessly adding intermediate configurations such remounting when the path changes but not when query params change.

[madeleineostoja]

If the main rationale for this feature is that the current behaviour has caused confusion, then surely the lowest hanging fruit is just more explicit documentation?

I can only speak for my own experience, but destroying and remounting pages between routes goes against one of the key benefits of an SPA, and feels like a pretty niche use-case. Unless there's proven solid demand for it I feel adding this feature rather than just suggesting to cleanup on afterNavigate like Rich mentioned is unnecessary API bloat

[FeldrinH]

For me the main rationale is that the current approach makes correctly ensuring no state leaks between different pages on the same dynamic route harder and more error prone, even if you know about the current behavior.

[FeldrinH]

As for demand, I can also only speak for myself, but almost every website I've worked on had a sizable number of pages that would benefit from the ability to remount if path parameters change. (Most of those websites were not made with SvelteKit, but that's beside the point)

[FeldrinH]

To be clear, I propose and support the following behavior:

/photos/1 and /photos/2 should be considered two distinct pages, even if the underlying component is the same, and navigating between them should remount. This is useful because I do not want these two pages to ever have any shared state.

However, navigating from /photos/1 to itself or to /photos/1?u=7#details should not remount, because this would be the same page with the same content and therefore I want state to be preserved.

Intuitively, the system should behave as if there are /photos/1.svelte and /photos/2.svelte components, even if there is in fact a single component with a dynamic param. All other behavior could stay the same as it is now.

This behavior would match Nuxt 3 and Routify with param-is-page.

[FeldrinH]

If I understand correctly, this is not the same behavior as preserve: false for pages, which would remount on every navogation.

[artemkovalyov]

When we're talking about the state it should never be implicit. I ate my brain with a [catch all...] endpoint that didn't change a component tree. I don't have a strong opinion about the best routing pattern, I have a strong opinion it shouldn't be a puzzle or know-how of a few. What would help:

• Comprehensive documentation about @app/navigator working modes and lifecycle together with the options for anchors.
• Potentially detecting such routing situations at build or run-time and log info message as a hint
• Clearly mention somewhere in the routing guide that all the routes are intercepted by @app/navigation and the decision is made at the run-time.

I think the mental model of most developers who start with Svelte would be like this: path changed -> components are re-rendered, especially if the path is a part of deciding what and how is going to be rendered. All those MDSvex Blog examples follow this pattern at least.

[JohannesPertl]

How did you solve your problem with catch all routes?

[artemkovalyov]

@JohannesPertl, I solved it with reactive variables updating the route change. Without reactivity, the loading will happen only once on the page load.
Something like:

export let data: PageData;
  $: post = data.post;

[japherwocky]

I think a clean way to solve this is to make the current URL a writable store, then if your component isn't mounting, you have a clean spot to subscribe, with an interface you're probably already using.