Array as keys?

Now I’m using svelte-query but I’m not happy with it: it has not-so-convenient APIs (@benbender is working on it, but the maintainer is not so active, so I doubt it will change in a short time).

After the “fix” for Svelte Kit I’m trying sswr.

The first “issue” is about the query keys. Svelte-Query also allows you to use an array of keys for use cases such as pagination or filtering, you know… https://sveltequery.vercel.app/guides/query-keys.

What do you think about?

Is it so hard to add?

[benbender]

afaik your swr wont run again in react if some fetcher dependency changes. Only if you specify it on the key array and using the value provided in the fetcher function’s param will re-trying that update.

Yes and no 😃 swr runs again, but it doesn’t fetch again because the logic is wrapped in useCallback().

https://github.com/vercel/swr/blob/3bbbf5b86be0868963c12906816a7bc1ded84c15/src/use-swr.ts#L245

Thing is that all those “hooks” like useEffect(), useState(), useCallback() etc in React are basically methods to rip bits and pieces of code/state out of the normal react-rerender-flow to make them stateful. It’s, more or less, a band-aid to have statefulness in functional components in react. Thats exactly what’s happening here.

The beauty of svelte is that it gets rid of all those band-aid-concepts react introduced - and we are used to - for the past several years 😃

About array-keys: they aren’t only used for dependency-tracking but also to differentiate different results of requests and group requests with context. So there would be a benefit having something like that…

[benbender]

quick note on my efforts regarding react-query: I’m thinking about abandoning my efforts as I start to realize that its not a great fit into the sveltekit-ecosystem in the first place. It replicates state-handling and reactivity where it isn’t needed in svelte(kit) because both are built-in. And react-query is therefor quite heavy in relation to sveltekit itself… Most use-cases of react-query should be achiveable with much less code.

I’m also generally start to questioning the whole idea of explicit caches for queries/mutations on an app-level, as it is basically a duplication of the builtin http-caching in browsers (at least for everything http-related). F.e. preloading is a breeze with sveltekits routing and even could be supported by the built-in support for service-workers. So there is basically only a small margin of cases where a solution on the app-level seems to be worth the effort anyways (given that the api, you are trying to reach, does http-caching right).

Oh, and I would love to see solutions for svelte which embraces the approach of sveltekits sample-todo-app, which leverages basic http to handle forms with progressive enhancement and are even working without js at all…