Repository navigation
[feature request] Add 'params' prop to the 'A' component #216
Description
Describe the bug
Not a bug, it's a feature request.
I think that it would be nice to add a params prop to the A component, for example:
<A href="/users/:id" params={{ id: userId }} />I'm proposing this for 2 reasons:
- It seems like a nicer and more maintainable API when working with an object containing all paths. For example:
<A href={routes.user} params={{ id: userId }} />- This would be a nice combination with named routes proposed here Add named routes #61
This is the API I'm thinking about:
<A name="user" params={{ id: userId }} />When working with named routes there must be some way of providing params.
An alternative API could be
<A href={{ path: routes.user, params: { id: userId } }} /><A href={{ name: 'user', params: { id: userId } }} />Your Example Website or App
Steps to Reproduce the Bug or Issue
Expected behavior
Screenshots or Videos
No response
Platform
Additional context
No response
Activity
Exelord commentedon Dec 11, 2022
Interesting take. I was working on named routes implementation these days and was looking for a interpolable API.
The alternative API is exactly what I came up as well.
hrefcould be responsible for determining the URL based on path string or RouteQuery object.the object is a "find a match" description. It could precise name, path and/or params, making it very flexible, as well as it allows to easily pass a link reference without API split.
So I am +1 on thi solution :)
We could also leave
<A>just a basic primitve and extract this logic to a helper function eg:buildURL()that could be even more flexible and non-locking option
We would need to expose then 2 functions from the router API.
orenelbaum commentedon Dec 11, 2022
What I like about having a separate
paramsprop is that it would be really easy to switch between a simple route, for exampleto
and vice versa.
It's also a bit cleaner imo.
But it doesn't matter to me that much.
As for the
buildUrlfunction, I think that it might be a good idea to add this function regardless.And we already have a function to detect whether a path is active or not,
useMatch, unless I'm misunderstanding you.Also in other issues I proposed adding an options object as the second argument to
useMatch, so maybe we could have it take params as well:Exelord commentedon Dec 17, 2022
Yes, that's exactly what we need. The same way, we could have
buildUrlworking:buildUrl('users/:id', { parsams: { id: 2 } })Having this API would even allow to build named routes on top.
Im wondering if it would be possible to use those functions without a need for context 🤔
orenelbaum commentedon Dec 17, 2022
Why not
buildUrl('users/:id', { id: 2 })?Is there anything else that you can see going there other than params?
I mean making it an options object is more future proof but I don't really see what options we could potentially add.
Exelord commentedon Dec 17, 2022
Good question. Yes, the route can be described as well by QueryParams which are separate from RouteParams. There might be also a need for other route's descriptors, like history state.
ideally I would love to see it as a self contained object that has all the information to identify a route. Similarly like you send an API request to a search endpoint, or do DB query.
That way you will be able to specify wide or exact, route you need.
Putting the path into this object would be also nice, as that would ease the named routes integration as well.
orenelbaum commentedon Dec 19, 2022
That's a good point.
Btw apparently tanstack router also has a
paramsprop on its<Link>component.ryansolid commentedon Dec 19, 2022
It's probably to do with how it matches routes by ids which are essentially the router registered path. I've had these APIs before routers Ive created before. However, I really like how minimal
Ais overa.