Feature Request: Query/Search Params

[Rykuno]

Describe the feature in detail (code, mocks, or screenshots encouraged)

Request: A rune to conveniently parse and interface with the query/search params.

Current Solution: i'm using https://sveltekit-search-params.netlify.app/ everywhere.

Why: We end up utilizing search params quite a bit. Tab navigation, page state, search queries and so on. Would be super convenient to have this along with the debounce rune work together as well.

What type of pull request would this be?

New Feature

Provide relevant links or additional information.

No response

[huntabyte]

Maybe this is something @paoloricciuti would be interested in?

[paoloricciuti]

Lol i just published this

https://github.com/paoloricciuti/sveltekit-view-transition/issues/43

i would not be opposed to merge the project into runed but i wonder what could be the way forward:

1. sveltekit-view-transition as the name suggest uses a sveltekit api while runes seems more svelte oriented...i think without interacting with goto and the page store (or state in the future) the code can get very hairy and possibly conflict with sveltekit.
2. the library has quite a few users already so if we end up merging this how to deal with old users?
3. as you may seem in the codebase of sveltekit-search-params there are quite a few edge cases so i worry of the complexity that this could add to runed being basically a whole library rather than a simple utility.

[TGlide]

Lol i just published this

https://github.com/paoloricciuti/sveltekit-view-transition/issues/43

i would not be opposed to merge the project into runed but i wonder what could be the way forward:

1. sveltekit-view-transition as the name suggest uses a sveltekit api while runes seems more svelte oriented...i think without interacting with goto and the page store (or state in the future) the code can get very hairy and possibly conflict with sveltekit.
2. the library has quite a few users already so if we end up merging this how to deal with old users?
3. as you may seem in the codebase of sveltekit-search-params there are quite a few edge cases so i worry of the complexity that this could add to runed being basically a whole library rather than a simple utility.

TBH I'm not opposed to having SvelteKit only utilities. We just need to mark them well, maybe add some tags! We can experiment together 😄

[Rykuno]

^ I'd love to see this and splitting up client/server utilities would be really nice.

The majority of use cases we run into as well are client side as some backends are in Laravel/Node and SvelteKit is not used more than half the time. Even to start out a simple rune to subscribe to search params could be largely beneficial as we have written our own at this point. I'm really joyful to see this collaboration.