[feat] pass data from `locals` to `load`

[benmccann]

Describe the problem

My site queries an external API with the following pattern:

• handle extracts user ID from cookie
• +layout.svelte fetches user by user ID
• +page.svelte fetches profile by user ID

These fetches previously happened in parallel. With $session removed I have no way to write this code without introducing a waterfall

Describe the proposed solution

I'm happy with any solution folks can think of that solves this problem

I think we could potentially solve this as part of #7105

Alternatives considered

No response

Importance

i cannot use SvelteKit in a performant manner without it

Additional Information

No response

[pilcrowonpaper]

Duplicate of #6714, no?

[ZetiMente]

I also have this same problem using Supabase.

[dummdidumm]

Copying my Discord-thoughts into here:

What became clear to me that getSession was used for multiple things at once.

1. pass data from server to client load functions
2. make cross-cutting data easily available across all client load functions
3. trigger a load function to rerun when data changes (e.g. $session.user = null)
4. a convenient writable store that is somewhat global

Because it had so many use cases in once, it became somewhat confusing what runs when, because people may only think about 4 and then wonder about 3. So I think removing it in its form was correct, but we need some features that bring back the mentioned points in a easy-to-use way. Right now we have this situation:

1. pass data -> can do this now by having a +layout.server.js and passing whatever you want to the client
2. cross-cutting data -> use await parent() -> this introduces a waterfall because you can't tell "hey I'm only interested in the data from parent X, don't wait on the 3 other layout loads after that". Something like locals for the client side would help with this.
3. trigger rerun -> there's nothing built-in for this right now. Rich shared a pattern somewhere about creating a custom state which triggers a unique invalidate function under the hood. Maybe it's enough to make this a blessed pattern and/or tidy it up a little and provide a wrapper around it.
4. convenient writable store -> again, nothing built-in, this would be [feat] helper for creating stores #7105
   3+4. It's not clear to me how to achieve a combination of these two in a nice API. session made it possible because it was on both sides.

--> I feel like we need to add recipes and/or APIs to ease this

[dummdidumm]

Adding this link which gives some more insights about the needs in context of an auth library: https://discord.com/channels/457912077277855764/1030455826701369405

[j4w8n]

As far as the cross-cutting waterfall when using await parent(): if this function could take in a depends()-like custom identifier, would that resolve the water fall issue? This may be difficult, if not impossible, to implement. Just throwing out an idea.

In the below code, the src/routes/some/where/+page.js load function would only wait on parent load functions which declared the same custom identifier. Doing something like this would still have to allow all other child load functions of src/routes/+layout.server.js to inherit it's returned data. This solution is more like a parent data filter for the src/routes/some/where/+page.js load function.

You'd probably want to allow the +page.js load function to pull in from multiple parents this way, not just one.

/* src/routes/+layout.server.js */

/** @type {import('./$types').LayoutServerLoad} */
export function load({ child }) {
  child('custom:session')
  return { user: { id: 1 } };
}

/* src/routes/some/where/+page.js */

/** @type {import('./$types').PageLoad} */
export function load({ parent }) {
  const { user } = await parent('custom:session')
}

Or I suppose if you could pass in the paths to the parent files, then you wouldn't need to declarechild() in the parents.

/* src/routes/some/where/+page.js */

/** @type {import('./$types').PageLoad} */
export function load({ parent }) {
  const { user } = await parent('+layout.server.js')
  const { where } = await parent('some/+layout.js')
}

Or maybe multiple parents could be merged.

/* src/routes/some/where/+page.js */

/** @type {import('./$types').PageLoad} */
export function load({ parent }) {
  const { data } = await parent(
    '+layout.server.js',
    'some/+layout.server.js'
  )
  console.log(data.user, data.where)
}

[pilcrowonpaper]

Why was $session a store? I think just making it a normal object (or readonly object) would make the role of getSession() clear, which (I think) is to pass data directly from hooks to the client (including load functions). Maybe renaming it to serverSession would make it more clear.

[david-plugge]

What about #6183, that would also solve this right?
And it also makes it possible to only load the necessary data for the sub routes and not the whole app (minor issue, but still).

Something like this:

// src/routes/(app)/+layout.server.ts
export const blocking = true;

export const load: LayoutServerLoad = ({ locals }) => {
	return { user: locals.user }
}

// src/routes/+page.ts
export const load: PageLoad = ({ data }) => {
	// 'user' is undefined here
	console.log(data.user);
}

// src/routes/(app)/account/+page.server.ts
export const load: PageServerLoad = ({ data }) => {
	// 'user' is merged into all subsequent loads
	console.log(data.user);
}
// src/routes/(app)/account/+page.ts
export const load: PageLoad = ({ data }) => {
	// 'user' is merged into all subsequent loads
	console.log(data.user);
}

If you don´t have a server the same thing applies when using +layout.ts

[dummdidumm]

The idea of more fine-grained await parent() is a interesting idea. Another way could be to optionally pass parent a function to tell it what to wait for, or a list of top level keys.

export function load({ parent }) {
  const user = await parent(['user']); // resolves as soon as `user` resolves, only reruns when `user` changes
}

Edit: They key-version is probably not possible. How would the function know that the user key that is returned by some upper load function is actually the last with that key? If there are two load functions returning user, we need to wait for the later load function in the chain, but we don't know that there's something coming later on.

[antony]

Just to add a case to @dummdidumm's list that we ran into today after upgradng, we have the following use-case:

We have a set of data which is passed via query string. It's configuration for an application - things like theme colours, etc.

On first load we grab all this data from the query string and lump it into a config object. We previously used session for this, and the session hook.

When we upgraded SvelteKit to a more recent version, we found that the recommended path of placing things into a +layout.server.js file and then accessing it in pages works up until the first navigation, whereby the url changes, triggering a reload, which then wipes out the configuration data!

Having the url change as a way to invalidate the load function is the primary issue here.

Our workaround is storing the data in a session cookie and then checking for it's presence first, but it certainly feels worse than the original method.

[Rich-Harris]

There's a fundamental mismatch between event.locals and client-side state — the server is stateless (i.e. event.locals is recreated for each request), but client-side state persists until you get rid of it. This was a source of particularly insidious bugs with $session (svelte.dev itself was affected by #4426 for a very long time before we noticed). We must be careful not to reintroduce that by another name.

Obviously you don't want to refresh infrequently-changing client-side state on every interaction; that would defeat the object of running the app in the browser in the first place. But returning a userid from the root +layout.server.js is a good compromise, since there are existing approaches for invalidating that state (and in the common case, where a cookie changes as a result of a POST to a /login or /logout action or similar, invalidation is automatic unless you opt out). The userid is then available to the entire app (unless the root +layout.server.js is shadowed by a root +layout.js that doesn't also return userid, of course).

In the case where you're using server-only load functions, there's no waterfall, because the functions all have access to event.locals.

So one question is 'how do we prevent a waterfall with shared load functions?', e.g. because you're using an external API server. A more granular version of parent() wouldn't solve @benmccann's issue, because there's already only one parent of the +page.js load function. We'd have to have a more granular version of parent() and we'd have to add a route group so that we could avoid doing any work in the root layout:

src/routes/
├ (main)/
│ ├ profile/
│ │ └ +page.js      # const { userid } = await parent('/'); return { profile: getProfile(userid) };
│ └ +layout.js      # const { userid } = await parent('/'); return { user: getUser(userid) };
└ +layout.server.js # return { userid: getUserId(cookies.get('sessionid')) }

This is obviously somewhat cumbersome. So another question is 'how problematic is this in practice?'.

Here, I'm going to make some assumptions. I'm going to assume that the API server is close to the app server, such that fetch during SSR is relatively cheap (if not, there are bigger problems!). I'm also going to assume that the root layout isn't going to be invalidated frequently (i.e. it only gets invalidated after things like logging in or out, not on each navigation). If those assumptions hold true, then in the case where you hit a page involving a waterfall directly, it's a cheap waterfall. In the case where you hit a different page, then navigate client-side to /profile, there is no waterfall because the root layout data remains valid.

Given all that, I'm wondering about the extent to which this is a real problem that we need to solve versus a micro-optimisation that comes with some downsides.

[Rich-Harris]

(In particular, whether it's something we need to address pre-1.0)