Via this Stack Overflow question. It would be nice if there was a way to do optional parameters — e.g. /foo, /fr/foo and /ca/fr/foo all resolving to the same page component (where fr is a named lang parameter and ca is a named country parameter).
@Timer from the Next.js team had a neat idea — we could mark optional parameters with double brackets: routes/[[country]]/[[lang]]/foo.svelte
At the same time, it might be nice if routes/[...parts]/foo.svelte matched all those pathnames. At present it will match /fr/foo and /ca/fr/foo but not /foo.
I had not thought of routes/[...parts]/catchall.svelte... but I _really_ like that.
To have routes/[...parts]/foo.svelte match /foo would we use the optional syntax: routes/[[...parts]]/foo.svelte?
It could be that, or it could just mean that parts is always a zero-length array for /foo. Not sure if I have a preference, honestly
I absolutely want this. It would simplify my search pages significantly - filesystem routes are not ideal for SEO!
I just tested this on my filesystem and it does seem to work - but it's not extensive, obviously!
/routes/[country?]/[lang?]/foo.svelte
Next.js landed support for this with the following syntax:
pages/foo/[...rest].tsx
The above matches:
/foo/bar
/foo/bar/baz
/foo/this/keeps/going/forever
But does not match:
/foo
To match /foo, and all above routes, you can use:
pages/foo/[[...rest]].tsx
I absolutely want this. It would simplify my search pages significantly - filesystem routes are not ideal for SEO!
I just tested this on my filesystem and it does seem to work - but it's not extensive, obviously!
/routes/[country?]/[lang?]/foo.svelte
@antony How did you get this to work? Did you have to modify Sapper source in some way? I tried doing the same thing, e.g.
src/routes/[region?]/foo.svelte instead of just src/routes/[region]/foo.svelte
and the compiler returned this error:
Unexpected token (Note that you need plugins to import files that are not JavaScript)
162: pattern: /^\/([^\/]+?)\/?$/,
163: parts: [
164: { i: 1, params: match => ({ region?: d(match[1]) }) },
^
165: { i: 2, params: match => ({ region?: d(match[1]) }) }
166: ]
And if you did have to modify Sapper source to get this to work, what is the workaround you are currently using? Thanks in advance! 🙏
I believe Antony was just saying that he was able to create directories and files named like that on his filesystem.
Linux is indeed fine with that, and I don't know about macOS, but Windows definitely won't let you do that.
@jhwheeler it's been more than a year since I did this, I can't remember.
If you're working on Windows, you might try under WSL
Oh I see what you mean. I thought he meant that he got it to work with Sapper, not just the naming convention.
So is there any plan to support this feature? It seems to be quite essential for SEO purposes. Or perhaps if anyone has an idea for a workaround, that would be cool too :D
If there isn't such a plan and no workaround, what do you guys think of this approach: https://github.com/sveltejs/sapper/pull/780 ? I saw you closed it, but I didn't see an alternative way forward on this.
If you're up for a different approach, I could implement something; my team and I are quite keen on having this feature.
@Conduitry @antony Do you have any suggestions on how we could improve upon the approach from #780 so we can get this feature? Like I said we are really keen on this and would love to make a PR; just want your input on design decisions and to know more or less what direction you want to take.
@jhwheeler my own approach at this time would be to open a RFC, link all of these issues, and detail:
I think from there you'd be in a good position to gather any required feedback, resistance, etc, in order to create a PR to add the syntax.
@antony Awesome, thank you for the detailed instructions! I will do exactly that. 🙏
Most helpful comment
I absolutely want this. It would simplify my search pages significantly - filesystem routes are not ideal for SEO!
I just tested this on my filesystem and it does seem to work - but it's not extensive, obviously!