Feat: do not type search parameters globally in vite-plugin-kit-routes

[kran6a]

It is easier to maintain if we keep parameters definition on the route themselves rather than as a global config.

They can be typed on +page.ts files via the config export.
It would also allow configuring a search param on a layout and have all child routes inherit it.
Note that you can do export type config rather than export config and that you can export a type and a variable with the same name simultaneously so exporting a type should not cause problems for anyone already using export config.

Aditionally, I think we should also type the hash part of the url and that search parameters and route parameters should not be passed in the same object as you can't have a route like /config/[tab]?tab=1, which may seem like an odd route despite being a valid one, but that would require a breaking change.

[jycouet]

It is easier to maintain if we keep parameters definition on the route themselves rather than as a global config.

In some cases yes, in some other, I'm not sure. I'm building a lot of apps without +page.ts.
But I like a lot the idea 👍

They can be typed on +page.ts files via the config export.
It would also allow configuring a search param on a layout and have all child routes inherit it.
Note that you can do export type config rather than export config and that you can export a type and a variable with the same name simultaneously so exporting a type should not cause problems for anyone already using export config.

I'm feeling that it's almost a ""hack"" to do it that way. You would export the type without a capital C ?
What about export type _SearchParams ?
What do you think ?
You want to code something ? Or let me look at it ?
How urgent ? 😉

Aditionally, I think we should also type the hash part of the url and that search parameters and route parameters should not be passed in the same object as you can't have a route like /config/[tab]?tab=1, which may seem like an odd route despite being a valid one, but that would require a breaking change.

Hummm, got it ! Interesting one. I would not recommend for code readability, but you are right, it's possible ^^
In case of a collision, we could be explicite in the searchParam ? Like

{ tab: "a", sp_tab: 1} 

We should probably split in 2 issues