[feature request] Add 'params' prop to the 'A' component

[orenelbaum]

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

[Exelord]

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. href could 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()

declare function buildUrl(query: RouteQuery): string;

that could be even more flexible and non-locking option

We would need to expose then 2 functions from the router API.

1. a fn to interpolate a path with params and QP
2. a fn to detect whether a path is active or not

[orenelbaum]

What I like about having a separate params prop is that it would be really easy to switch between a simple route, for example

<A href={routes.user} />

to

<A href={routes.user} params={{ id: userId }} />

and vice versa.
It's also a bit cleaner imo.
But it doesn't matter to me that much.
As for the buildUrl function, 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:

useMatch('/users/:id', { params: { id: userId }})

[Exelord]

Yes, that's exactly what we need. The same way, we could have buildUrl working: 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]

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]

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]

That's a good point.
Btw apparently tanstack router also has a params prop on its <Link> component.

[ryansolid]

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 A is over a.