Simpler custom layouts #6124
Replies: 27 comments 100 replies
-
|
I like the grouping mechanism because loading and or layout ui often go hand in hand with feature areas. I don't like that it potentially creates more folder depth, but I can live with that - but curious to hear other people's opinions. An alternative would be to keep the current system but without the possibility to inherit from siblings - you would always go up the tree, and all named layouts inherit from the default layout automatically. This should achieve the same without the grouping mechanism. One question about segments: if I want to rewind to the layout within One edge case I'm not sure how it's handled: what if there are multiple segments in the tree with the same name. What to do if you want to jump past the first one? One note about |
Beta Was this translation helpful? Give feedback.
-
Correct @CaptainCodeman What does 'references across groups' mean? |
Beta Was this translation helpful? Give feedback.
-
|
Exactly that example - it wasn't clear if the groups were independent or not. Once you are referencing groups though you're kind of back to just using named layouts (I guess apart from within the group?) |
Beta Was this translation helpful? Give feedback.
-
|
Yes, and? |
Beta Was this translation helpful? Give feedback.
-
|
I don't think you get much in return for splitting up your route hierarchy into these group folders, not just into different folders but potentially also to multiple inconsistent depths. Not enough to make it a worthwhile tradeoff. Now to locate a route, you have to know & remember which layout(s) it uses, to know which folder(s) to look in. |
Beta Was this translation helpful? Give feedback.
-
|
Or type |
Beta Was this translation helpful? Give feedback.
-
|
This is slightly off topic (slightly sorry), but slightly related: This proposal creates a solution that uses slots to put a modal page in a simple page. |
Beta Was this translation helpful? Give feedback.
-
|
Also it would be great if sveltekit team consider #627 now |
Beta Was this translation helpful? Give feedback.
-
I can't picture how this would be usable, wouldn't pages only belong to one "group" or another? What if they need to take part in two groups at the same time? i.e. one for auth, one for some other context I'm picturing a site like firebase console, where you have auth and you might have a selected project. Currently, I'd use a layout for loading the selected project data that becomes the context, and that layout uses another that ensures auth ... but other things also need to use the auth layout as well (e.g. user preferences, billing, profile) without any project context. I don't see how I could have an (auth) group and a (project) group and pages use both. |
Beta Was this translation helpful? Give feedback.
-
|
Like this? Obviously you couldn't have an unauthed project under this design, but at that point layouts are the wrong tool for the job. |
Beta Was this translation helpful? Give feedback.
-
|
So groups can also be nested ... at any level? (i.e. any point in the route tree can introduce a new group?) |
Beta Was this translation helpful? Give feedback.
-
|
Yes |
Beta Was this translation helpful? Give feedback.
-
|
It sounds like you want to mix and match |
Beta Was this translation helpful? Give feedback.
-
|
No, each load would be doing its own thing, although they depend on the higher levels they don't repeat what they do. There's actually a (console) layout, which would load the list of accessible projects based on the users auth, and the selected (project) level would be the context to show all pages related to that project, also checking for access permissions to it. |
Beta Was this translation helpful? Give feedback.
-
|
I understand the rationale for this proposal but I think the solution is digging the hole even deeper. The problem stated was that named layouts were confusing. The solution proposes a new abstraction that adds more "api" to file and directory names, which IMO will increase the confusion and learning curve. Using a hierarchy to determine routing is reasonable because it maps 1:1 with a URL structure, which is indeed a hierarchical tree structure with no loops - read: "not a graph". But as soon as we want to break out of the layout determined by the hierarchy that determines routes, we are attempting to create a graph. (Please let me know if that's not clear and I'll provide more details.) I liked how RH (or someone... can't remember) described the render tree as different than the data tree. In reality, we have at least 2 trees and 1 undirected graph. Trees: route, data. Graph: render, (where layout is part of render.) I recommend only using directories and filenames for the "api" of the route concern. Which means URLs are determined by directories and filenames. Ideally rendering is determined by code in the templates, (which would mean we have to solve the static determinism problem RH mentioned in the discussion HEAD.) And data... well, that's more difficult but using +X.server.js seems ... fine ... for now? Tl;DR - I'd suggest moving away from treating the file and directory names as an API and move toward separating routing vs render "APIs". p.s. One of the great things (and strongly intended design decisions) of SvelteKit is the drive toward type safety. Thanks as always for reading |
Beta Was this translation helpful? Give feedback.
-
|
This proposal absolutely does not increase the API for named layouts from how it currently works. It just reworks the API into something more elegant and intuitive. I would argue that it's even less surface API area, though that's up for debate. Rich said,
I contrived some outlandish examples (for the sake of argument) elsewhere with Rich, and came away thinking of this proposal as bullet proof. I would also argue the grouping explicitly makes it easier to find and make sense of routes and associated layouts. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe I'm missing something. But doesn't this proposal include adding 2 new file/directory naming conventions? If so, then that's 2 new concepts that are being added the the "API" we have for filesystem names. |
Beta Was this translation helpful? Give feedback.
-
@coryvirok Things got replaced, not added.
If you ask me, the API doesn't change much, but the directory tree gets simplified a lot. Named layouts become less powerful and focus more on the jobs they're supposed to do. |
Beta Was this translation helpful? Give feedback.
-
|
Strictly speaking, the You have to have these superfluous 'anchor' layouts everywhere you want to reset to a parent layout that's also the default layout for its subtree. It's very unwieldy. In addition to getting rid of that, this proposal removes Sure, if you count the additions and removals, it comes out more or less as a wash, depending how you slice and dice it (I'd argue this breakdown is generous to the status quo)... ➖ ...but an accurate appraisal requires us to compare how intuitive those various aspects are. By contrast, in this proposal we have an unambiguous hierarchy with a single piece of layout-related syntax in component filenames. I think it's pretty hard to argue that this increases confusion. |
Beta Was this translation helpful? Give feedback.
-
|
I also think the existing design could be easier because it really complicates the file naming. Especially if you are just starting out it could be quite difficult to understand how layouts work. What I don't like about this approach
Here's my suggestion: Why not having a separate folder
The layouts could be applied by this:
<Layout name="admin">
<h1>Admin Dashboard</h1>
<div>....</div>
</Layout>Nested layouts could be done by this:
<Layout name="admin">
<h1>Admin Dashboard</h1>
<Layout name="product">
<div>...</div>
</Layout>
</Layout>Advantages of this approach
I'm still a beginner, so I can't really tell if that would be a good approach or not. But from the perspective of a beginner, this looks very easy and logical. |
Beta Was this translation helpful? Give feedback.
-
|
I wouldn't want to repeat the wrapped layout in every of my page components. The common case is that you don't need many different layouts, if at all, so for the common case it's more boilerplate. |
Beta Was this translation helpful? Give feedback.
-
I'm having a hard time understanding this response. Currently, if you need to break out of a layout hierarchy to the root then at minimum you need Under this proposal, your root directory will have at most a single layout.
Keeping the directory clean is not the goal. The goal is to make things understandable. That's where the current system falls down, and where this new proposal has significant advantages. Putting layouts (which are inherently hierarchical) in a separate (flat) directory would make it much harder to understand the relationships between different parts of the app. |
Beta Was this translation helpful? Give feedback.
-
|
They may be loosely hierarchical but don't always have a 1:1 match to the route hierarchy which gives rise to the named reference complexities. I think it comes down to whether there are ever that many layouts that having them in the route hierarchy, esp. given that you then often want to undo that hierarchy by skipping inheritance etc..., is really that clear or valuable. |
Beta Was this translation helpful? Give feedback.
-
|
I'm sure you'll all hate this, but expressed in a special comment block at the top would solve everything ... <!-- use-layout=whatever -->
<script>
...
</script> |
Beta Was this translation helpful? Give feedback.
-
|
This sounds like a different version of |
Beta Was this translation helpful? Give feedback.
-
|
yeah but it's guaranteed to be easy to statically analyse |
Beta Was this translation helpful? Give feedback.
-
I believe the package resolution of Golang uses this proposed comment-style type of optimisation. First line of each file is required to be a package definition, I certainly don't understand this problem nearly as much as anyone else here, but I doesn't seem there's a specific requirement to parse the code through JS first to determine the layout or any other Kit config value per route. If the first 15 chars aren't Again, I am not clear on the inner working of Kit and when this part is evaluated and if it indeed does need to be done after parsing files into JS. Just wanted to share that I believe other tools use mechanisms/optimisations like this. |
Beta Was this translation helpful? Give feedback.
-
|
The problem with |
Beta Was this translation helpful? Give feedback.
-
The framework can define the rules for this. Assume it's static, don't allow dynamic. Grep the file for Single or Double quote strings after the Inelegant or hacky, sure. Simple to use and explain, I think so. |
Beta Was this translation helpful? Give feedback.
-
|
Another option might be something like this: Specify all the layouts in a Not sure how you would go about adding a layout to the absolute top-level though. Maybe a Unsure how you would "eject" from layouts. Maybe something like |
Beta Was this translation helpful? Give feedback.
-
|
this will be annoying pretty fast if you have a dozen of pages. |
Beta Was this translation helpful? Give feedback.
-
|
I suppose - but that doesn't seem like something you'd do that often. This is way clearer to the consumer than the other proposals in here IMO. |
Beta Was this translation helpful? Give feedback.
-
|
It's way clearer in the simplest cases, but putting layouts in a separate
The first option forces you to come up with a bunch of unique names, for basically no reason. (Even in the current system, where you're also forced to come up with names, at least they only need to be unique within a subtree.) Understanding the layout hierarchy is very confusing, because you have to mentally convert an unordered subset of the list of names into a linked list that applies to a given page. The second is a maintenance nightmare, especially for larger apps. Even if that weren't the case, you'd still be forced to add |
Beta Was this translation helpful? Give feedback.
-
If I find myself doing that it usually means I need to flip the default and named layouts round, so only the odd exception needs to be given a name. |
Beta Was this translation helpful? Give feedback.
-
|
My hesitation with the groups is that it really messes with my head on the routing. Especially if those (directories) are collapsed. Quick side note: how in the world do y'all create those fancy-looking folder/file structures?? We've already gone to a directory centric approach to defining routes. What if we did the same for layouts?
This keeps the layout structure separated from the route structure, while (I think?) simplifying things. What I don't like about my idea:
|
Beta Was this translation helpful? Give feedback.
-
|
I'm trying to glean what the exact rules are based on the descriptions given and and previous comments Sorry, I thought "references across groups" was clear. Across as in, referencing other folders than the group the route is in. Otherwise I would describe that as references within groups. So it sounds like references across groups (from one tree to another) is not allowed, all you can do is reference the current or parent group (?) you are in? |
Beta Was this translation helpful? Give feedback.
-
|
The proposal explicitly says 'identifying the parent level' — parents, not cousins or nieces or nephews. It would be absurd if it worked any other way! |
Beta Was this translation helpful? Give feedback.
-
|
That was in the context of referring to route segments. The other comments were talking about references to I've stopped trying to decide if something is absurd or not. |
Beta Was this translation helpful? Give feedback.
-
|
I really wish you'd take this reflexive snark somewhere else. |
Beta Was this translation helpful? Give feedback.
-
|
I feels like you're determined to imply every question is stupid or the answer already obvious. I'm asking them because to me they weren't, and I've explained the reasons for my confusion. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think grouping is a good idea as it would as well make perfect sense to just split the two groups into 2 parent routes given how different they are (and redirect if they accessing the parent route) src/routes/
+ ├ app/
│ ├ dashboard/+page.svelte
│ ├ item/
│ │ ├ [id]/+page.svelte
| │ │ └ edit/+page.svelte
│ │ └ +layout.svelte
│ └ +layout.svelte
+ ├ marketing/
│ ├ about/+page.svelte
│ ├ testimonials/+page.svelte
│ └ +layout.svelte
├ admin/+page.svelte
└ +layout.sveltestill there would be a problem where app and marketing pages would use the root layout. For this I suggest we can write a single @ which indicates it does not inherit any layout, such that the child pages of that route would also do the same: src/routes/
+ ├ app@/
│ ├ dashboard/+page.svelte
│ ├ item/
│ │ ├ [id]/+page.svelte
| │ │ └ edit/+page.svelte
│ │ └ +layout.svelte
│ └ +layout.svelte
+ ├ marketing@/
│ ├ about/+page.svelte
│ ├ testimonials/+page.svelte
│ └ +layout.svelte
├ admin/+page.svelte
└ +layout.svelteThen for child pages that would like to escape we can write like, which fall backs to src/routes/
├ app@/
│ ├ dashboard/+page.svelte
│ ├ item/
│ │ ├ [id]/+page.svelte
+ │ │ └ edit/+page@app.svelte
│ │ └ +layout.svelte
│ └ +layout.svelte
├ marketing@/
│ ├ about/+page.svelte
│ ├ testimonials/+page.svelte
│ └ +layout.svelte
├ admin/+page.svelte
└ +layout.sveltesuch that if we want to fallback to src/routes/
├ app@/
│ ├ dashboard/+page.svelte
│ ├ item/
│ │ ├ [id]/+page.svelte
+ | │ │ └ edit/+page@routes.svelte
│ │ └ +layout.svelte
│ └ +layout.svelte
├ marketing@/
│ ├ about/+page.svelte
│ ├ testimonials/+page.svelte
│ └ +layout.svelte
├ admin/+page.svelte
└ +layout.sveltefor me this way seems to be more straight-forward and still maintain the route hierarchy. |
Beta Was this translation helpful? Give feedback.
-
|
So you're saying that the routes should just be |
Beta Was this translation helpful? Give feedback.
-
|
Yes! Since they don’t share any layout then maybe it’s more reasonable to split in two completely different route trees and get rid of the layout with single @. |
Beta Was this translation helpful? Give feedback.
-
|
I mean that's fine, if it's in your power to do that, in which case you don't need to bother with any of this stuff. But when your boss/client/whatever comes along and says |
Beta Was this translation helpful? Give feedback.
-
|
thats true though XD |
Beta Was this translation helpful? Give feedback.
-
|
TL;DR
I like the part of the proposal where a page can reference the root layout using Group problem 1. It could potentially make some refactors difficultIf a team decides to change a group name then that could block some other teammates' changes upstream and would require careful planning. Bigger teams may have potentially bigger conflicts. Group problem 2. What if we need more groups?Original example for referenceAn app may require more groups in order to have new "root layouts"; such as item reviews, store locator, user profiles, or (marketing) sponsorships; and the new app routes require a different root layout because they don't utilize a common navigator or footer because they're meant to be embeddable (iframe) app pages. Altogether, that would look something like this: src/routes/
├── (app)/
│ ├── dashboard/+page.svelte
│ ├── item/
│ │ ├── [id]/
│ │ │ ├── edit/+page@.svelte
│ │ │ └── +page.svelte
│ │ └── +layout.svelte
│ └── +layout.svelte
+── (app-embeddable)/
+ ├── item/[id]/reviews/+page.svelte
+ ├── stores/
+ │ ├── [id]/+page.svelte
+ │ ├── +page.svelte
+ │ └── +layout.svelte
+ ├── users/
+ │ ├── [id]/+page.svelte
+ │ └── +page.svelte
+ └── +layout.svelte
├── (marketing)/
│ ├── about/+page.svelte
│ ├── testimonials/+page.svelte
│ └── +layout.svelte
+── (marketing-sponsors)/
+ └── sponsors/
+ ├── +page.svelte
+ └── +layout.svelte
├── admin/+page.svelte
└── +layout.svelteAnd what if a page needs to render both as an app and as an embeddable page? We could add a I hope this example doesn't come across as contrived since I had worked on such an app with embeddable requirements. A fair argument would be having the Potential solution: root layoutsI propose keeping named layouts and introducing a "layout root assignment" by appending Given the following: src/routes/
-── (app)/
├── admin/+page.svelte
│── dashboard/+page.svelte
+── embed/
+ ├── item/[id]/reviews/+page.svelte
+ ├── stores/
+ │ ├── [id]/+page@.svelte
+ │ ├── +page.svelte
+ │ └── +layout.svelte
+ ├── users/
+ │ ├── [id]/+page.svelte
+ │ └── +page.svelte
+ └── +layout@.svelte
│── item/
│ ├── [id]/
│ │ ├── reviews/
│ │ │ ├── +page.svelte
│ │ │ └── +layout@.svelte
│ │ ├── edit/+page@.svelte
│ │ └── +page.svelte
│ └── +layout.svelte
│ └── +layout.svelte
-── (marketing)/
+── about/+page+marketing.svelte
+── sponsors/
+ ├── +page.svelte
+ └── +layout@.svelte
+── testimonials/+page@marketing.svelte
├── +layout.svelte
+── +layout-marketing.svelteThe behaviour would be:
I understand the big question is "is this intuitive?" and not "is this clean?". At a glance, it's not intuitive how Revisiting layout functionalityCompared to the imperative approach in Astro, Nuxt, and Jekyll, I think we would lose functionality if we don't have the flexibility of named layouts. With the groups proposal, we wouldn't have selective layout inheritance (i.e. From my understanding, layouts require the following functionality:
Static site generators like Jekyll require every page to explicitly define their layout in the page's code. A layout can also slot into other layouts, but it's inflexible: once a layout consumes another layout, that's defined permanently. Breaking out of that requires duplicate layouts. SvelteKit today solves problems 1 and 2 and adds bonus functionality thanks to the file-based router:
That's great, athough some applications may run into inflexibility concerns when a page should not consume a certain sibling or parent layout, and for that I can see how this discussion can yield several potential solutions. I hope my proposal introduces enough flexibility without introducing too much new complexity, compared with groups. Thanks for your effort. |
Beta Was this translation helpful? Give feedback.
-
|
@theetrain how does colocating make it easier to loop in an each block? |
Beta Was this translation helpful? Give feedback.
-
|
I think he means splitting out the inner content into a separate component. Just to avoid having too much in the page view component. One thing often forgotten in all this is unit tests - if you have a test file that also references a component, as well as the view, is it then "shared"? |
Beta Was this translation helpful? Give feedback.
-
|
@theetrain sorry for the late response, what I meant by "reusable components" were components that can be imported by multi pages in different places. Like the one that needs |
Beta Was this translation helpful? Give feedback.
-
|
@np-nam just put it in |
Beta Was this translation helpful? Give feedback.
-
|
Thanks everyone for the lively discussion. I see the new changes have been implemented, so let's try it. @np-nam I see your point about making reusable components (needed by multiple pages) be shared in Also, it looks like |
Beta Was this translation helpful? Give feedback.
-
|
What I like about this proposal is that it keeps layouts under In the current structure, layout gets referenced through In the proposed structure, the fact that I can scan my directory structure and make sense of These is more like a trade-off between |
Beta Was this translation helpful? Give feedback.
-
|
Even if Introducing The proposal to create an |
Beta Was this translation helpful? Give feedback.
-
|
I've commented elsewhere about why |
Beta Was this translation helpful? Give feedback.
-
|
I'm not against the proposal. But here goes another idea... Instead of letting layout inherits layout, can we switch to something like directory uses layout or segment uses layout? The default example becomes:
So there are three choices:
and you can use multiple of them ( The layout is scoped within a segment. This means two things:
Compared to the default proposal:
One more thing I forgot to mention is where do you put the layout files if there are multiple directories for the segment? For example, what happens if I put the
For the original example, I should've put the But yes, the tree grows and you can't decide this ahead of time. Use whatever directory you deem appropriate. EDIT: well, what about
|
Beta Was this translation helpful? Give feedback.
-
|
Now, you can work out the layout stack without following the inheritance chain:
|
Beta Was this translation helpful? Give feedback.
-
|
If I need to give this a name, scoped named layout sounds good to me. |
Beta Was this translation helpful? Give feedback.
-
|
On second thought, maybe we can apply it to layouts, too, so that the canonical root problem in the OP can be solved. So... while with the original named layouts,
So... to sum up, my proposal is to limit the scope of named layouts to only inside a directory and between siblings. I think that's all? |
Beta Was this translation helpful? Give feedback.
-
|
Because we currently have a specific role for each file in the folder, I don't see any sense apply extra syntax to the file instead of the folder. |
Beta Was this translation helpful? Give feedback.
-
Umm... you're talking about my proposal, right? If we only had So we still need But yeah, the original proposal is already coming to town 😅 I guess discussing this is now futile. |
Beta Was this translation helpful? Give feedback.
-
|
It looks like you are trying to use one concept to solve two separate problems. Let directories specify routes, period. Now find another means of associating layouts. To my way of thinking the problem is really how to bi-directionally link components and layouts. Layouts already link to components with a slot. So now use a compatible means of linking components to layouts. In these terms, layouts are really just components by another name. The real thing that distinguishes a layout is that it is not a route, it is implicitly used by routes. That suggests layouts don't belong under /routes at all. You mentioned a possible, but rejected, solution in JavaScript. I'd think about an HTML solution that is the counterpart to |
Beta Was this translation helpful? Give feedback.
-
|
There are only 3 ways to do it that I can think of:
3 was good for ease-of-use because the association came from the route structure, but it breaks down when you don't actually want the layout containment to match that route structure, which is what the resets and named layouts addressed. I'd prefer to keep the current system to splitting up the route tree even more, I think it just fragments and obfuscates the structure too much. Next option for me would be 2. It's been dismissed because it "doesn't scale" which I don't understand - exactly how many different layouts do people typically need? And if all those layouts are folders ... that seems like it would also be equally problematic. |
Beta Was this translation helpful? Give feedback.
-
|
It's not about the number of typical layouts, it's that you would have a
|
Beta Was this translation helpful? Give feedback.
-
|
Can anyone explain in more detail why |
Beta Was this translation helpful? Give feedback.
-
|
As long as you require that everything is vanilla JS/TS — no using other compile-to-JS languages, or using Vite's But then it's not JavaScript — it's a subset of JavaScript, or rather a confusing mixture of JavaScript and not-quite-JavaScript in the same file. People would try to do things like |
Beta Was this translation helpful? Give feedback.
-
|
With a folder based routing, (imho), having a For example this: would be this: If (imho) this is
What do people think about this? |
Beta Was this translation helpful? Give feedback.
-
|
This would require huge amounts of boilerplate for any non-trivial app. It's not just UI that you'd need to reimplement all over the place... <!-- src/routes/settings/+layout.svelte -->
<script>
import RootLayout from '$lib/layouts/root.svelte';
import AppLayout from '$lib/layouts/root.svelte';
/** @type {import('./$types').LayoutData} */
export let data;
</script>
<RootLayout {data}>
<AppLayout {data}>
<div class="settings">
<!-- layout markup goes here -->
<slot />
</div>
</AppLayout>
</RootLayout>...it's all the data loading (and auth guards, etc). And you wouldn't get free type safety inside |
Beta Was this translation helpful? Give feedback.
-
|
This is an interesting take. Under the modal you're describing, would pages only slot in once to the nearest layout, and layouts never slot into their nearest parent layout? If so, that is indeed simple, but we lose out on features such as layout inheritance, and multiple layout loaders via
I agree this is simple, but a bit repetitive since you would need to import |
Beta Was this translation helpful? Give feedback.
-
|
Maybe instead, the layout could inherit the layout from the folder above by default? and maybe there's a filename based way to opt out of that behavior to "break out" (e.g.
FWIW I really like using folders for routes and I really like the specific implementation that was landed on (I just upgraded most of my projects to the latest version of sveltekit this weekend and in one of my larger projects everything became a lot simpler to understand. I even caught some bugs that I didn't know I had). Without any actual data on this, I'm venturing a guess that a large number of projects have a root layout that implements basic structure such has header html / footer html / javascript based analytics / maybe global css etc. I'm also assuming that most projects will probably want a unique layout for a small number of all the routes they have, and they probably the same layout for any sub-routes (i.e. sub folders) for those routes. For example, if we were implementing github: github.com/sveltejs/kit/discussions, github.com/sveltejs/kit/issues, github.com/sveltejs/kit/pulls etc all probably would use the layout defined in |
Beta Was this translation helpful? Give feedback.
-
|
@theetrain makes a good point. Is there really a requirement for inheritance from layout to layout? I know in my app there isn't and I can't think of a use case where there would be. How many people really want multiple nested layouts? If it is for rare esoteric use cases then consider having the simple, easy to understand layout design that @theetrain describes, and make the few people who want more employ the JavaScript imports that @Rich-Harris described. |
Beta Was this translation helpful? Give feedback.
-
|
I've definitely used that feature already. Ironically, I have thought about changing it to use it's own "internal layout" system so it can be packaged up for re-use to make adding to other projects easier. |
Beta Was this translation helpful? Give feedback.
-
|
It's pretty common to have up to 3 levels in admin pages. |
Beta Was this translation helpful? Give feedback.
-
|
Throwing an idea on the wall that I haven't fully baked, so bare with me. JSON route configuration fileTo address the needs for complex route inheritance, "breaking out" of route inheritance and the fact that
{
"layout": "@post",
"prerender": true
}Which could map to Handle any route configurationAny route specific configuration could live here (layout, prerender, hydrate, router, etc). {
"layout": "foo@bar",
"prerender": true,
"hydrate": false,
"router": false
}Static analysisSince it's JSON, it's statically analizable. Resolves point 1. Works for layout inheritance/error pages tooCould be applied to a layout or error via the same mechanism perhaps ( This could help allow for "grouped layouts" by allowing you to indicate one layout is nested within another. For example, in {
"layout": "@admin"
}Inherit any layout anywhereYou could reference a layout by path: {
"layout": "foo/bar/baz"
}Would map to This means you could map to any arbitrary layout in your app irrespective of its hierarchy and would negate the need for all the fancy file name gymnastics. Kit could notice if that path was invalid and throw an error. Partially resolves point 2. Resetting layout to defaultSetting layout to "@" defaults to the root layout (or maybe {
"layout": "@"
}Partially resolves point 2. Custom named layoutsFor custom named layouts (eg "marketing", could do: {
"layout": "@marketing"
}Which could map to {
"layout": "foo/bar/baz@biz"
}Would map to Simple default caseFor the default case of a route just using the default layout, no config option needs to be set, only set it when you want to override the default hierarchical inheritance. JSON is standard and simpleAnd finally, we're all used to JSON for configuration, so I don't think it would be too confusing. FINThanks for coming to my TED talk ✌️ |
Beta Was this translation helpful? Give feedback.
-
|
Another possibly divisive suggestion: Can we get rid of layouts? Do we even need them? ... Hear me out... Why not do what other routing libs do and just allow for a Now that we have per route "middleware" or whatever we want to call it, we can build the data server-side and push down through And if you needed a child URL to break out of the parent component, you would put that logic into the parent component itself while having the data returned from the server stuff something into This is how it works with VueRouter and it's pretty nice. |
Beta Was this translation helpful? Give feedback.
-
|
I personally don’t find a better way for the group job.
Honestly, to introduce this third level of abstraction, we need something to materialize it, I’m fine with you proposal. I’m curious to see what you’ll imagine for the next one. |
Beta Was this translation helpful? Give feedback.
-
|
Why is JSON problematic exactly? |
Beta Was this translation helpful? Give feedback.
-
|
You need to open a new file to know something is happening, I don’t speak about hydrate/prerender properties; and unless there is a plugin that analyze and notify (just in case of error), you have to open the file. I come from the Java world, years ago xml was used to configure, today it’s decorators with annotations through the compiler. |
Beta Was this translation helpful? Give feedback.
-
|
I find a JSON config file both very standard and way more intuitive than the current proposal of using folders with parens in them and all the other route gymnastics. |
Beta Was this translation helpful? Give feedback.
-
|
While I might be late to the party (hopefully more than 3 days of discussion is being given to important changes like these though), I find that the current system of named layouts is, in a word, gross, and this new proposed system does little to improve. I think this is where the filename magic in kit started to get out of hand, and moving away from using filenames as an API is better for readability, tooling, and offers more flexibility in the future. Current and older systemsGoing back to a time before named layouts, you were restricted to two options:
This system was quite simple, and for many apps was perfectly sufficient. The issues came with keeping code DRY, since layout resets required you to put all of your layout code in one file, unable to take advantage of the fact that you've already written that code before. Resets were also an all-or-nothing solution which lacked control and could end up being very clunky with larger, more intricate apps. With the introduction of named layouts, all of this was flipped on its head, since they offered so much control over how your layouts were inherited. With so much flexibility, however, came a loss of simplicity. Many experienced devs, as well as myself, are left head scratching trying to remember what the rules are for where layouts can inherit from, and "where the heck is this layout defined," and shoving layout inheritance into filenames made it frustratingly opaque to debug. I wouldn't call it a nightmarishly complicated task, but constantly running into issues like that could definitely put a damper on one's workflow. Design considerationsThe fundamental question when designing systems like these is where to place the balance between simplicity, consistency, and flexibility. Layout resets excelled in the first, named layouts excelled in the last, and I think that a new system should strike a balance between these. An important realization is that (applying the classic 80/20 rule) ~80% of your code is going to use only ~20% of the available features. It's going to be much more common in most, if not all apps, that pages will not need to break out of the classic layout nesting system. Knowing this, a new system should preserve the trait that the majority of cases will be the simplest to deal with. The point in contention is how to handle the abnormal, more complex, and special cases in need of fine control, while also striking that balance between simplicity and flexibility. I think many people here make a good point by acknowledging that layouts run double-duty in a kit app, being integral to both the render tree and the load tree. These two systems are often, but not always, correlated, so I don't see a need to completely separate them. The current My proposalWith a lot of fluff out of the way (mostly to get my own brain warmed up), here's how I think layouts should be designed and used. For the simple cases where layouts are neatly nested inside one another and load functions are called in nice succession (assuming
Now for the real meat of the proposal: how to break this system. If you stop to think about it, layouts are really just components with a slot and some extra magic behind the scenes. Why not take inspiration from the way we use components? This has the advantage of being easy to understand for those who have learned svelte before kit, and provides a consistent syntax. I propose that in order to break out of the classic layout nesting, one would import a layout just as they would import a regular component, and then use it like they would use a regular component. Since there are already methods available to generate an import tree without actually running the code, this seems like it falls within the constraints of "statically analyzable". Here's an example, where <script>
import FeaturedLayout from 'src/routes/blog/+layout-featured.svelte'
</script>
<FeaturedLayout>
<h1>Here is where your specific code for this layout</h1>
<slot></slot>
</FeaturedLayout>Note that the named layout syntax is used, but only to disambiguate this from any other layouts you happen to have made. The contents of the layout filename are completely arbitrary and don't affect how it's used, as long as it starts with The classic layout nesting could also pick up from wherever the layout is imported from, in this case checking for layouts in In order to keep the import tree from being a complete free-for-all, there should be restrictions about where layouts can be imported from. One potential idea: layouts can only be imported from directories that are direct parents of the current directory, which includes the Note that having an actual import statement in the file makes many things much easier. First, it completely removes the ambiguity of "where is this layout coming from". Second, and more importantly, it makes it much easier to use existing tooling to its full extent. While I can't speak specifically to the design of kit tooling, I predict that analyzing filenames to look for the layout name, then digging through the filetree to find the layout is a hassle. How the heck should you display something like a "this layout does not exist" error anyways if the error is in the filename? This is probably why (afaik) there is exactly zero tooling out there that understands these kinds of "imports" inside the filename. For how much emphasis was put on enabling nice tooling during the routing rework, it's being conveniently ignored here. One issue that I also see with this new proposal is that the one-to-one correspondence between the directory tree and the route tree that was emphasized so much during the routing rework is ditched. This is a regression. Plain and simple. To deal with the last remaining piece of the puzzle, I propose that a utility import be added to <script>
import { BlankLayout } from '@sveltejs/kit'
</script>
<BlankLayout>
<slot></slot>
</BlankLayout>
Possible drawbacksI acknowledge that there may be a few drawbacks with this proposal. First, the importing of a Next, and closely related to the previous, could using layouts as if they were components cause confusion about what can and can't be done with them? For example, things like putting layouts inside There's still a lot of open questions about the fine details of implementing a big change like this and whether parts of it are feasible. I hope that Rich and the rest of the team can at least give this some thought, as I think I've been clear about what the advantages of such a system could be, and what the disadvantages are of showing even more of the API into filenames. |
Beta Was this translation helpful? Give feedback.
-
|
Using layouts through imports is unfortunately not statically analyzable in a good fashion that handles more complex use cases. What if you have it nested inside an By the way, there is nothing stopping you from using the layout composition that way. You can create a reusable UI component for layouts X and Y and do the same for a export function load(event) {
return reusableLoad(event);
}<script>
import ReusableLayout from '$lib/ReusableLayout.svelte';
export data;
</script>
<ReusableLayout {data}>
<slot />
</ReusableLayout> |
Beta Was this translation helpful? Give feedback.
-
|
This proposal is ok for me, maybe I can comment on a few things, but folks here have already done it. #6183here, I need a place where I can init i18n, and it should be called globally, after any #6196if I want to have a separate During the discussion for this proposal, don't forget that for each |
Beta Was this translation helpful? Give feedback.
-
|
@danawoodman But for #6196 still I need to create almost empty files? (with reimport my shared load function) |
Beta Was this translation helpful? Give feedback.
-
|
That's true, but it requires no additional API. Regardless what API we choose, there will always be cases where you have to resort to things like composition, which may feel boilerplaty but is simple to understand. Under the proposal, it may also be possible that you can create your two root layouts by having two groups at the root like this: |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I will try, maybe it's not so bad. |
Beta Was this translation helpful? Give feedback.
-
|
@stalkerg what are you replying to? You mean my suggestion of using a config file? |
Beta Was this translation helpful? Give feedback.
-
|
@danawoodman it's was to @dummdidumm |
Beta Was this translation helpful? Give feedback.
-
|
Thank you everyone for participating in the discussion! After careful consideration, reading all the alternative proposals and much discussion internally we decided to go with the original proposal, as it - in our opinion - strikes the best balance between simplicity and handling more complex use cases. What became clear from the discussion is that the use cases vary drastically and that it's close to impossible to design an API that satisfies them all in a consistent way that is easy to learn. It also became clear that whatever API we land on, people feel somewhat compelled to use it because "that's what the framework gives you" - even if other means such as composition or a simple if-statement somewhere in your layout would solve the problem more easily. We hope to make it more clear in the docs that you are encouraged to find your own ways if you don't want to use the |
Beta Was this translation helpful? Give feedback.
-
|
I'm curious, why add this at all at this point if there is so much resistance to it? Is the rationale that we need to make all these big changes before we get to v1.0? To me it would be better to not make a change and let things play out a bit before rushing the gun on something so divisive. Couldn't a solution be added post v1.0? |
Beta Was this translation helpful? Give feedback.
-
|
We could only add it if it was non-breaking, this was a breaking change. Furthermore, we didn't feel there was big resistance to the change - the proposal had many thumbs up and alternate proposals like JSON or named layouts v2 didn't feel like they were completely contrary to what the original proposal had (and some just didn't work with the restrictions we have). I fully understand that it's tough to go through all these breaking changes in such quick succession right now, but the end is in sight. |
Beta Was this translation helpful? Give feedback.
-
|
I'm astonished at how fast such a huge change was proposed, discussed, and then implemented. I mean I happen to quite like it — even with a fairly simple use-case (2x authenticated layouts & an unauthenticated layout, all sharing data) named layouts were a pig — but I do feel like these large design changes should somehow be surfaced and dogfooded better. Idk I guess that's difficult when sveltekit is barrelling so fast towards a finalised 1.0 API, but as a user I feel like I JUST did a major refactor I didn't have a chance to think about and I'm gonna have to turn around straight away and go do another one now. I know it's all pre release so I did this to myself, but damn the ride is getting rocky. Bundling some of these huge changes up and communicating them in a more cohesive way to developers would be v helpful EDIT — Just refactored for layout groups, and it made my route structures so much clearer, and auth guards simpler, so I'm a big fan. But regardless the feedback about the rapid succession of poorly communicated breaking changes causing friction in the community stands Still this basic app structure is a thing of beauty 👌🏼 |
Beta Was this translation helpful? Give feedback.
-
|
I understand that one could feel that way, but we don't just do this to check a box, we are genouinly eager for feedback. Note that most people who read it will either go "yeah that works" and close the discussion, or go "that's great!" and put a thumbs up in there, then close - most of the time only those who are opposed to it or have an alternate proposal will make a discussion post, which makes it seem like the reception is negative. We've read all alternate proposals carefully, some wouldn't work due to technical reasons, some would not satisfy other constraints like predictability or more ability to code yourself into a corner. We discussed these and looked if the alternate proposals could be worked into the original proposal, but that wasn't working without making things ambiguous or less learnable - which is why we stuck with the initial proposal. |
Beta Was this translation helpful? Give feedback.
-
|
I think the point is it doesn't really give people sufficient time to read, consider and respond in anything but a hurried fashion. Many people aren't even aware of the changes at all until they have suddenly appeared. If you happen to be free to be looking at the Svelte repo that day, you might see it and have chance to respond ... if |
Beta Was this translation helpful? Give feedback.
-
|
After opening the routing RFC and the forms RFC, I personally have been bombarded with 'when will it be ready?' messages via tweets, DMs and so on. They say you can please some of the people all of the time and all of the people some of them, but not all of the people all of the time, and that is never truer than in open source! On a macro level, we're under pressure from the community to reach a stable release, and that necessitates breaking changes. I just don't know what alternative approach to gathering feedback from the people motivated to give it could be better than an Keeping discussions open has diminishing returns: there's a decay function in effect, and — empirically — the discussion tends to get less useful after the initial wave of responses. Meanwhile, there's a real cost to delaying, apart from the mini-Osborne effect that happens when people know changes are coming. Often, resolution of one design question unlocks the resolution of others; there are many chunks of work that simply can't happen when you know that changes are coming to the affected part of the codebase. Implementing this change in particular removed a significant amount of technical debt that has allowed us to make progress on a swath of issues, which would otherwise have remained open needlessly.
I take issue with that — the routing proposal evolved significantly as a result of the discussion, and forms are still up in the air because the discussion is ongoing. But in this case it was clear that there no real workable alternatives; by adopting groups we are adopting a solution that has been proven to work with Remix, and will be part of a future Next version, which validates the design choice. (Neither Remix nor Next has the 'breakout' mechanism, however.) I understand that there's a lot of turbulence right now, and if there was a way of making progress towards 1.0 without that being the case I would take it. Unfortunately there just isn't a way to make everyone happy. I wish there was a kinder way to say this, but this is the price of using pre-release software; we're all paying that cost now to reach a better 1.0 sooner. We do our best to make the changes as manageable as possible (with migration guides and informative error messages), which honestly I feel like a lot of open source projects at this stage wouldn't bother with, but if there are concrete suggestions for how we can make them more so then we would definitely like to hear them. |
Beta Was this translation helpful? Give feedback.
-
|
My take on this - if someone is really interested in what's going on, he/she can turn on notifications for discussions. I am deleting more than hundred mails related to discussion notifications on a daily basis. And I can't say there isn't/wasn't enough room or time for discussion. |
Beta Was this translation helpful? Give feedback.
-
|
All we're asking for is letting these things "soak" longer so more people have a chance to be aware of them and voice their feedback. A few days just isn't reasonable, no matter the medium or how many people thumbs up the original post. We all appreciate the strong push to 1.0. I, for one, can't wait for the API to stabilize so I can help "spread the SvelteKit gospel". I'm just asking that some more time is given between announcement and merge. (And it's worth reiterating that I genuinely appreciate all the core teams contributions and I know you all have to deal with a hell of a lot of comments, criticism and more. The reason we're so vocal is because we really care about (nay, love) this project.) |
Beta Was this translation helpful? Give feedback.
-
|
When there is a change like this there should be a greater effort to gather input and slowdown to find a more palatable solution for the community over a longer time period . I actually really liked the layout system when their wasn't named layouts and wish there was still an option to use that system for less complicated uses. I generally don't like pushing logic into the filenames and feel like that is the wrong way to go. I would prefer having a another configuration file that specifies the routing grouping as an alternative solution. Can there be a poll on discord / here for this or other controversial proposals in the future? |
Beta Was this translation helpful? Give feedback.
-
|
You don't need to use groups to create layouts, you can still put them into your folder like before. You can also rewind to earlier layouts by referencing their folder name, all without groups. This change replaced the named layouts in favor of groups, but the simple layout solutions stayed the same. |
Beta Was this translation helpful? Give feedback.
-
|
Looking at the updated docs, i see this: The URL's to access these pages are this: so we have routes that are actually in the same subdirectory to access, but don't live in the same folder am i understanding that correctly? |
Beta Was this translation helpful? Give feedback.
-
|
its for complex layout management. So I think the correct way is to stick with the old way and only opt in to this new way when you find that you are trying to hack the layout system to achieve something. |
Beta Was this translation helpful? Give feedback.
-
|
@harrylaulau I was using // +layout-admin.server.js
import { redirect } from "@sveltejs/kit";
export async function load({ locals, url }) {
if (url.pathname !== "/admin/login" && !locals.user) {
throw redirect(307, "/admin/login");
}
return {
user: locals.user
};
}I've re-organized my routes to use the new |
Beta Was this translation helpful? Give feedback.
-
|
I think It should be more straightforward for your use case 😂👍🏻 |
Beta Was this translation helpful? Give feedback.
-
|
@acoyfellow if you use that layout only inside that |
Beta Was this translation helpful? Give feedback.
-
|
@dummdidumm thats good news, thank you. Not sure how I missed that. |
Beta Was this translation helpful? Give feedback.
-
|
I am okay with the new changes in the routing system, makes my routes easier to reason about because I can group routes to now use the same layout. Excellent work done. FWIW, it would be very helpful if we can version the docs to sync with new updates. I keep the docs opened in multiple tabs only to scroll down to the named-layout section and its gone, I tried updating the package.json with Not everyone follows I really love the work you guys are doing here with a strong emphasis on Keeping It: SvelteKit Simple. Thank you so much for Svelte and SvelteKit are heaven-sent blessings, so invaluable |
Beta Was this translation helpful? Give feedback.
and others
-
Update: The decision has been made, thank you for participating in the discussion!
The sense I've had from recent discussions is that people don't really like how named layouts work. And I kind of agree — a file with a name like
+layout-foo@bar.svelteis doing a lot of work, and the inheritance rules (layouts can inherit from sibling layouts indefinitely, but if they don't specify a parent (wait — is it a parent or a sibling?) then they will go one directory higher to continue the search, unless you want them to inherit from the default layout at the current level in which case you can specify@default, which is a reserved name) are a lot to try and understand.It's a powerful and flexible system, but it's not intuitive, and common tasks (grouping some-but-not-all siblings with a custom layout, or breaking out of the layout hierarchy to the root) are unnecessarily cumbersome.
Beyond that, the fact that it's possible for a directory to contain multiple different layouts adds some unavoidable complexity. For example, because there's no canonical root layout that everything is guaranteed to inherit from, we don't have a place to put code that gets run for every single page, or apply universal CSS. (We often talk about creating a dedicated client entry point — the equivalent of
src/hooks.jsbut in the browser — that is responsible for hydrating the app and importing global CSS and e.g. firing analytics events on navigation, but there'd be no need to introduce a new concept like that if we had a root layout.) Implementation-wise, the extra complexity in the codebase is also a source of sadness for me personally.Can we do better?
The two jobs of custom layouts
Fundamentally, there are two reasons to use custom layouts:
/aboutand/testimonialsmight be 'marketing' pages, while/dashboardand/itemare 'app' pages and/adminis neither)<slot />file), but possibly to something lower down. For example/item/[id]/editmight need to break out of the app layout or theitemlayout within it.A lot of this can be achieved within a layout itself, by doing this sort of thing...
{#if $page.data.blank} <slot /> {:else} <div class="layout"> <slot /> </div> {/if}...but it's less scalable, and only applies to the UI (rather than the
loadfunctions that apply to different layouts).Here's how we'd achieve the structure above in our current system:
There's a lot going on here: four layouts in
src/routes, three of which inherit from the base+layout.svelte(and one of those three,root, is just a<slot />since it only exists to give a way to reference the root layout from/item/[id]/edit).The nice thing about this approach is that the directory structure maps perfectly to the routing structure, but everything else is bad: 'app' and 'marketing' are expressed three different ways (once per route that uses them, plus once in the name of the layout); lexical ordering means that app/marketing pages are interleaved, which in all likelihood doesn't correspond to the placement of shared modules, or the human factor of code organisation (i.e. that the 'marketing' pages are likely owned by a separate team to the 'app' pages); the weird
@rootthing. Making sense of the hierarchy is just really hard.Job 1: groups
An obvious way to solve the grouping problem is with a directory that doesn't add a route segment:
It's subjective, but I find this much more obvious. All the
(app)and(marketing)code is co-located (and that would extend to any shared modules or components, which would currently have to go insrc/libotherwise they'd clutter up the root directory), and it's easier to trace the 'flow' of layouts from tip to root.Since all this applies to data loading as well as UI, it's also very easy to add an
(authenticated)guard or similar — just add an(authenticated)/+layout.server.jsfile with aloadfunction that throws anerrororredirectif the user isn't logged in.Job 2: breaking out
Technically, it's possible to achieve everything with just groups, by having sibling hierarchies:
...but this is monstrous. Given how often this is necessary, it's worth having a more idiomatic solution. As long as we're using the filesystem to define custom layout hierarchies (on which, see the 'what about' section below), then this necessarily involves adding some syntax to filenames, but it doesn't need to be as much syntax as we currently have.
Currently, you have to declare a layout in some parent directory to act as an 'anchor', which means we need the
-fooconstruct. But this is unnecessary, because we already have a perfectly good way of identifying the parent level to which we want to 'ascend' — the segment names themselves.For example if we wanted to use the
clayout in/a/b/c/d/[e]/+page.svelte, we don't need to declare a+layout-cinside thecdirectory — we can just... usec:To ascend straight to the root layout, we can just omit the name altogether —
+page@.svelte. So our more realistic example becomes this:src/routes/ ├ (app)/ │ ├ dashboard/+page.svelte │ ├ item/ │ │ ├ [id]/+page.svelte + │ │ └ edit/+page@.svelte │ │ └ +layout.svelte │ └ +layout.svelte ├ (marketing)/ │ ├ about/+page.svelte │ ├ testimonials/+page.svelte │ └ +layout.svelte ├ admin/+page.svelte └ +layout.svelte+layout@whatever.sveltewould reset to thewhateverlayout for everything in its subtree.Downsides
The main drawback of this proposal is the way the directory tree no longer maps 1:1 with the routing tree. Finding the code for a specific route becomes very slightly harder. Reasonable people can disagree about how major that is.
A corollary is that it becomes more possible to introduce conflicts (between
(foo)/whateverand(bar)/whatever), though the framework can easily throw a helpful error in that case.What about
export const layout = ...?A common question: why does it need to be expressed in directory and filenames? why can't we having something like this?
One answer is that SvelteKit really needs to be able to resolve the layout hierarchy statically, and with layouts expressed in JavaScript it's impossible to guarantee that. If it can't be determined statically, then SvelteKit needs to load the leaf node (
+page), then find out which layout it references and load that, and repeat, all the way back to the root one at a time.By constrast, when we know the layout hierarchy statically we can load all the pieces concurrently, resulting in faster apps.
There are other options — we could add a
+config.jsonor something. But it's honestly hard to see how that's an improvement.What about existing named layouts?
+layout-name.svelteetc would no longer exist under this proposal, so it's not additional API, rather it replaces the existing API.Thanks for reading this far! Feedback welcome 🙏
Beta Was this translation helpful? Give feedback.
All reactions