Expose status and error to layouts, if rendering a generic error page

[Rich-Harris]

This is a braindump follow-up to #4665, which addresses #4815. As of #4665, the behaviour seen in #4815 will be different — it will render the plaintext error page (because an error status is returned from __layout during the rendering of the __error page), which isn't what we want.

One possible solution to that is to expose status and error to __layout components, so that if a layout does something like this...

if (!$session.user) {
  return { status: 401 }
}

...it's possible to skip that when load is called a second time during rendering of the generic error page:

-if (!session.user) {
+if (!session.user && status === null) {
  return { status: 401 };
}

This does feel rather messy, and does feel like it hints at a deeper design flaw. It also adds some complexity, since ordinarily layouts don't see these values (we only 'unwind' layout/leaf nodes until we hit an __error that we can render; we don't re-run __layout and so there's no opportunity to present status/error), there's a distinction between generic and non-generic error pages, which has to be somehow replicated in the client (at present it's easy, because if we initialise the client with an error, only the specified __error page gets to see it).

An alternative, as suggested in #4815 (comment), is for __error pages to be completely separate from the layout tree. I don't love that, since aside from being a significant breaking change it would mean a lot of code duplication between __error and __layout.

Needs some further thought. In the meantime, I'm just going to leave this here.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

[changeset-bot]

🦋 Changeset detected

Latest commit: bc1bd76

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[rmunn]

An alternative, as suggested in #4815 (comment), is for __error pages to be completely separate from the layout tree. I don't love that, since aside from being a significant breaking change it would mean a lot of code duplication between __error and __layout.

What about having error pages be separate from the layout tree unless they opt in? I.e. if you want your error page to display using the top-level __layout.svelte layout, you'd name it [email protected], but an __error.svelte page without an explicitly-inherited layout will render as a top-level component all by itself, with no layout components.

This would allow the fallback code to only load the top-level __error.svelte and not the top-level __layout.svelte, which might help mitigate issues like #2130 and #2154. (See #2130 (comment) discussion for more about this.)

Haven't fully thought through the implications of that yet, but it seems like a possible solution here.

[Rich-Harris]

Going to close this as it is obsolete in light of #5748.

Allowing error pages more control over layout is probably a smart idea, and one we should revisit after the redesign work is complete