search

jycouet / kitql

A set of standalone tools to SpeedRun WebApps!
https://kitql.dev
MIT License
409 stars 37 forks source link

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

Open kran6a opened 1 month ago

kran6a commented 1 month ago

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 commented 1 month ago

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