search

modernweb-dev / rocket

The modern web setup for static sites with a sprinkle of JavaScript
https://rocket.modern-web.dev
MIT License
368 stars 51 forks source link

[Feature] Dynamic Routes #284

Open daKmoR opened 2 years ago

daKmoR commented 2 years ago

https://nextjs.org/docs/routing/dynamic-routes

jaydanurwin commented 2 years ago

Although I do appreciate the simplicity and "magic" of 11ty's approach to dynamic routes/page templates with collections it does feel a little too abstract. I'd like to know what's really going on under the hood which is why I personally would lean more towards Astro's approach with getStaticPaths() (I think largely inspired by NextJS) and dynamic routes. I feel like I understand what's happening much easier and have a lot more flexibility.

The only complaint I've had so far with Astro's implementation is that it only allows a file parameter to be used once at each level of the file tree. For example, if I have [slug].astro at the base level of pages to generate CMS pages at the root level of the site I can't have another file that uses a slug parameter. I'm not sure what a better implementation would be because I'm aware you can't have two files named [slug].astro or [slug].rocket.js at the same level.

The only hacky solution I've found is to map over all of those queries that need to be in a base level [slug].astro file and conditionally treat them differently inside of the 1 file. This can get pretty messy when you have several different types of pages all needed to be at the base level of the site. I can go more in depth on this if needed with examples but basically there is a limitation on using the same parameter twice unless it's nested in a different folder.

Let me know if you have any questions I can expand on because this is probably the most important feature for me and my team at my agency to even attempt to start testing Rocket internally.

daKmoR commented 2 years ago

I can't really follow 🙈 You want to have files like pages/foo/[slug]/bare/[slug].rocket.js?

Maybe you can describe what the ideal API would be?

something in the line of ...

jaydanurwin commented 2 years ago

Haha no worries, it was difficult for me to communicate without a better concrete example. Maybe a better example would be with blog URLs. Let's say we have a blog post template and a template for blog post categories/tags but I don't want the URLs for those to be /blog/posts/example-post or /blog/category/category-page, instead I'd like the urls to both be written to /blog/example-post and /blog/category-page. Both the blog posts and the category have a slug field coming from the CMS so technically they both would need a [slug].astro or [slug].rocket.js file.

That isn't easily done with Astro's current implementation for getStaticPaths() because you would need 2 [slug].astro files under the /blog/ and obviously you can't have 2 files with the same name next to each other.

Maybe there isn't really a fix with the file parameter option to do this but I do know with 11ty it's no issue because I can just set the permalink value to /{{ slug }}/index.html in 2 different files with no issue. Personally, I would still choose the file parameter option even if we didn't find a way to make this example work because I still think it's better.

I hope that helps!

jaredcwhite commented 2 years ago

I like file-based routing with placeholders along those lines for server-rendered code paths where you do expect to process incoming params a lot and figure out what to do from there. But for content itself and certainly for static rendering, I much prefer the idea of permalink metadata (front matter, etc.) attached to the content determining its final destination.

As a sort of in-between, I also worked on a concept called Prototype Pages for Bridgetown where you can place a file somewhere in your source tree, but the filename itself gets swapped out by the slugified term it finds out of a set of terms. So for instance taking from your example, maybe you'd create within your source tree blog/categories.ext (.ext being whatever template engine you use), and then that would get statically built out to final URLs /blog/first-category, /blog/another-category, etc. And there'd be no conflict with actual posts which get built into /blog.

I have no idea if that idea could apply in some way to Rocket, but thought I'd share the prior art.