Remove `$page.stuff` and allow `load` functions to run concurrently

[Rich-Harris]

Describe the problem

I've come to the view that stuff (as it's currently designed) is a mistake, because it forces nested routes to load serially and because it prevents us from taking advantage of nested routes to stream responses (see #4910).

Ideally if we had a route like this...

<!-- src/routes/__layout.svelte -->
<script context="module">
  export async function load({ fetch }) {
    const res = await fetch('/one.json');
    const { one } = await res.json();

    return {
      props: { one }
    };
  }
</script>

<script>
  export let one;
</script>

<h1>{one}</h1>
<div>
  <slot/>
</div>

<!-- src/routes/foo/__layout.svelte -->
<script context="module">
  export async function load({ fetch }) {
    const res = await fetch('/two.json');
    const { two } = await res.json();

    return {
      props: { two }
    };
  }
</script>

<script>
  export let two;
</script>

<h2>{two}</h2>
<div>
  <slot/>
</div>

<!-- src/routes/foo/bar.svelte -->
<script context="module">
  export async function load({ fetch }) {
    const res = await fetch('/three.json');
    const { three } = await res.json();

    return {
      props: { three }
    };
  }
</script>

<script>
  export let three;
</script>

<p>{three}</p>

...then two things would happen. Firstly, we'd fetch one.json, two.json and three.json concurrently. Secondly, as soon as one.json returned, we'd flush

<h1>1</h1>
<div>

then as soon as two.json returned, we'd flush

<h2>2</h2>
<div>

then as soon as three.json returned, we'd flush the remainder:

<p>3</p>
</div>
</div>

At present, that's not possible. We run load functions in sequence for two reasons...

1. we want to bail out early if a layout errors or causes a redirect — subsequent load functions should not run
2. a nested route should be able to access any stuff that was returned from an rootward layout

...and we can't render anything until everything has loaded, because the root layout might make use of $page.stuff.

Ideally, we'd be able to solve all these problems without relying on a design that forces serial loading and delayed rendering.

Describe the proposed solution

Honestly, I haven't really figured this out yet — I'm really just trying to articulate the problem in hopes that a solution will present itself. But here's a straw man:

<script context="module">
  export async function load({ fetch, parent }) {
    const stuff = await parent(); // merges stuff from all parent layouts

    return {
      stuff: {
        b: stuff.a + 1
      },
      props: (stuff) => ({
        // because `props` is a function, rendering is
        // delayed until we have the final `stuff` object
        title: stuff.title
      })
    };
  }
</script>

<script>
  // this comes from the leaf component
  export let title;
</script>

<svelte:head>
  <title>{title}</title>
</svelte:head>

This doesn't feel totally intuitive, but it would speed up performance in the common case where load isn't blocked on its parents, and $page.stuff isn't used. And we would still have the ability to bail out if a parent load redirects (maybe await parent() throws an error for non-200 responses?)

Alternatives considered

I am all ears. (I'm also interested to know how people are using stuff)

Importance

would make my life easier

Additional Information

No response

[TheHadiAhmadi]

Hi @Rich-Harris
I use $page.stuff because this is useful to reduce boilerplate code.
I store some data (which comes from backend after successful login) in stuff that I need it in pages, for example apiKeys or enum types....

Describe the proposed solution

I think one solution is to make stuff a function (same as props in your example) which it's first parameter is merged stuff from parent layouts

export async function load({ fetch }) {
   const res = await fetch('/some-data').then(res => res.json())

    return {
      stuff: (stuff) => ({ // merged stuff from parent layouts
        b: stuff.a * res.multiplier,
        apiKey: res.apiKey
      }),
      props: (stuff) => ({ // final stuff object
        title: stuff.title
      })
    };
  }

[Zachiah]

Since svelte is already a compiler could you detect if $page.stuff depends on other $page.stuff and only then run them in sequence, otherwise just run them in parallel? I think for most cases it isn't very usefull to have $page.stuff depend on other $page.stuff.

From my view, the purpose of $page.stuff is to pass information up to the parent so if we have a structure

a/
    __layout.svelte
   [paramB]/
       __layout.svelte
       c/
           [paramC].svelte

the reason stuff is useful is that a/__layout.svelte doesn't have access to paramC right?
well a/b/c/[paramC.svelte] could probably have access paramB

so if a/__layout.svelte expects a title in $page.stuff
and a/[paramB]/__layout.svelte wanted to set it to ParamB = ${paramB}; ChildrenStuff: ${page.stuff.title}
then a/[paramB]/c/[paramC].svelte sets $page.stuff.title to ParamC: ${ParamC}

this would be a case where having the dependancy tree makes sense, however this could easily achieved without the dependancy tree simply by putting
ParamB = ${paramB}; ChildrenStuff: ParamC: ${ParamC} in a/[paramB]/c/[paramC].svelte

So the only way this wouldn't actually be rewritten without the nesting is if the parents fetch data and put it in params.stuff and you don't want to duplicate that fetching in a/[paramB]/c

I think one way to get around the series fetching in this case would be to just allow paramC to be accessed from a/[paramB]/__layout.svelte if it's available of course.

In a perfect world I guess only one fetch function would be run per route if this is an initial page load and the fetch function could determine how the parallelism is handled (Promise.all). Of course this isn't really possible because it doesn't make sense to reload the parent layout's data when ever the child changes which is why allowing paramC in the a/[paramB]/__layout.svelte has drawbacks. I guess again you could detect if children params are used inteligently and only reload the parent layout on children changes if it is necessary.

Let me know if I'm completely off here

[Mlocik97]

I typically pass some meta data through stuff from leafs components or better said pages to upper layouts, where I can use them. I even pass title of page through it.

[baukevanderlaan]

(I'm also interested to know how people are using stuff)

I use stuff only as a replacement for store to pass page meta data to __layout‘s that are higher up in the tree. Examples are breadcrumb components, SEO components and locale switchers.

I‘d still welcome a solution in which these things could be done in SSR with a simple store because store is such an elegant concept clientside and I think it’s a bit of a bummer that this is one of the few situations in the Svelte ecosystem where we as developers need to consciously change our paradigm when making an app work for SSR. I'm sure changing store to work on SSR and making it ready for streaming HTML is probably much harder than any other solution you come up with, but I still wanted to mention my sentiment now that stuff is up for debate. Feel free to mark as off-topic!

[stephane-vanraes]

I use stuff quite a lot in my current project, where the layout loads data from an api, that is common to all pages within that hierarchy and passes it on to the page. This reduces the number of API calls drastically and speeds the app up a lot.

This should still be possible to do in any new situation.

[plmrry]

Also using stuff a lot in a project.

To me it seems like the features of stuff can be broken up into:

1. A mechanism to pass loaded data from a __layout into nested routes
2. A convenient global store available via $page.stuff
3. "A mechanism for pages to pass data 'upward' to layouts." (from the docs)

It seems like 2 and 3 are mostly a convenience that could be done in user-land via a store + context, if I'm not missing something.

[endigma]

I'm using this for breadcrumbs atm, if this is going to be removed please document how to replace this "upwards push" functionality elsewhere? I'd rather not have to re-engineer this system because of a svelte update.

[Rich-Harris]

It seems like 2 and 3 are mostly a convenience that could be done in user-land via a store + context, if I'm not missing something.

Almost. It could be made to work in a client-side situation, but not during SSR — by the time you set the store value in the leaf, the layout would already have been rendered.

The only way to get that data to the layout in time for it to be SSR'd that I can see is a) with a SvelteKit-managed store (like $page.stuff) which can be populated before rendering happens, or b) to somehow get the data into the layout's props. The proposal above is one approach to option b:

// we can render this layout immediately, because it returns a props object
return {
  props: {
    answer: 42
  }
};

// we wait to render this layout until we have accumulated `stuff` from the child layouts and the leaf
return {
  props: (stuff) => ({
    answer: 42,
    breadcrumbs: stuff.breadcrumbs
  })
};

If you do the first option, you opt out of the ability to read child stuff when rendering layouts. If you do the second option, you opt out of the ability to render in phases. I think making this trade-off an explicit (and granular — per-layout, rather than per-app) option is the right approach — maximum performance by default, maximum flexibility by choice.

[coryvirok]

I only just recently understood what stuff could be used for. I'm now using it to pass data "up" to layouts but that definitely was a fairly unintuitive thing to learn.

Reading this thread, I'm reminded of how DOM events have 2 phases, bubbling and capture, to handle this type of logic where we want to push data up through the hierarchy of elements as well as annotate an event while it's being pushed down through the hierarchy.

Maybe there's similar event pattern we can make use of for stuff?

[Algoinde]

One thing to consider for nested layouts: if one of the layouts/endpoints errors out, do we throw the whole chain under the bus or cancel out only the layout stack at and below the error, and return (in SSR) only what succeeded?

[benmccann]

I like the idea of running the load functions concurrently unless one depends on another.

I think there might be alternatives to removing $page.stuff that are nearly as performant. Not being able to pass data upwards in pages seems like a severe restriction and would be a tough thing to lose. Hopefully we could get the benefit in other ways. If you think about the things that get sent to the server sooner by streaming, we could send it earlier or eliminate a lot of it in other ways. The layout contains a few things we could potentially stream:

• serialized data for hydration
• head contents
• HTML for the top part of the page (typically a logo, menu bar, etc.)

A lot of the serialized data for hydration could be dropped if we introduced something like partial hydration. This is obviously not something that would happen in the near future, but Svelte's always avoided taking API shortcuts and focused on the long-term.

In terms of head contents, the most valuable thing to stream is the external resources, so that the browser can request them earlier. This could be done by streaming Link headers (earlier discarded PR) or better yet with 103 early hints (which will ship with the next version of Chrome, but likely work only in adapter-node, adapter-deno, and other non-serverless platforms - discussion).

The HTML for the top of the page could only be sent if we truly supported streaming. The HTML itself is unlikely to be that large, but may link to larger resources like images. Those could potentially be handled in a similar way to the head contents - though we'd probably want to let the user select which should be preloaded (draft PR for font preloading)

The transformPage API would probably need to change even with these other optimizations (#4910)

[coryvirok]

What if Layouts were able to receive all of the props of their children as slot props? This would remove the need for stuff and would rely on slots to pass data up and down from page to layout or from layout to layout.

<!-- __layout.svelte -->
<script>

  // These come from whatever page is rendered in <slot/>
  // and are also available as slot props to a parent layout
  export let user
  export let navLinks

  // These are passed down to pages
  let var1 = 'some data from the layout'
  let var2 = 42
</script>

<header>
  Hello {user.name}
</header
<nav>
  {#each navLinks as navLink}
    <a href={navLink.href}>{navLink.text}</a>
  {/each}
</nav>

<main>
  <!-- 
      user and navLinks are passed "up" to the layout from the page. 
      var1 and var2 are passed "down" to the page from the layout.
  -->
  <slot {bind:user} {bind:navLinks} {var1} {var2} />
</main>

[Algoinde]

So not sure if this is related, but it seems like it is. I'm trying to do a new project and ran into a problem with how things currently are: nested layouts which have a load function rerun every time you navigate to a lateral route instead of just keeping the data.

Here's the example layout:

Each level of the route structure has a __layout in it that contains the markup and the load to populate that markup with data using API requests.

Say, you were on /profile/2/foo and navigate to /profile/2/bar using href. This requests /profile, then /profile/2, and then renders the /profile/2/bar, every time the path is changed.

I'm very new to SvelteKit so maybe there is a way to make this work as things currently stand? If not, it should definitely be factored in.