Skip to content
This repository has been archived by the owner on Jan 11, 2023. It is now read-only.

Reset layout in nested route #809

Closed
sto3psl opened this issue Jul 19, 2019 · 5 comments
Closed

Reset layout in nested route #809

sto3psl opened this issue Jul 19, 2019 · 5 comments

Comments

@sto3psl
Copy link

sto3psl commented Jul 19, 2019

Hi everyone, I'm currently building an app with sapper and am quite happy with it. There is one problem though.

I have a _layout.svelte file in my src/routes folder to get a consistent navigation component on all pages. All sub routes inherit that layout, which is fine in most cases. Now I want a nested routed, but it should not use any _layout.svelte that is above in the tree.

Example file structure:

src/routes
├── _error.svelte
├── _layout.svelte
├── user
│   └── [user_id]
│       ├── index.svelte
│       └── info
│           └── index.svelte /* this should not use `src/routes/_layout.svelte` */
└── index.svelte

Is there any way to reset the layout or tell a page to not inherit layouts?

@antony
Copy link
Member

antony commented Jul 19, 2019

Hi @sto3psl - Github is a place for Issues, bug reports and PRs, not usage questions.

For help with Sapper and Svelte, please come and ask your question on the discord https://discord.gg/R8FKuA or on stack overflow, with the tag svelte or sapper.

As a quick pointer - you can't currently do what you want to do with Sapper, you should use a more generic base layout and/or wrap your layout elements in if statements based on the segment property.

Please close this issue and come and chat to us on discord for further help :)

@sto3psl
Copy link
Author

sto3psl commented Jul 19, 2019

Hi @antony - thank you for your advice. Is Github the right place for feature requests or proposals?

I think this would be a very handy feature. It is not that uncommon that in a big application single pages want to implement a completely different layout. For example a highly interactive visualization might not want to include the default header or a sidebar and instead control the whole page.

Conditional rendering based on segments is a workaround but not great either. It gets messy if you have to maintain a list of special cases when you could reset the layout somewhere down the file tree.

I don't know how an API for that could look like and I'm just spit balling here but setting something like inheritLayout = false in some nested _layout.svelte file would be a great feature.


On a side note: I'm not interested in creating a discord account and in my opinion this would get lost and other people running into the same issue won't find the previous discussion easily or at all.

If you still think Github is the wrong communication channel here, I will close the issue.

@antony
Copy link
Member

antony commented Jul 19, 2019

Github is the right place for proposals, you are correct. I agree that mutliple-layouts is something desirable (for me too, and a few others), there is a fair amount of historical discussion that you haven't seen - and I agree it gets lost in discord, and is better placed in github issues (as a proposal).

I would suggest closing this issue and raising a proposal instead, as I can't find the previous one right now. I would strongly suggest a discussion in discord first, but that's up to you.

You can use discord without an account, and a proposal should ideally be the result of a discussion. Items are more likely to get lost on github issues (because usage questions will often just be closed without response - it's not the right place for them).

@sto3psl
Copy link
Author

sto3psl commented Jul 19, 2019

I will consider using discord. Nevertheless, thank you for answering quickly to this issue. Maybe I use the Feature Request Template when your PR is merged 😉.

@sto3psl sto3psl closed this as completed Jul 19, 2019
@antony
Copy link
Member

antony commented Jul 19, 2019

@sto3psl - yes, I'm very eager to get those merged!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants