Replace the current implementation of load

[grischaerbe]

Hi,

First of all: Svelte and SvelteKit is great, I'm coming from Vue/Nuxt and React/Next and Svelte feels like a revelation in many parts. There are some things I'm not 100% happy with, and this discussion is about one of them.

To make senseful use of the current implementation of loading data for prerendering pages you have to use the custom fetch implementation to fetch data that is provided to the method on both server- and clientside.
The mechanics are somewhat "simple": this custom fetch implementation "caches" data on the server side and ships it along the rendered html, ready for the custom fetch implementation on the client side to pick it up and use it without actually making an API roundtrip. Clever!

There are however some pitfalls to that approach.

Caching

TLDR; If fetch is not called server side, the client does not receive and data for hydration, resulting in calling the load function twice for every request.

⚠️ Be aware that code in this post is copy-pasted, mixed and mashed together at "runtime" and may be incorrect.

Usually my stack looks like this: I'm setting up a GraphQL API on the server side and I'm using Typescript along with GQL code generation on the client side to achieve a maximum of end-to-end type safety. This for me has proven to be a pretty good solution to produce error-free code that is easily maintainable and easy to reason about even after some time went by.
For simple GraphQL operations I'm using graphql-request which has the option to supply a custom fetch implementation.

Problem

In a current project (which also happens to be the first full SvelteKit project) I'd like to add a caching layer somewhere along the data flow. For some past projects I wrote a simple but type-safe caching library and it's working great in conjunction with Nuxt.JS's asyncData and fetch.

A NuxtJS example of graphql-request with a cache layer in between would look something like this:

async asyncData({ params }: Context) {
  try {
    const { slug } = params
    
    const pageData = await cache.cacheable(
      () => gqlClient.queryPage({ slug }),
      Cacheables.key('page', slug),
      { fetchPolicy: 'stale-while-revalidate' }
    )

    return {
      pageData,
    }
  } catch (e) {
    // Error handling
  }
}

The first thing to note is that the complexity of injecting a custom fetch implementation is missing here, but the important difference is that caching works as expected. When NuxtJS is in SSR mode and and you hit that page without navigating to it (= it's actually prerendering on the server), the server is able to use the cache layer provided by cache.cacheable to fetch the data and ships it along with the prerendered page, ready for NuxtJS to hydrate the page without calling asyncData and thereby making an API request. The client now holds it's own cache and subsequently navigating to a page implementing that caching technique would hit the API and cache the result.

Note also that this is NuxtJS 2 with the options API of vuejs, the "type-safety experience" is lacking quite a lot. With NuxtJS 3 and its useAsyncData hook, this probably got way better also.

Now let's look at this example in SvelteLand:

export const load: Load = async ({ fetch, page }) => {
  try {
    const { slug } = page.params
    const client = getGqlClient(fetch)
    const pageData = await cache.cacheable(
      () =>  client.QueryPage({ slug }),
      Cacheables.key('page', slug),
      { cachePolicy: 'stale-while-revalidate' }
    )

    return {
      props: {
        pageData
      },
      status: 200
    }
  } catch (error) {
    return {
      status: 404,
      error: 'Page not found'
    }
  }
}

The first thing to note is the added complexity of the injection of a custom fetch implementation. It's a detail but missing it is something that TypeScript can't check since fetch is monkey patched.
Let's look at how the caching layer would work in this example in SSR mode:
If this page is hit the first time, no cache value would be present and the API would be hit, resulting in the custom fetch implementation to be used to fetch data. Since this implementation caches the result to ship it to the client, everything works as expected.
Let's say there's another request to that page and the cache jumps in to provide the data. This time the custom fetch is not called, the page is prerendered with the cached data. The client receives a prerendered page but lacks the API data for hydration. It's making another API roundtrip.
The rest of the application runs as expected since subsequent calls from the client side maintain their own cache.

I thought about this for a while and tried to come up with a workaround.

Workaround

SvelteKit offers the creation of API endpoints. To use a cache layer, I created an endpoint /api/v1/page.json.ts like this:

export const get: RequestHandler = async ({  params }) => {
  const { slug } = params

  const data = await cache.cacheable(
    () => gqlServerClient.QueryPage({ slug }),
    Cacheables.key(`page-${slug}`),
    cacheableOptions
  )

  return {
    body: {
      data
    }
  }
}

and a load proxy like this:

const isString = (x: unknown): x is string => typeof x === 'string'

type LoadFnInput = [fetch: FetchFn, url: string]

type LoadFn<T extends unknown> = (...args: LoadFnInput) => Promise<{ props: T }>

export type LoadFnProps<T extends unknown> = Await<ReturnType<LoadFn<T>>>['props']

const fetchJson = async <T>(fetch: typeof fetch, url: string) => {
  const res = await fetch(url)
  const d = (await res.json()) as { data?: T; errors?: Array<{ message: string }> }
  if (d.errors || !d.data) {
    if (d.errors) {
      throw new Error(d.errors.map((e) => e.message).join('\n'))
    } else {
      throw new Error('An unknown error occured.')
    }
  }
  return d.data
}

export const loadFn = async <T>(fetch: typeof fetch, url: string): Promise<LoadOutput<T>> => {
  try {
    const data = await fetchJson<T>(fetch, url)
    return {
      props: data
    }
  } catch (error: unknown) {
    return {
      error: isString(error) ? error : 'An unknown error occured.'
    }
  }
}

to use it in a page like this:

export const load: Load = async ({ page, fetch }) => await loadFn(fetch, `/api/${page.params.slug}.json`)

⚠️ This is far from production ready, more like a POC, probably not complete and hastily put together. Better not use it.

Now the caching on the server works as expected with the additional benefit that subsequent calls from the client side also hit the server side cache. But it adds a whole lot complexity (which I think stands in quite a contrast to the rest of Sveltes ideals and conventions) and subsequent API calls which end up not hitting the server side cache actually travel quite far: client → server → API → server → client.

Also – and this is what actually stops me from following this approach – it means a lot more type-casting (fetch() as SomeType – maybe it isn't of that type?). You would have to cast the load function's fetch response (with all its await json() => { data?: any; errors?: Array<{ message: string }> goodies 😒) and on the component instance property then. NuxtJS 3 on the other hand with its useAsyncData hook needs no type-casting at all.

Solution

This is where it gets less technical and more hypothetical since I didn't really delve into SvelteKits codebase yet:

For a starter I propose getting rid of the custom fetch implementation and caching the result of the whole load function instead. This should even be backwards compatible.

But this still requires maintaining proper type casting on the component instance property and so I'd like to go one step further and suggest to get inspired by the NuxtJS implementation of a hook-based solution that sits right in a component instance:

<script lang="ts">
  let pageData = useLoad(async ({ page }) => {
    const { slug } = page.params
    return await client.QueryPage({ slug })
  })

  onSomeEvent(() => {
    pageData.reload()
  })
</script>

<h1>{$pageData.title}</h1>
<button on:click={pageData.reload}>Reload</button>

useLoad would return a Svelte store with an additional method reload that can be used to rerun the provided callback at any time. Since it's a store, you would be able to subscribe to it from anywhere in your application. The store would be type-safe without casting it, which would be so great. Note that this would not replace the API endpoints functionality SvelteKit provides.

It's a feature I'm dearly missing in SvelteKit and I'd like to hear your opinion about it. I'm not a pro in contributing to OSS, but I can try my best to implement this when the community thinks it would be a good idea.

Also sorry for the excessiveness of this post, it got a little bit out of hand. Have a nice weekend ✌️

[gterras]

Very interesting read thanks,

warning This is far from production ready, more like a POC, probably not complete and hastily put together. Better not use it.

One year later do you have a battle-tested implementation to share?

[benmccann]

@grischaerbe I just stumbled across this old post of yours. I know it's a bit delayed, but I thought I'd see if I could offer some suggestions

The first thing to note is the added complexity of the injection of a custom fetch implementation.

Rather than putting the cache in each individual load function, could you move it inside handleFetch? https://kit.svelte.dev/docs/hooks#server-hooks-handlefetch

The client receives a prerendered page but lacks the API data for hydration. It's making another API roundtrip.

This option may not have existed when you originally posted, but it sounds like you're looking to mark the load function as prerenderable: https://kit.svelte.dev/docs/page-options#prerender-prerendering-server-routes

[205g0]

Thanks for sharing. Could #10481 be related?

[FeldrinH]

For a starter I propose getting rid of the custom fetch implementation and caching the result of the whole load function instead. This should even be backwards compatible.

For future readers it should be noted that this is definitely not backwards compatible, because currently load is explicitly allowed to return things that can't be serialized (e.g. functions) and the cached result of load needs to be serialized to send it from the server to the client on initial page load with SSR.