[Feature Request / Question] Search Params at the Layout Level
Opened this issue · 6 comments
Hi There!
Thanks for tackeling this problem! Really cool way of approaching it and giving ownership 🙌 Also thank you for all the time on your videos too; Learnt so much over the years!
I have a use case that I wondered if there was already a way to support or if there was any desire to do so? 🤔
In some cases you may want to add a Search Param that can be used anywhere below a certain level in the routing tree, and not sure how to handle this.
For example if you have a client side Modal that you include in layout.tsx at the root level, say to show Notifications ,and it's open state were stored in the URL search params of any route below it like /profile/edit?showNotifications=true or /?showNotifications=true it would be cool to be able to merge that possible search param into all type definitions for routes underneath.
This may take the form of being able to add a layout.info.ts file that defines shared params for the routes below it? Or would there be a better way to handle this?
(p.s. also aware there may be a different way of approaching the example using intercepting routes server side too but I'm actually less of a fan of the modal client side, full page on bare URL navigation convention for some use cases... Maybe some more learning required for me!)
I think you can accomplish this with zod.merge. Have you shared search param schema stored in globally accessible module. Then zod.merge it into each route that has those shared search parameters, along with whatever unique search params the route has. And if it doesn't have any, then just use those global search params straight.
Yep - Figured I could do it manually editing each page.info.ts (using .merge) but means you have to remember to add it to each new page added etc as the default build step would be oblivious.
Was wondering if there was a better way but guess it would add a new level of complexity to the library having to know about a hierarchy...
I'd be ok with adding a level of complexity to get the hierarchal nature of the routes... if it was for more than just this one use case.
I'll have more of a think too, but one to see if others were interested in too then!!
How do you go about telling - Is it worth keeping open and looking for +1's in the form of up votes, or happy to see if people find it in closed?
Sure. Thumbs up the original comment and if we get a bunch we can do it. Though the how would come only after we have some more use cases. So if folks could also comment with other use cases for hierarchal routing that would be great.
Also, are we talking about NextJS, React-Router, or Qwik? Please don't say "all" unless you mean that. What is your specific platform that you are writing in?
For my case it is Only for Next.js I'm working in! 👍