"magic" layout for resetting

[stephane-vanraes]

Describe the problem

Ever since named layouts it's no longer possible to do __layout.reset.svelte.
A workaround is to define a top level __layout-reset.svelte with just an empty slot, then apply this reset as a named slot: __layout@reset.svelte

Describe the proposed solution

Have reset be a magic named layout that does exactly the same without having to define this file.

Of course this would break for people that use the reset with something else but an empty slot, maybe SvelteKit can check if it is defined and if not fall back to an empty slot ?

Alternatives considered

No response

Importance

nice to have

Additional Information

No response

[dummdidumm]

Had the same request at a conference from two people. Alternative: bring __layout.reset back. Pro: no danger of collision. Con: you know need to know about both the @ and the . character and their meanings

[stephane-vanraes]

Had the same request at a conference from two people. Alternative: bring __layout.reset back. Pro: no danger of collision. Con: you know need to know about both the @ and the . character and their meanings

How would this work if people tried to do __layout.reset@something ?

With @reset and the rule you cannot have multiple inheritance this does not pose a problem, with .reset this suddenly becomes an option that could give confusing results.

[furudean]

Named routes are already a very complicated feature. I don't think it's a good idea to introduce more magic to an already commonly misunderstood system.

I think the solution lies in better educating folks on this.

How about adding the @reset layout to the default Svelte Kit template with a short comment on what it's used for? Adding this this would help bring attention to this pattern and raise it to a de-facto standard.

I think the docs are lacking, too. They immediately go off about how named layouts can do a ton of stuff but no common use cases. It's a bit easy to get "lost in the sauce" as one might say. I think putting a tl;dr at the top with some common recipes would go a long way.

[Mlocik97]

I think from all features that Svelte and SvelteKit offer, layouts are actually the most confusing and complicated feature. So I agree with @furudean . I use it really carefully and a lot of more complicated stuff that someone would typically use layouts for, I do with dynamic content... like:

./src/routes/__layout.svelte:

<script>
    import SomeContainer from '$lib/SomeContainer.svelte';
    import { page } from '$app/stores';
 </script>
 
 {#if $page.url.pathname.startWith('/something')}
     <SomeContainer>
         <slot />
     </SomeContainer>
 {:else}
     <slot />
 {/if}

even tho, doing it with named layouts would make more sense.... and it's just because I find this less chaotic, mainly in more complicated layout structures.

I think, we need to redesign layouts (again),... and I got idea of having ./src/layouts/ folder, where we would be able to create all layouts, use them for pages programatically. In pages, we would have:

<script context="module">
   export const layouts = {
		a: {
			b: {
				c: {}
			}
		}
	};
</script>

and it would render content of that page in layout c that would be in layout b that would be in layout a. Or something like this. (actually that export const layouts is just first idea, it would probably look different, but somehow we would define all layouts like this)