True equivalent to `getStaticProps`?

Is your feature request related to a problem? Please describe. The load function currently runs on both the server and the client, which means that you can’t do anything that should be left to the server in it (eg: fetching data for static rendering). Instead you have to create an endpoint route and then fetch this as json in your load, which is a lot of boilerplate and bloat for a very common use-case.

Even with a JSON endpoint to do heavy lifting, every route on the client still has to make that request and wait for it to resolve before rendering when the page has already prerendered.

Describe the solution you’d like A way to opt out of running load on the client, so it provides props either only for SSR or prerendering. I know this was previously considered for sapper, and I’d love to see it reach sveltekit. Either as an option on load, or a new function with a similar signature, like how NextJS has getStaticProps, etc.

Describe alternatives you’ve considered The currently recommended pattern for this use-case is creating JSON endpoints for every single route that needs data, which for a static site generator type context with a CMS is every route. Not only is that a lot of boilerplate and crappy DX, but it has unnecessary performance implications during routing outlined above.

There are other workarounds to help reduce the issue — prefetching as much as possible, using maxage to cache already visited routes — but none actually fix the problem that shouldn’t exist in the first place.

How important is this feature to you? Unless I’m missing something this is a big drawback to using sveltekit as an SSG, which was my main use-case over the likes of NextJS and Gatsby.

[madeleineostoja]

Oookay that makes much more sense. I didn’t realise that svelte’s fetch implementation would hydrate and re-use data sent from the server. I think this could use some clarification in the docs, I thought svelte’s fetch was just a utility method for an isomorphic fetch.

I am using sveltekit’s fetch implementation to fetch local .json.ts paths, but I’d only tested it in preview and dev since I’m still playing around with the best way to fetch data in my setup. After more testing I can see that it’s working as intended, rehydrating almost instantly. So now I’ve just re-written my CMS integration to use a provided fetcher from load rather than the SDK I previously was using, making this mostly a non-issue for me personally. I mean I still don’t need to call load for every fully static prerendered route in my site, but the perf impact of that is now negligible.

I still think an SSR-only load method would be a DX improvement, but sounds like I just misunderstood how load actually works.

Happy to close this, unless the docs should be clarified at all.

[benmccann]

Even with a JSON endpoint to do heavy lifting, every route on the client still has to make that request and wait for it to resolve before rendering when the page has already prerendered.

I’m not sure about this statement. I think that it’s either not true or I’m misunderstanding what you’re saying. The reason SvelteKit reruns this logic on the client is that it’s doing hydration. If you’re not familiar with that term check out these docs I’ve proposed adding in one of the pending PRs. So, SvelteKit fetches data in load on the server and then it reruns load on the client to hydrate the client, but it does not refetch the data. The data has been sent down with the initial page and Svelte uses it instead of refetching it. Note that this logic is built into SvelteKit’s fetch implementation so the one case this might not be true is if you’re getting data without using fetch somehow. In that case I’d first recommend trying to use fetch in whatever data fetching you’re doing