Programmatic render API

[Rich-Harris]

This isn't a fleshed out thought — I'm thinking it as I type it — but reading #16368 made something click for me. At the moment the way to add custom bits and bobs to a response in SvelteKit is to use handle, where the resolve function defaults to 'what the framework was going to do anyway':

export function handle({ event, resolve }) {
  return resolve(event);
}

If you want a stack of middlewares, you use sequence, in which case resolve means 'the next handler after mine':

import { sequence } from '@sveltejs/kit/hooks';

export const handle = sequence(
  ({ event, resolve }) => {
    console.log('first');
    return resolve(event); // calls the second handler
  },
  ({ event, resolve }) => {
    console.log('second');
    return resolve(event); // calls the built-in handler
  }
);

So far so whatever. It starts to get a little confusing when your needs become more involved, as shown in the sequence docs — suddenly you have to learn things like 'transforms are applied in reverse order' and that some options like preload can only be invoked once, by the first handler that happens to define them.

It's also just a little... I don't know, ugly.

Meanwhile — and this will seem totally disconnected, bear with me — we have occasionally wondered about having a way to render pages programmatically, particularly for the sake of service workers, but maybe it would be useful in other contexts (particularly old-fashioned form submissions, where if you're not using page actions or remote functions for whatever reason, you can't respond with a rendered page — the best you can do is redirect).

So what if we exposed something like respond?

import { defineMiddleware } from '@sveltejs/kit/hooks';
import { resolveEvent, respond } from '$app/router';

export const middleware = defineMiddleware(
  (request, next) => {
    const url = new URL(request.url);

    // just the raw request
    if (url.pathname === '/potato') {
      return new Response('potato');
    }

    // respond to a synthetic request
    if (url.pathname === '/synthetic') {
      return respond(new Request(`${url.origin}/hello`));
    }

    // in case you need to resolve an event
    const event = resolveEvent(request);
    if (event.url.pathname.startsWith('/skip-middlewares-for-some-reason')) {
      return respond(request);
    }

    return next(request);
  },
  async (request, next) => {
    const t = Date.now();
    const response = await next(request); // `next` here is equivalent to `respond`
    console.log(`[${request.method}] ${new URL(request.url).pathname} - ${Date.now() - t}ms`);

    return response;
  }
);

You could also use $app/router in e.g. +server.ts handlers, and ideally in service workers (though that's a little trickier since you would still need to go back to the server sometimes to fulfil a request; you couldn't ship private env vars or database clients to your service worker but you could ship e.g. a remote function that didn't use anything sensitive).

Like I say, not fleshed out at all. I haven't suggested a good pattern for passing context between middlewares, for example. And now that I've written it, clearly more involved than something we want to block 3.0 on. But maybe there's something there?