+layout.server.ts load re-runs on every navigation

Describe the bug

Layout load function runs on every navigation

Reproduction

Log to console when layout load function is executed and it happens on every navigation.

import type { LayoutServerLoad } from './$types'

export const load: LayoutServerLoad = async ({ }) => {
  console.log('load /layout')

  return {
    name: 'My Site'
  }
}

Logs

No response

System Info

npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.64 
    @sveltejs/kit: next => 1.0.0-next.415 
    svelte: ^3.44.0 => 3.49.0 
    vite: ^3.0.0 => 3.0.8

Severity

blocking an upgrade

Additional Information

No response

[Rich-Harris]

An argument against posting data back to the server is that we may want to introduce the ability to send non-JSONable values from the server:

// +layout.server.js
export function load() {
  const map = new Map();
  map.set(map, map);

  return {
    map
  };
}

It’s likely that we’d achieve that with https://github.com/rich-harris/devalue, which is only safe to use when sending data from the server to the client, not the other way around.

[Rich-Harris]

This Remix issue asking for loaders to use superjson has 37 👍 votes — it’s definitely not an unheard of requirement to include things like Date objects etc.

Another case that JSON can’t handle is this, if the referential equality matters (which it would in a <select bind:value> for example):

export function load() {
  const options = [
    { flavour: 'chocolate' },
    { flavour: 'strawberry' },
    { flavour: 'banana' }
  ];

  const selected = options[0];

  return { options, selected };
}

We don’t plan on using superjson, because devalue is faster, produces smaller output, and doesn’t force you to add a not-that-tiny client to deserialize on the client. But it does mean the data can only safely go one way. (Though we decided that sending data back to the server to simulate statefulness is a terrible idea anyway.)

(Re cache aware server push — the logic is on the wrong side. The server doesn’t need to know what the client has, because the client is going to tell it. All the server has to do is tell the client ‘this blob of data will be invalidated if params.foo changes’ or whatever.)