feral abyss
I have my routes setup like the following:
/customers/$customerId/ (customerRoute)
/customers/$customerId/orders/$orderId (customerOrderRoute)
When I try to navigate from the first route using a <Link from={customerRoute.fullPath} to="orders/$orderId" params={{orderId: "123"}}>, I'm getting an error that customerId is required.
So I think the solution here is to pass a callback for params, according to the docs the current params will be passed into the callback:
params={(prevParams) => ({...prevParams, orderId: "123"})}
In order to preserve the customerId. Seems a bit odd to have to do it that way, and I feel like that defeats the purpose of relative routing, but I guess it works.
cyan garnet
Hmmm, that's interesting.
It likely worked using the callback method, since it then knows that customerId is defined in the prevParams.
Its likely because the callback approach merges the data being committing, whilst the initial approach tried to commit it immediately.
feral abyss
Agreed, but I feel that the advantage of relative pathing is that I don't need to specify the path parameters again, so I guess my question is, is this a bug or is it just not built that way?
cyan garnet
@feral ferry what do you think about this?
feral ferry
@feral abyss can you please provide a minimal example?
The reason I ask is that relative navigation seems to be broken (See also https://github.com/TanStack/router/issues/1066)
I just tried to reproduce your route setup and I get
Object literal may only specify known properties, and 'fooId' does not exist in type '(current: {} & { invoiceId: number; }) => never'.ts(2353)
feral abyss
Yeah, let me try reproduce it in a standalone project
feral ferry
I have a fix for this: https://github.com/TanStack/router/pull/1163
this makes path params optional that exist in the from route
this needs further testing of potential side effects though.
@cyan garnet please have a look
cyan garnet
I have a fix for this: https://github.com/TanStack/router/pull/1163
this makes ...
Yea, if the from props is provided, then it makes sense for the params to be optional since we can assume they either want the existing ones or want to merge'n'replace with new ones.
Is this the same logic being used with useNavigate already?