Build adapters for integration with redux

[roninjin10]

In the documentation it is explained that react-query handles remote data and not client side data. It says there are usually no issues with using it alongside redux.

In my use of react-query and similar libraries like React-Apollo, I have found this to be the case. However, I don't see any reason why React Query can't act as a middleware for remote data and plugin any local state management tool.

The state the application and redux might care about is stored in QueryCache instances and by proxy Query instances. These are already pluggable today because a custom query cache can be injected into the QueryClient constructor.

What we could do is simply create a 3rd party package that acts as an adapter between redux and react-query and stores these states within redux. The query state would be stored in the redux store. React-query then would essentially wrap redux. queryClient would then be thought of as the proxy used by the application code to both read state and dispatch actions. QueryClient.prototype.getQueryData and similar APIs operate now as state selectors. QueryClient.prototype.setQuerydata operates now as an action creator. And QueryClient.prototype.fetchQuery would be thought of an action creator dispatching to a redux middleware analogous to dispatching an action to redux thunk. The react hooks for react-query such as useQuery would live alongside react-redux.

The adapter would connect reactQuery to the redux store with a custom middleware.

The benefit of this would be niche to very specific applications (like the one I currently work on) who make heavy use of the redux store. Most applications would be best off just using the default queryCache. For this reason I think this makes sense as a third party package rather than being part of react-query core.

[TkDodo]

The benefit of this would be niche to very specific applications (like the one I currently work on) who make heavy use of the redux store.

I don't really see a benefit in this. If you are using redux with hooks, you can join useSelector and useQuery as you like:

const currentId = useSelector(selectCurrentId)
useQuery(['something', currentId]), () => fetchSomething(currentId))

The state the application and redux might care about is stored in QueryCache instances

the other way around also works:

const query = useQuery('something', fetchSomething)
useSelector(state => state.somethings.filter(it => it.id === query.data?.id))

all of this works best when done with custom hooks of course, so you'd likely write more custom hooks than selectors, but it would likely be easier to reason about than syncing state back and forth between redux and a query cache

[roninjin10]

For our application we have more complicated use cases than this. Our local state and our query states are coupled in ways where using something that is flux would really helps out.

I don’t think it’s correct to say I’m syncing state back and forth between redux. By using redux in a queryCache, the state lives in redux and redux is the one and only source of truth here. The state doesn’t live in react query and then get synced to redux which would be bad.

[TkDodo]

Don’t want to steer you away from react-query, but if you really want your server state to live in redux, rtk-query might be a better fit. Have you evaluated it?

[roninjin10]

Thanks for pointing me towards rtk-query! I don't believe it existed when I first started using react-query a year or so ago. Though I will look into rtk-query more, I still think this idea is a good idea. From digging into react-query source code I don't see any downside or potential issues with custom QueryCache instances using redux, mobx, a plain javascript object, or whatever state solution one prefers under the hood. And there are tons of upside. Similar to connected-react-router, it's simply a way to have your cake and eat it too when it comes to the decision of using react-query or redux.