"Home" folder that can handle "/" route.

[danielimmke]

Most SPAs have a "homepage" (sometimes more than one - a marketing one and one for logged in users) but I don't believe the new system accounts for this as a discrete concept. So your homepage ends up being the +page.svelte at the root of the /routes/ folder. Then you have to conditionally check if you're on the homepage or not, and it's messy.

I would propose the ability to have a page folder just like all the others, but specifically designate it to handle the base "/" route. This would make it easier to keep things organized.

Apologies if there is already a way to do this that I just don't know about.

[aloker]

Just create a folder named (home) and put +page.svelte there - done!

[danielimmke]

I understand it's possible to do this under the current system, but to me it violates the spirit of the routing system.

If "Home" is a discrete page, conceptually the same way that "About" is, you should be able to create a page folder for it. It's convention on the web to serve a site's homepage at the / route. That makes this an edge case worth addressing. A simple option to enable in that folder like serveAtRoot = true

What you're suggesting would confuse a lot of people - because routes/(home)/+page.svelte would actually serve as the top level page template for all routes. It feels like a workaround.

Then if you wanted to set other globals, you'd have to do like routes/[topLevel] or routes/[...path] which makes things way more confusing, in my opinion.

It makes sense to be able to set global defaults for your app. That's why we can put files like page.ts and +page.svelte directly under the routes folder. But without addressing this edge case, we have to use those defaults for homepage specific things. Just because it's in the (home) folder doesn't change that those files affect everything. It makes it worse - imagine being new to Svelte and trying to find the base page.ts file only to learn that it's tucked in (home)/page.ts.

[vnphanquang]

I would propose the ability to have a page folder just like all the others, but specifically designate it to handle the base "/" route. This would make it easier to keep things organized.

@danielimmke sorry for my ignorance, if I understand correctly, you're saying is it'll be messy to put your homepage inside a group layout and it violates the routing system. But i'd argue it's the same to have a serverAtRoot = true for some random folder?

---

Then you have to conditionally check if you're on the homepage or not, and it's messy.

Then if you wanted to set other globals, you'd have to do like routes/[topLevel] or routes/[...path] which makes things way more confusing, in my opinion.

I'm not sure I follow these sorry. Can you give a more concrete example? why would you need to check if you're on the homepage, and how does your proposal solve this issue?

I'd personally not have multiple conditional homepages, SPA or not (although i understand if it's a project constraint that is not up to developers). Once you do that, I don't think there is any good way to avoid conditional rendering or confusion.

[danielimmke]

The purpose of (group) folders is when you have several routes at the same "level" but want them to have a different layout/template.

In this scenario, we don't have several routes. We have one route: /.

I can't do routes/(homepage)/+page.ts and routes/(app)/+page.ts or routes/+page.ts. Svelte would say they conflict.

So if I put my custom homepage in a (group) like: routes/(homepage)/+page.svelte what am I actually accomplishing aside from making the folder structure a little easier to read for people who already understand this routing system? Any +page file I put inside (homepage) is going to be used as the top level default for the entire routing system. Where you can set settings like if you want the page to be prerendered.

And if the homepage is a page - just like "About" would be a page, why do I have to treat it so differently?

Yes, you can explicitly handle other routes through other means, but any scenario where you do that is way more complicated than being able to set a simple flag in a folder. What is the point of having a system where these routing files "bubble up" to the top if you can't actually use them that way? I'd prefer to be able to have a +page.ts that can work as a catch-all

But i'd argue it's the same to have a serverAtRoot = true for some random folder?

Yes, this would violate the pure mechanics of the folder based routing, for one specific edge case that is very common that I outlined in my second reply. But to me, being able to set a folder to handle the / route would be more in line with the goals/aims of the routing system and less confusing to new users.

[vnphanquang]

@danielimmke thanks. I think I understand that part about group layout being not helpful for your use case here.

What i'm still concerned is how a serverAtRoot config solve your problem of having homepage and app at the same path /? What is the interface you're thinking of? Say you have two folders homepage & app that will have serveAtRoot set to true, how do we set which to render? What is the relationship between homepage/+page.ts and app/+page.ts, or +layout.tss?

This is basically moving the "conditions" that you have to check manually from your code into framework code, plus some config that a user still has to set. It might become easier for a few of us, but i think certainly not for maintainers, since they'll have to cover a lot more edge cases that this change might bring about.

Again, I'd prefer not to have multiple "pages" within the same path. In the case there's no choice, I'll make these "pages" into components and have a if elseto conditionally render them. But i assume you have already thought about that. To me, render conditions in SPA are not unconventional...

[infovore]

I don't fully understand what you're asking. src/routes/+page.svelte is the file that defines what appears at /. Why do you need to "conditionally" check if you're on the homepage? If you're rendering that template, you're rendering the root path. This is just following the principle of Kit's directory based routing: src/routes/ is a valid directory for that.

I'm not saying "no you're wrong!"; I just am not sure I've full understood the complaint, especially the 'conditional' part of it. Can you give a more thorough example?

[danielimmke]

I've tried to outline it more thoroughly in another reply, so please check that thread. I hope I've at least made myself understood, even if people disagree with this idea. I don't think I will be the last person to raise this concern.

[infovore]

thanks, Daniel, will read.

[aloker]

Personally, I don't see how the homepage is in any way special wrt routing.

src/routes/+page.svelte maps to /. Each subfolder (if we ignore route groups for a second) maps to a sub-segment (like /about, /info, etc.)

Likewise:
src/routes/items/+page.svelte maps to /items. Each subfolder maps to a sub-segment like /items/bike-1234, /items/helmet-1413

If src/routes/+page.svelte bugs you, why doesn't src/routes/items/+page.svelte?

Here are a couple of screenshots:

It's pretty clear, that +page.svelte is the root route. Now let's dive into items, which is basically identical structurally:

I hope you see the symmetry. I fail to see how the top level +page.svelte is (and should be) in any way different from the one in items. On the contrary, I would find it really confusing. IMHO, The routing system is complex enough as it is. BUT it is consistent - something that couldn't be said if / was treated specially.