Feature request: Reset layout inheritance in nested routes

[sto3psl]

Is your feature request related to a problem? Please describe.

When building a website I want pages to share a specific layout with common UI elements like a navigation, sidebar, footer, etc. Other pages might want to use different layouts like a custom landing page. This works fine as long as my landing page is not a sub page of an existing page with layout.

** MY SHOP **
src/routes
├── bikes
│   ├── _layout.svelte
│   ├── category
│   │   └── index.svelte
│   └── [slug]
│       ├── index.svelte
│       └── _layout.svelte

In this example /bikes has a custom layout. Individual bike routes like /bikes/fancy-bike-3000 add their own layout and inherit the one from /bikes.

The problem appears when I want to make a super fancy landing page to promote all my mountain bikes. This page is completely individual and uses its own layout.

  ** MY SHOP **
  src/routes
  ├── bikes
  │   ├── _layout.svelte
  │   ├── category
  │   │   ├── index.svelte
+ │   │   └── mountain-bikes-promo
+ │   │       └── index.svelte
  │   └── [slug]
  │       ├── index.svelte
  │       └── _layout.svelte

/bikes/category/mountain-bike-promo will always inherit the layout from /bikes, but in this case it's not wanted.

Sapper needs a feature to bail out of the layout inheritance and let sub pages define their own layouts.

Describe the solution you'd like
I would like an API that allows me as developer to get more flexibility when needed but has the layout inheritance by default.

Ideas:

• Use a special prop in layout components, that tell Sapper to not include layouts up in the file tree. Maybe something like this:

<!-- _layout.svelte -->
<script>
  export let inherit = false;
</script>

• Nuxt.js has a layout/ folder with custom layouts that you can specify in your page (https://nuxtjs.org/api/pages-layout). This probably doesn't work well with the current inheritance model but I like it.

/* vue code */
export default {
  layout: 'blog',
  // OR
  layout (context) {
    return 'blog'
  }
}

Describe alternatives you've considered

In the end it's always possible to import layout components like any other component on every page. This provides full flexibility but can be a bit cumbersome if something like the inheritance model already exists.

A different solution could be to structure routes differently but a site structure should ideally not be constrained by the framework of choice.

How important is this feature to you?

I think this is a use case every application of a particular size will eventually run into. May it be custom landing pages or interactive stories with data visualizations.

Additional context

There was a former discussion in this issue sveltejs/sapper#809.
The idea to hide elements in a root layout based on segment doesn't really work since not the full route is available.
Looking at my example bikes/_layout.svelte has segment === "category" but mountain-bike-promos is needed to know if layout components need to be hidden.

---

I look forward to any API discussion and can maybe come up with an implementation if this is a feature you want to integrate into Sapper.

[zwz]

I had the same request.
Would it be good that we introduce a reset-layout file __layout.svelte (note the double _), which means it will not inherit layouts up in the file tree, and all the child _layout.svelte will inherit up to it but stops here.

IMO, it is simple, clear, and consistent to the current layout mechanism.

[sto3psl]

@zwz I like the idea, but would reconsider the name. From a quick glance the difference between _ and __ isn't that big and it could look like a typo. It could cause some hard to debug issues where people see their layout not apply (or apply incorrectly) and don't find the issue because the difference between _layout.svelte and __layout.svelte isn't easily visible.

Maybe _root_layout.svelte could be used? This makes it super visible in a file tree, when a new route uses a new layout root. What do you think?

[pngwn]

The idea to hide elements in a root layout based on segment doesn't really work since not the full route is available.
Looking at my example bikes/_layout.svelte has segment === "category" but mountain-bike-promos is needed to know if layout components need to be hidden.

That's because that is the segment and not the path (which could be removed in a future version, there is an issue discussing this). If you use the page store, then you have access to the entire path (see the Sapper documentation on stores()).

Regarding this request, this is something that has come up several times. There has been quite a bit of discussion around what the best way is to achieve this. Additional layouts in the relevant route folder would be in-keeping with how Sapper handles things, but it could be confusing having multiple layouts. If you wanted to 'disinherit' a parent layout, you would need to add blank 'reset' layouts, for example. This doesn't feel like an ideal solution to me.

I'm inclined to think that this kind of behaviour is better handled with a config file, but I know that Rich is (or at least has been) against adding a config file to Sapper. I am personally of the opinion that with the amount of CLI options we now have and with feature requests like this, a configuration file should be reconsidered.

One other option is to use a special layouts folder to 'shadow' specific layouts (or vice-versa—define them in a layouts file and shadow them in routes). This could work: custom layouts could be defined by matching the folder location and filename of the file you wish to customise which fits Sapper's routing model, but we would have another special folder. There are probably other problems with this too, what if you only want to 'disinherit' one of many layouts at an arbitrary depth gets weird, I can think of some partial solutions, but the resulting API would be confusing at best and limiting at worst.

If a config file is the best way to go then we need to have a conversation about whether or not we should have a configuration file in Sapper (and some related details) before this issue is tackled.

[sto3psl]

@pngwn could you elaborate how a config file would look like to solve this layout inheritance issue? Would there be a root config with a list of routes that inherit/don't inherit layouts?

For now I will make layout components and import them explicitly until there is a Sapper solution. I think that is what one would do in Next.js.

[pngwn]

@pngwn could you elaborate how a config file would look like to solve this layout inheritance issue? Would there be a root config with a list of routes that inherit/don't inherit layouts?

No, I couldn't because I've given it approximately zero thought. But it seems like it might provide a relatively flexible solution.

[carcinocron]

Another idea:

<svelte:layout name="simple" />

or

<svelte:layout inherit={false} />

All the ideas proposed so far work for me.

[sto3psl]

@InstanceOfMichael I don't think this is an issue that should/can be solved in Svelte.

It only concerns how Sapper builds pages by building a Svelte component per page and nesting all _layout.svelte components on the way.
You can see that here https://github.com/sveltejs/sapper/blob/master/src/core/create_manifest_data.ts#L29
and here
https://github.com/sveltejs/sapper/blob/master/src/core/create_app.ts#L271.

If I use Svelte outside of Sapper, there is no concept of layout inheritance.

[khrome83]

Throwing in my 2 sense...

Would it make sense to return a configuration object as part of the output of preload or another method like preload? That way you have a place in JS where you can make the decision on how a layout needs to behave. Hypothetically.

I like the idea of it being part of the route path as well. But this would give programatic control.

For example a blog post that is part of a series and should inherit the current layout, vs is not part of a series and should not.

[sto3psl]

@khrome83 I'm not sure if that is a possible solution. As I understand it preload get's called at runtime and the pages with all nested layouts are already compiled. That means the solution needs to happen at build time of the page components.

[ramiroaisen]

I think that the hole layout thing makes no sense, is better if each page imports the layout
I personally use this
//_layout.svelte => <slot></slot>
and have _root.svelte files that the pages can import instead of _layout.svelte
There is no layout in svelte why would be one in sapper?

[timeshift92]

Hello everyone, but maybe you’ll make a type like this person’s, he added _reset.svelte ?
https://github.com/jakobrosenberg/svelte-filerouter

[Saiv46]

Any progress?

[jokin]

I found the routify (https://routify.dev/ ) approach very straightforward, if you have a _reset.svelte file on a folder, you use that and stop traversing the filesystem.

I don't get by there a 2 projects with so many similarities instead of one, it's a hard decision to make a choice between booth, I'm evaluating what to use for a very constrained device (a tv with a low end SOC), and using svelte instead of angular has bring a lot of improvement to the speed of the interface, but having to decide between so many options on routing is tiresome

[joelhickok]

I really like the _reset.svelte approach.

I am amazed Sapper does not yet have the ability to use multiple layouts.

[joycollector]

Created a PR with _reset.svelte implementation: sveltejs/sapper#1141