Ability to override load or use before/after hooks

One of the most common requests in Sapper is a way to alter fetch or otherwise affect the load calls

Is your feature request related to a problem? Please describe.

• Distributed tracing - add a header to every request to trace requests from frontend all the way to datastore (requested by @adamb on Discord. difficulty setting up honeycomb.io also mentioned in https://github.com/sveltejs/sapper/issues/751)
• Using an internal hostname on the server-side (that’s what I want this for. my api server is written in another language)
• Using fetch in setup - e.g. to setup Apollo client (https://github.com/sveltejs/sapper/issues/1243 https://github.com/sveltejs/sapper/issues/751)
• Specifying a base URL (https://github.com/sveltejs/sapper/issues/489)
• Using a UNIX socket for AWS Lambda (https://github.com/sveltejs/sapper/issues/356)
• Ability to wrap fetch (https://github.com/sveltejs/sapper/issues/908)
• It currently requests only over HTTP. A user on Discord reported this wouldn’t work with his server than listens only on port 443
• Accessing Polka request on server (https://github.com/sveltejs/sapper/issues/1436)

Describe the solution you’d like

I originally sent https://github.com/sveltejs/sapper/pull/1336 though it might not solve all requests. E.g. there was a request to time how long load takes and I don’t think my solution would have made that easy to do, so it should probably be updated a bit to account for that.

How important is this feature to you?

This enables a large number of use cases for advanced users, so is fairly important.

[benmccann]

Loader context doesn’t seem like it solves the timing / metrics gathering use case. If you want to instrument how long your load calls take I’m not sure how you would do that using only loader context. If we want to punt on that I’m okay with that because loader context will solve the rest of the use cases. I just think that we need to be aware that we might need to add some type of additional instrumentation hooks in the future if we go with loader context now.

If we decide to go the loader context route - I didn’t like that in Rich’s example that I’d have to change every call to fetch to special_fetch throughout the codebase. I would prefer that SvelteKit’s implementation of fetch is provided in the context so that I can just override it with my own version

[Rich-Harris]

Can these cases be accommodated with loader context? i.e.

<!-- routes/$layout.svelte -->
<script context="module">
  export async function load({ fetch }) {
    return {
      context: {
        special_fetch = make_special(fetch);
      }
    };
  }
</script>

<!-- everywhere else -->
<script context="module">
  export async function load({ context }) {
    const stuff = await context.special_fetch('/stuff.json');
    // ...
  }
</script>