TanStack Query VS react-apollo

@tanstack/react-query

A common convention I've seen is using T at the start of a type parameter, [1] for example. TKey, TData, TError, TSuccessCallback, etc. I always liked T at the end, but I've not seen that as often.

[1] https://github.com/TanStack/query/blob/59a6d3df3035d6effeaed...

Tables are most commonly used to render database query results — in modern times, the output of an ORM. In this post, I'll introduce a way of connecting Prisma - the most popular TypeScript ORM, to React Table, with the help of React Query and ZenStack. You'll be amazed by how little code you need to write to render a full-fledged table UI.

I was interested in how nested React and TanStack useSuspenseQuery worked together. The small app below is a visualization of various combinations of and TanStack Query.

To ensure that we get the best TanStack Query experience possible we are also encouraged to share feedback and participate in the discussion on GitHub, which you can check out here!

I trust you found this information beneficial. For further details, please refer to the conversation on this GitHub issue here

Tanstack - Tanstack has evolved to an entire ecosystem consisting of the famous Tanstack (or React) Query, Tanstack Table, now also Tanstack Router and Tanstack Form. It started with Tanstack Query, which adopted Nx and Nx Cloud. Zack talked about this collab with Dominik, and we also had Dominik on our Nx live stream. Now, all the above-mentioned Tanstack libs have adopted Nx, and there's more coming.

"I’m building SQLSync because I want to make client-side applications easier to build without us having to reinvent the wheel each time."

Kinda ironic no?

Anyway, since the article is also about React, I can't recommend enough React Query [1] if you don't want to worry about caching data to reduce calls to the database and managing/refreshing stale data. It simplified so much my job.

[1] https://tanstack.com/query

This apollo issue matches my problem: https://github.com/apollographql/react-apollo/issues/2866

We’re heavy users of Apollo GraphQL in my team at Swarmia, but sometimes mocking the queries is bothersome. And based on a few GitHub comments, it looks like we’re not alone. This blog post is here to help!

I'm using the awesome https://github.com/apollographql/react-apollo library and I'm trying to see if there is a better convention to load data into components than how I'm doing it now.

Hello guys, I'm working with GraphQL using Apollo Client and facing a big issue but haven't found a fix yet. The problem is with fetchMore callback. This trigger twice, one is the original call, second is the call with new variables. But onComplete only return the response of the original one. When I use nextFetchPolicy: "cache-first" it not trigger the original variables anymore, but the onComplete doesn't return the result of new call. I've looking for a solution on the internet and found this: https://github.com/apollographql/react-apollo/issues/2177 But a few years passed and there aren't any explain or fix. It makes me nervous about choosing apollo client for long-term usage. Can you suggest a client that still has maintainers?

React Apollo fits perfectly the requirements, and it now supports Hooks for your GraphQL operations.

I've been using Apollo for a couple of years now, and it is infamously nebulous when it comes to moderately complex real-world scenarios, such as parameterized queries. There are many years-spanning github issues on this problem alone, with barely any maintainable solutions proffered. I've written a lengthy guide that explains exactly how Apollo's InMemoryCache works under the hood and how to sanely solve these caching issues.