Allow same params in route/url => would have a much nicer DX and make routing so slick, with an example

[205g0]

Describe the problem

now: /users/[user-id]/blog-posts/[blog-post-id]

cons:

• clunky to look at
• clunky to read
• clunky to write
• Not DRY
• Refactoring tables leads to double renaming of folders and more loss of git history than needed

Describe the proposed solution

/users/[id]/blog-posts/[id] and accessing them either via an array { id: [4545, 9898] } or some other way, edit: this is TBD and more suggestions in the thread!

pros:

• way nicer folder structure
• terse and beautiful
• easier to read
• easier to write
• easier to refactor, e.g. change of a table name would need only one folder to be changed but not two
• DRY, I mean which other id should follow a resource?
• Might enforce more compliant REST urls, newbies wouldn't let resources be followed by other potential ids which are not the primary key (or some proxy id)

Alternatives considered

You could work-around today by appending an index, e.g. id0, id1, etc. but that wouldn't be as slick

Importance

nice to have

Additional Information

No response

[gtm-nayan]

You could work-around today by appending an index, e.g. id0, id1, etc. but that wouldn't be as slick

id[0], id[1] and having to discern whether id is an array or a single property is more "slick" to you?

[205g0]

id[0], id[1] and having to discern whether id is an array or a single property is more "slick" to you?

Since you access them only in a respective route handler with a limited scope and their appearance is always close to their entity, e.g. users.id == id[0] instead users.id == user-id, yes, it's absolutely slick

And it's optional, you can still name you params as clunky as before and they do not return as an array, so it's even not a breaking change

[205g0]

I mean, we could go one step further and auto-generate a proper object with keys from the resource, then the access would be a bit nicer (but maybe this would go too far but why not haha), e.g.:

paramsDX = {
  users: {
    id: ...
  },
  'blog-posts': {
    id: ...
  }
}

[Conduitry]

I'm not a fan of this. The fact that adding a second id would suddenly change the first id from a string to an array is confusing.

[205g0]

The fact that adding a second id would suddenly change the first id from a string to an array is confusing.

How we gonna access them is something we can work on. The folder structure would significantly benefit in any case and would be reason enough to brainstorm for a better access solution once.

So, the current suggestion we have:

1. Make an array in case duplicate of params, non-breaking, type would be string | [string, ..string[]]
2. Introduce a new params object "deluxe" which returns an object with sub-objects with the params, e.g. accessible via params.users.id, non-breaking or breaking if params would be replaced
3. Stitch resource and id together (either as camelCase, snake_case or dashed) in case of duplication or always, too much magic for my taste but we'd get params.usersId which actually looks not too bad
4. We could take a users custom function for params prop creation and the default one defaults to the current implementation

Maybe you have any better ideas?!

[205g0]

I've one more pro:

Just think of how many times you look at your folders in VS Code (or nvim), in the explorer side bar/file tree, in the bread crumbs at the top of panes or in Quick Find where you need the path to identify a file because of all the generic +page.svelte, files etc. The current verbose params bloats all these views with redundant resource names in brackets for no reason.

So, we look a gazillion times on our folder structure day in and day out but how often do we read or work on a handler? Not as often, so every compromise there would justify aforementioned. And I'm sure we'd find something way better than a lousy compromise for access if we try hard enough haha.

[dummdidumm]

I'm also against this. Explaining the details of how the params change their type from a string to an array, and type-checking and guarding against it, is much worse than having to come up with slightly bigger names. Therefore closing.