Repository navigation
Introduce TanStack Query #104
Description
In a far future, we'll have to consider adding caching to our API calls. The simple browser APIs for caching dont allow developer friendly handling of invalidating caches. One proven library that is known for its developer friendliness and cache controling is TanStack Query.
https://tanstack.com/query/latest
Getting Started:
https://tanstack.com/query/latest/docs/framework/svelte/overview
Activity
dklOrdix commentedon May 8, 2026
Also consider wrapping the listBucket call with the new TanStack Query Client.
#104 add tanstack query cache
lfrancke commentedon May 8, 2026
Unfortunately I'm on vacation starting in... a few hours, but: Adding this is something we should at least briefly discuss. It's "just one" dependency but architecture wise it's a bigger decision.
Do we really need it? IIRC TanStack is a React library first and foremost. I mention this because I tried using parts of it (not Query!) in the past and the Svelte adapters took months to catch up making newer releases unusable, breaking code. I don't want to solve a theoretical problem.
So pushing back slightly: Do we really need this now?
dklOrdix commentedon May 8, 2026
Yes, TanStack originated from a pure React Library. However their solution became so popular that a demand for other frameworks was created. Since version 6 of Tanstack Query, Svelte v5 is supported, including a whole refactoring of the depracted Svelte Stores to the new Svelte Runes.
Caching is one big part of TanStack Query. But: Also invalidation and mutation of data, window events (what should happen on windows focus loss?), pagination, simpler refetch apis, data stale time control. They offer developer friendly apis for this out of the box. Thus, we can already benefit from this heavily, for our delete/upload functions that do modify the data and would trigger refetch calls on success.
We can also benefit from their easy to use hydration APIs. Currently we rely heavily on the server side of Svelte to serve us the Data. However, in a scenario of bigger size, this can then lead to longer states in which nothing happens on the frontend-side. Requesting fewer data via pagination is one way around this, but we can further optimize this already at an architecture level by building our app/feature with loading states in mind.
dklOrdix commentedon Jun 2, 2026
A week ago or so I had a look what actually changes when we would use TanStack Query. Yes we do have benefits of using TanStack Query in terms of dev experience and ease of use. However, TanStack Query introduces fundumental changes to how the SvelteKit App would work, introducing more dependence on client side rendering. This would cause headaches on handling more cases of loading/error states instead of using SvelteKits Error fallback pages.
Therefore i close this ticket for now. maybe this is something that we still need to have a look at, but for now it causes more problems for us than we can benefit.