option to render layout before page is loaded

[JacobZwang]

Describe the problem

When building application-like websites, users expect instant feedback when changing pages, even if the page's content isn't ready yet. It's confusing to a user when they click a button and nothing happens, then a second later the page changes. Loading indicators help but are still not ideal.

Describe the proposed solution

Provide an option that will allow a +layout.svelte file to be rendered before the +page.svelte is ready. For example, say clicking a button opens up a page that is a modal. We place the markup for the modal inside the +layout.svelte file and the content inside the +page.svelte file. As soon as the user clicks, we can render an empty modal. Then once the page is ready, the content will appear. While the page is loading, we can utilize the slot default as a loading page or skeleton UI.

<script>
	// declare that this layout will be rendered to the DOM before the page is loaded
	export const optimistic = true;
</script>

<div class="modal">
	<slot>
		<p>skeleton ui or loading indicator</p>
	</slot>
</div>

Alternatives considered

• Using #await block so that surrounding markup is not dependent on data: This destroys SSR and sveltekit's entire data model.
• Having a dedicated +loading.svelte file: Seems like unnecessary complexity when it can be done without it. If for some reason someone requires separate default and placeholder page contents they can always use the $navigating store to switch between them.

Importance

would make my life easier

Additional Information

• If the +layout.svelte also relies on data we can still render it as soon as its own data is ready.
• This probably shouldn't affect SSR in any way. When we render on the server, we probably want to wait until the entire page is loaded before responding to the client. If we didn't, it would defeat the purpose of SSR in the first place.
• As far as I know, this doesn't break any existing functionality.

[dummdidumm]

The problem is that you can use $page.data anywhere on the page and if you access data from the page in a layout that would break. Something like +loading.svelte seems like a safer, more consistent solution to me.

[JacobZwang]

That's true, but your layout must already accommodate this lack of data because your layout will still be rendered when there is an error. If error pages inherit layouts then a loading page must inherit layouts as well. I am not against +loading.svelte but I don't think that it solves the issue you present.

[GuillermoCasanova]

+1

Not sure if related, but when clicking on links there's a slight lag before the page moves away on my end: I currently have my internal links trigger a page fade out and then a page fade in of the new page (via ready = false onDestroy() ready = true onMount()), but there's still a slight lag on click which makes it feel less snappier. The onDestroy() doesn't get called immediately it seems, only about 200-400mms later?

[dummdidumm]

that sounds unrelated. the animation slows this down because the page fades out before being destroyed (which you notice by the delayed onDestroy)

[GuillermoCasanova]

I don't think the animation is an issue here.

I'm attaching a video where there is no animation between pages. What it shows: clicking a link takes a second too long for anything to change for the user, which doesn't feel snappy/performant. Could it be the page.js load() function is running before the page changes and only once data is loaded does it trigger a chance? I'd hope not, as it's best if the page changes or triggers a fade out immediately on click and then shows the new page to the user. This is expected behavior of quick sites/SPAs/html-only sites.

EXAMPLE:
https://user-images.githubusercontent.com/9218601/195445798-580e2b3b-30c6-48b3-b8ad-b2fee3ddf8ed.mp4

And for when I have the animation on: a click on a link doesn't trigger fade out immediately on click, it takes a second too long, like @JacobZwang describes, then triggers the animation and then shows the page.

Seems like if I want something to happen immediately I'd have to cover the page with a separate "loading screen" element, trigger a fade in on click and then fade it out once the other page has loaded?

[dummdidumm]

The page redirect happens after your load resolved, so if you have something slow in there, it's noticeable. This feature request here would help you mitigate that by having some kind of noticeable page change earlier. For now, if you know it always takes some time, you could do some kind of loading spinner or else using the navigating store from $app/navigation, to show that spinner on that site when a navigation is in progress.

[GuillermoCasanova]

@dummdidumm Understood. I ended up doing exactly that and working with navigating store and show/hiding an overlay -- worked like a charm for perceived performance.

Ditto that the feature request would be cool to have then for more app-like stuff. Thank you!

[dummdidumm]

For inspiration: https://reactrouter.com/en/main/guides/deferred

[Rich-Harris]

I think this needs to be a +loading.svelte file, rather than fallback <slot /> content, for two reasons:

• Granularity. If I want different loading screens for each of /a, /b and /c it's easier to achieve that with src/routes/a/+loading.svelte etc than a big {#if ...} block in src/routes/+layout.svelte. (You could get an equivalent result by adding src/routes/a/+layout.svelte and only putting <slot>loading</slot> inside it, but that's less clear and more roundabout)
• SvelteKit needs to know which nodes have loading screens. If you navigate from /a to /b, we can't just remove the slotted content from src/routes/+layout.svelte unless we know that it has fallback content. We could determine that, but it would be finicky, especially when dealing with funky preprocessors. +loading.svelte is unambiguous

[JacobZwang]

@Rich-Harris Just throwing another idea out there. If we could define default data and then add a store to know when page data is loading, we could show our UI before the data arrived. I believe SvelteKit already has this functionality when using invalidate() to update the data on the page?

<script>
	import { loading } from '$app/stores';

	export let data = {
		users: []
                // or maybe even something like:
                // users: localStorage.getItem('users')
	};
</script>

<h1>Users</h1>
{#each data.users as user}
	<div>
		{user.name}
	</div>
{:else}
	{#if $loading}
		loading users...
	{:else}
		no users found
	{/if}
{/each}

I suppose this could also be solved using a service worker to return default or cached data immediately, then when invalidate is called with some extra identifier, the service worker queries the data?

Semi-related, I don't think SvelteKit has a way of loading "more" data. For instance loading 10 users, then loading 10 more users. Our only option would be to make those requests separately and store their results separately from page data.

[swyxio]

will point out that nextjs (which people will invariably compare sveltekit to) has loading.js https://app-dir.vercel.app/loading

it appears to be the only major feature we lack in comparison