Q: Regarding the sharing behaviour of query params between routes
My question is regarding the sharing of search query param values across path routes.
This is the route setup I've got.
rootRoute
| / -
index.ts index route
| agreements - agreements.path.ts path
| / - agreements.index.ts index route of 'agreements'
| reservations - reservations.path.ts path
| / - reservations.index.ts index route of 'reservations'
Both the index routes of 'agreements' and 'reservations' have a validateSearch zod schema of:
and a preSearchFilters functions of on both index routes of 'agreements' and 'reservations':
Currently,
* if I am on /reservations?page=2
* and click on a link that ONLY has the following prop of to='/agreements' on <Link />
* it takes me to /agreements?page=2 instead of /agreements?page=1.
Q1: Is this expected behaviour?
Q2: To get it to go to /agreements?page=1 I should explicitly provide the following of to='/agreements' search={(s) => ({ ...s, page: 1 })} to <Link />?3 Replies
stormy-goldOP•3y ago
Not looking for any changes to the package here, just want to confirm the mental model I'm working with.
extended-salmon•3y ago
Your result is expected, but I can see how that's... not what you'd want.
Let me think on this more.
It might be that search filters should only get applied if they are shared between the origin AND the destination
That would add some complexity though.
It's almost like the
page param from one isn't really equal to the other
I'll need to think on this
It's almost like filters need to have modes
source: 'all' | 'sibling' | 'descendant' or something like thatstormy-goldOP•3y ago
It may not be needed, but then I guess it'll be use-case-specific.
Like if I'm storing the entire application ui states, then I'd probably want the current behaviour so no matter what route I go to everything is being passed around.
For me, I was only having this issue on my app header navigation, and I just set the intended default values on the <Link /> components. Plus, I currently very explicitly control what gets set to the params using the
preSearchFilters so I don't really run a chance of this kinda thing happening too often.