search

svecosystem / runed

Magical utilities for your Svelte applications (WIP)
https://runed.dev
MIT License
387 stars 21 forks source link

Feature Request: Query/Search Params #71

Open Rykuno opened 2 months ago

Rykuno commented 2 months ago

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

Maybe this is something @paoloricciuti would be interested in?

paoloricciuti commented 1 month ago

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

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

^ 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.