Official way to pass state from endpoint to fallthrough page routes

Is your feature request related to a problem? Please describe. I’m implementing a login flow that for technical reasons needs to be an old-fashioned form submit. If the username and password that are entered fail to authenticate, I’d like the response to the POST to be the same login page, but with the username already pre-filled with what the user entered last time, and with a specific error message about what happened.

Describe the solution you’d like I’d like the handler for a POST endpoint to be able to fall through to a page (which it already can), and for it to be able to pass some state to that page. It turns out this is already possible, by mutating request.locals inside the endpoint. Since getSession is called anew each time we try to render a request as a page, we would be able to expose whatever information we want to the page.

The question then is whether this is desired behavior. It is convenient in my case, but it could be seen as too weird or magical. So this feature request is for solidifying this as official behavior through tests and documentation.

Describe alternatives you’ve considered In my case, there are other workarounds. I could manually implement this endpoint as part of the handle hook, so that I could be sure my locals values would still be present when Kit tries to render this as a page. Or on a failed login I could have the endpoint redirect (as a GET) to a URL that had the username and an error code in query parameters.

How important is this feature to you? Being able to implement this login flow is quite important, as it’s for work. The solution outlined here is somewhat important, as it seems like a nice way to solve this.

Additional context @GrygrFlzr and I chatted briefly about this and some related issues on Discord. It’s currently possible for getSession itself to mutate the request, but that seems really weird, impractical to prevent, and not something we should be worrying about defining the behavior of.

We also chatted about how routes are sorted by specificity and precedence. This is mostly described at https://kit.svelte.dev/docs#routing-advanced-fallthrough-routes but I’m wondering whether this could be made a bit more explicit. Endpoints do have higher precedence than pages, but only for routes that otherwise have the same specificity. This is a bit tricky to say in a way that is both accurate and comprehensible. We don’t, for example, want to just link people to the comparator function that’s used to sort them.

[dslatkin]

It would be great if this could be addressed before a 1.0 release or at least become a p1 issue. It feels hard to say that SvelteKit can make transitional apps if there’s not a built-in or sanctioned way for SvelteKit to handle server-invalidated form submissions for users without JS. I’m wondering if @Rich-Harris has seen this yet and has thoughts?

Another conversation on Discord recently led some of us to the same technique as @Conduitry - loading request.locals in an endpoint before falling through to a page, at which point getSession picks up those new locals to make them available in that page’s load function. I would feel much better about it if it’s clear in the docs that it’s sanctioned behavior and not an abuse of locals. It also wasn’t entirely clear to me that getSession may run multiple times on the same request during SSR so it would be nice if this were mentioned in the docs too?

For serving entire pages from endpoints, I personally would be very wary of addressing the issue that way. I could see routing becoming much more ambiguous by comingling which pages are served at which paths in the file tree. If a request comes in for /some-page, I would think it should be either /some-page.js or /some-page.svelte which serves the response.

[Rich-Harris]

Closing in favour of #3532