Support named layouts for the error page, e.g., __error@root.svelte, to remove hardwired dependency on __layout.svelte

[johndunderhill]

Describe the problem

Currently, __error.svelte is hardwired to __layout.svelte. In several of my projects, I use __layout.svelte for non-trivial purposes, including authentication guards, and of course rendering part of the page. This makes it nearly impossible to use __error.svelte to set up a global error page:

• The error page tries to display the shared page layout, which may be undesirable, and may re-trigger the error, or another error.
• Authentication guards may attempt expensive operations, redirect to a login page, or trigger another error.

I've tried to work around this by saving the error information and redirecting to a normal page to display the error, but the approach is cumbersome and fraught with problems:

• There is no way to detect, in __layout.svelte, that the error page is running. The URL path is the (possibly bad) path of the page that triggered the error.
• There's no good way to get the error information (error, status) to the next page. Using the session store may work, but may cause further problems or interfere with use of the session store for other purposes (such as server-to-client communication).
• It's not clear where or how to redirect out of the error page, and this may lead to further problems.

This has been a nightmare. I couldn't get it to work--I kept running into cascading issues--so I gave up (see Alternatives, below).

Describe the proposed solution

A simple solution would be to allow the error page to specify a parent layout (just like any other page, with the new named layouts):

__error@root.svelte

This could be an empty layout, which would remove dependencies on other parts of the app, making the error page less likely to fail. Similar to 2694 but adapted for the new named layouts.

Alternatives considered

Using a catch-all path in the route root will capture any unknown page, and this can specify a named layout:

[...anypath]@root.svelte

But this will not have access to actual error information, such as the stack trace, in development.

Importance

would make my life easier

Additional Information

The new named layouts were a bit hard to understand at first, but they are extremely powerful, and I'm sold on this. Fixing this would complete the picture, IMHO. As always, thanks to everyone for your hard work.

[blujedis]

Popping in to say I'm glad the nightmare I'm currently enduring is being addressed ha ha.

For what it's worth to me it feels as thought the best solution would be to just have say --layout-full.svelte where it has maybe basic font family etc. but is essentially 100% height and width then you could just do __error@full.svelte.

[vhscom]

For anyone lost in the weeds, there's a decent workaround for handling full-screen error page layouts documented here with example implementation here. It's a fairly non-invasive procedure. Not perfect but not too shabby while a suitable long-term solution is considered.

[icalvin102]

Sadly __error.svelte also seems to ignore the the inheritance chain of named layouts.
For example with __layout-base.svelte and __layout@base.svelte only __layout@base.svelte will be loaded in case of an error and __layout-base.svelte is ignored.

This causes issues when the extending layout or error page relies on things that are initialized in the base layout.

This is a big inconsistency and layout inheritance should work the same way it does for page components IMO.

[avarun42]

If you use nested layouts at all at the root-level, error pages are completely broken right now pretty much. You end up having to import the same things in the error that should've already been imported by the parent layouts of the base layout.

[MadeByMike]

I think there is a easier work-around than vhscom mentions above:

<script>
  import { page } from '$app/stores'
</script>
{#if $page.error}
<div class="your-error-layout">
  <slot></slot>
</div>
{:else}
<div class="your-normal-layout">
 <slot></slot>
</div>
{/if}

I end up with issues using the other method since it modifies the Request stream.

[Rich-Harris]

I think it's possible that we'll want to add +error@whatever.svelte in the future, but in the meantime note that you can now achieve this by putting your app inside a route (group) that your +error.svelte sits outside of:

src/routes/
├ (main)
│ ├ foo/
│ ├ bar/
│ ├ etc/
│ ├ +layout.svelte # can safely throw errors in here
│ └ +page.svelte
├ +error.svelte   
└ +layout.svelte   # optional

[netfl0]

It appears that the "named layouts" feature is gone?

https://kit.svelte.dev/docs/layouts#named-layouts - I now get a 404

I thought that was one of the slickest features pre "+layout" svelte-kit.

[madeleineostoja]

Named layouts have been replaced by layout groups, which is a much more powerful and flexible concept. This issue is still open because (afaik) you can't apply certain features of layout groups, namely bailing from the current group with @..., to error pages