Assuming you meant Redux Toolkit (RTK) Query there.
FWIW, the stance of both the Redux maintainers (myself and Lenz) and the React/TanStack Query maintainers (Tanner and Dominik) is:
- If you're using Redux at all, prefer using RTK Query
- If you're using just plain React, prefer using React Query
but don't write data fetching and caching logic by hand :)
There _are_ some API and philosophy differences between RQ and RTKQ. RTKQ emphasizes defining "endpoints" up front, and generates React hooks based on those endpoint definitions. That approach also helps enable codegen from OpenAPI and GraphQL schemas. RTKQ also has some unique capabilities around cache lifecycles that enable use cases like streaming updates:
(I'll also note that we have an `<ApiProvider>` that automatically sets up a Redux store for you internally, so you _can_ use RTKQ if you're not already using Redux in an app.)
FWIW, the stance of both the Redux maintainers (myself and Lenz) and the React/TanStack Query maintainers (Tanner and Dominik) is:
- If you're using Redux at all, prefer using RTK Query
- If you're using just plain React, prefer using React Query
but don't write data fetching and caching logic by hand :)
There _are_ some API and philosophy differences between RQ and RTKQ. RTKQ emphasizes defining "endpoints" up front, and generates React hooks based on those endpoint definitions. That approach also helps enable codegen from OpenAPI and GraphQL schemas. RTKQ also has some unique capabilities around cache lifecycles that enable use cases like streaming updates:
- https://redux-toolkit.js.org/rtk-query/comparison#unique-cap...
(I'll also note that we have an `<ApiProvider>` that automatically sets up a Redux store for you internally, so you _can_ use RTKQ if you're not already using Redux in an app.)