[✨] Qwik-query ?

[cesarve77]

Is your feature request related to a problem?

I was reading and testing Qwik I and very impressive and exciter about it.
The only missing part I can see now is have a fetch library like react-query.
TanStack/query#5700

Describe the solution you'd like

TanStack/query#5700

Describe alternatives you've considered

TanStack/query#5700

Additional context

No response

[maiieul]

Out of curiosity, what benefits do you see in using tanstack query with Qwik?

I have been thinking about this a little bit, and I am not sure query brings much benefits when using SSR with loaders and actions. With loaders and actions, you not only get qwiker performance, but you also don't need to worry about managing loading states (:wave: spinners), and if my understanding is correct you may not even need to worry about client-side caching since the page is pre-loaded with all the html/css and the browser can just make use of it's built-in cache. Besides, I'm quite confident that implementing things like debounced inputs, optimistic updates or pagination aren't much harder with loaders and actions. The only missing piece in Qwik at the moment I see is deduping requests. Remix does handle it, so Qwik might in the future if it doesn't already. If this whole approach wasn't better in many ways, I doubt tanstack would be working on tanstack loaders and tanstack actions 😅

Now, you may have a few reasons to run your app with CSR/SSG/ISG. Personally I have tried running Qwik with Capacitor (which requires an index.html file as part of CSR for better app store approval) to make it work on mobile, and I was missing an API for client-side data-fetching. Something like "Qwik-Query" could do the trick, but I think it would be even better to have an extended API for loaders and actions that would work server-side and client-side, potentially with an API similar to React's Suspense. This would give us an amazing DX by allowing us to use the same API when using SSR and CSR and SSG/ISG. This would allow us to write our app with the same code for our website (with SSR or SSG/ISG) and for Capacitor or Tauri apps (with CSR).

Meanwhile, if you don't care about CSR/SSG/ISG, I believe you'll be fine without tanstack query.

[KelechiOdom10]

@maiieul I agree for the most part we wouldn't need to use tanstack-query with Qwik but as you say there are situations this would be beneficial such as working on mobile. Another instance would be having the ability to invalidate queries for data that becomes stale after a mutation, this would allow you to trigger background-refetching and help update your client optimistically.

What do you think?

[maiieul]

Another instance would be having the ability to invalidate queries for data that becomes stale after a mutation

You're right that this is not doable with cache control headers (https://qwik.dev/docs/caching/). At least to my knowledge. Stale-while-revalidate with cache control headers works well for static pages where it's not a big deal to serve stale content to one user.

But this doesn't necessarily mean that tanstack query is the only solution that can solve the query invalidation problem. Qwik-city actions could have it too. I would love if we could find a way to take advantage of the built-in browser cache-control such as stale-while-revalidate and still be able to invalidate stale data 👀

[omerman]

I made something like this for a project of mine
you are welcome to use it and make it your own :)

[gioboa]

We moved this issue to qwik-evolution repo to create a RFC discussion for this.
Here is our Qwik RFC process thanks.