Data flow and execution of universal load functions

[chriswep]

I'm hitting several issues/questions concerning what i can expect from export let data: PageData in +[page|layout].svelte files.

1. data that i return from +layout.server.ts is not available in the type in +page.svelte in the same directory (via import { PageData} from './$types'). However it seems to be available on runtime. Is this a bug in the generation of the type information or is this intended behaviour (i.e. you have to specifically forward layout load data in +page.server.ts)

2. i hit situations when something that is returned from the server load method is undefined on the client. from what i see this is related to using goto together with invalidateAll. Data is updated eventually however i see the error on the server console, so it's probably related to ssr. in my case the the load function in +layout.server.ts returns something that can't be undefined however after goto on the client, the corresponding +layout.svelte triggers an undefined error when accessing data.something.property. Can't help but think that this is a bug, either in the server rendering/preload code or in the generate types, since they don't include undefined (thus not causing an error when not guarding for undefined in the IDE).

[geoffrich]

1. Data returned from +layout.server.ts should be available in +page.svelte, so it's probably a type generation bug -- it's worth opening an issue if you can create a repro.

Data returned from layout load functions is available to child +layout.svelte components and the +page.svelte component as well as the layout that it 'belongs' to.

Layout load docs

2. Sounds like that might be a bug, though hard to say for sure without seeing the code. Also probably good to open an issue if you can create a minimal repro.

[chriswep]

one thing i learned since is the concept of a universal loading function "shadowing" the server load function, as mentioned by @Rich-Harris here: #7107 (comment)

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).

i tried to read the docs about loading function very carefully, however the "shadowing" concept was new to me, i.e. i didn't see that mentioned anywhere. also not in the place where it shortly mentions the possibility of having +layout.server.js+ and +layout.js simultaneously.

Especially your quote

Data returned from layout load functions is available to child +layout.svelte components and the +page.svelte component as well as the layout that it 'belongs' to.

doesn't seem to be true without that caveat.

Adding a return data to my +layout.ts in that case did at least solve on part of the issues i had. Maybe that helps someone else.

[geoffrich]

Okay, the docs could probably be more clear in this case. It's more common to have either a +layout.ts OR a +layout.server.ts, not both. If you do have both, then the return value of the +layout.server.ts load is passed to the data property of the +layout.ts load. The data your page receives is then based on the output of +layout.ts.

This is gestured at in this section of the docs, but agree it could be clearer/use more consistent terminology:

Universal load functions are called with a LoadEvent, which has a data property. If you have load functions in both +page.js and +page.server.js (or +layout.js and +layout.server.js), the return value of the server load function is the data property of the universal load function's argument.

So if you have this layout server load:

// +layout.server.ts
const load = () => {
  return { numbers: [1, 2, 3] }
}

and this layout universal load:

// +layout.ts
const load = () => {
  return { vowels: ['a', 'e', 'i'] }
}

you will only have numbers in your data if you explicitly forward it from your universal load, like this:

// +layout.ts
const load = ({ data }) => {
  return { numbers: data.numbers,  vowels: ['a', 'e', 'i'] }
}

Depending on your use case, you might not need the universal load at all, and could just use the server load. But there are cases where you need both.

[chriswep]

Depending on your use case, you might not need the universal load at all, and could just use the server load. But there are cases where you need both.

generally speaking, if i need to guard a route with a condition that relates to state that is outside of the scope of the server - then i would (need to) use the universal loading function for that right? Or do i mis-use/understand the loading function here and there is another mechanic for that?

Also, i have SSR disabled - am i right to assume that universal loading functions only run on the client then? How would that work with SSR enabled? Would the universal loading function be delegated to the client if the server sees that it contains code like if(browser) ...? Or would the function be run only on the server on the initial page render (skipping the browser code) - or both on server and client?

[dummdidumm]

• with SSR disabled, universal load functions only run on the client
• with SSR enabled, universal load function run on the server on initial page hit, and are then rerun during hydration. Then they run on the client for all subsequent navigations

[chriswep]

thanks! i think after one week digging into this i now get a feeling for how things are structured and why. however simple clarifications like discussed in this thread would have gone a long way towards catching core ideas early on and translate them into a better project structure from the start. instead i didn't feel in control of what is happening behind the scenes - of course that's true for every framework to some extent, however i haven't quite experience that as much as with svelte kit at the beginning. just a feedback from someone getting into svelte kit from scratch.

somehow related to this is the question about safely managing client side state as e.g. discussed here: #4339 which carries a similar sentiment in the comments.

[dummdidumm]

#8547 attempts to solve this, specifically the new "when does a load function run" section