Deeper integration with React Query itself?

[Ionshard]

As you mention in the docs Zedux doesn't fully replace react-query. Currently we are using react-query and I am looking for a better way to handle our client side state. I have seen a lot of recommendations for zustand and we are experimenting with that.

However a common need we have is to create derivative data that is a combination of client and server state. A kind of toy example would be if we have a text input and the result does client side filtering of a list of data from the backend. In this case we have the list of widgets managed by react-query and the current filter managed by Zustand and we want a derived list of widgets filtered down by the current filter.

With Zustand we either duplicate the data from react-query into the Zustand store which is not recommended. Or we must do the derivation outside of the store in a custom hook which is a valid solution but now we can't take advantage of Zustand any longer and must operate in pure hook land. It looks like Zedux with the extreme amount of power it gives you might be able to bridge this gap.

Has there been any work done to see about integrating react-query into Zedux? If not, is this something that would make sense? I have done a cursory read through on the documentation and I will probably start playing around with this idea but wanted to see if the experts can see a huge caveat that I am missing.

My thought is that it would be great to make either an atom factory or a custom injector that allows you to retrieve data from React Query's cache. This way we could create a derived atom that consumes both the list of widgets from react-query and the current filter from a different atom and then return the filtered list of widgets.

Looks like all the plumbing is available. I can create a React Query QueryObserver to subscribe to changes to the query data to update the atom's store. I know technically I would be duplicating the state from the cache into the atom store but with Zedux this could all be done "behind the scenes" so you can't forget to do it like you can with Zustand. This would allow us to use useQuery directly in simple components that don't need complicated state management, but for components that do need complicated state we can use Zedux to orchestrate all our state management including server state while still keeping all the awesome benefits that React Query provides that Zedux doesn't (yet?)

Is there anything obvious that I am missing on why this might be a bad idea or might not work?

[bowheart]

Hey! Great question. The approach you outlined sounds fantastic. No, there shouldn't be any huge caveats you're missing. Just, as you said, if you want to be able to reactively use the React Query data inside atoms, that data will need to be duplicated.

Zedux is designed to be able to integrate with other libs via intermediary atoms like this. I haven't explored it with React Query specifically and it's been a few years since I worked with React Query. But relevant: We migrated from Redux by using a very simple reduxAtom that looked something like this:

export const reduxBridgeAtom = atom('reduxBridge', () => {
  const storeRef = injectRef<Store>()

  const dispatch = (action: Action) => storeRef.current?.dispatch(action)

  return api((undefined as unknown) as AppState).setExports({
    dispatch,
    storeRef,
  })
})

Where that cast to AppState is the state shape of the Redux store. Then we instantiate the atom and populate its state in a top-level component where we also create the Zedux ecosystem and Redux store. Something like this:

function App() {
  const reduxStore = ... create redux store ...

  const rootEcosystem = useMemo(() => {
    const ecosystem = createEcosystem({
      id: 'root',
    })

    const instance = ecosystem.getInstance(reduxBridgeAtom)
    instance.setState(reduxStore.getState());
    instance.exports.storeRef.current = reduxStore;

    reduxStore.subscribe(() => {
      instance.setState(reduxStore.getState());
    });

    return ecosystem
  }, [reduxStore])

  return (
    <EcosystemProvider ecosystem={rootEcosystem}>
      <Provider store={reduxStore}>
        ...children...
      </Provider>
    </EcosystemProvider>
  )
}

I'm sure this is all translatable to React Query. In fact with React Query's QueryClient and QueryObserver, you can do all of this completely outside React. There are maybe even cleaner ways to do it too that don't require the ugly type cast. If I get some time tomorrow, I'll try to put together a real example using React Query for you.

the awesome benefits that React Query provides that Zedux doesn't (yet?)

😄 That "yet" is something I've been saying for a while. I do think it's likely that we'll make Zedux a full replacement for React Query someday. There aren't any current plans for it.

Zedux is already a full replacement for us with its ttl, query atoms, and using injectEffect combined with RxJS streams. But our apps are full socket-powered with no current need for React Query's other goodies like pagination and infinite scroll. Still, I think we'll have need of some of those over time and will get around to a @zedux/query package someday.

[bowheart]

@Ionshard I made some time for it this morning. Here's a codesandbox demonstrating using a reactQueryBridge atom to sync React Query's state with the atoms universe:

https://codesandbox.io/s/react-query-zedux-basic-zv9kty

It uses React Query's QueryCache to sync all of React Query's data with Zedux. But QueryObserver, QueriesObserver, or manual filtering logic inside the QueryCache subscription could all be used to sync only a few specific queries instead.

[Ionshard]

Wow ... I just wanted to know if I was crazy. This answer is above and beyond! I will be inspecting that sandbox closely! Thank you so much for the super in-depth response.

We have an API library generating our react query hooks to have type information generated from our backend's OpenAPI spec so we do have the types for every query and every query key. I bet I could further work this to infer the types from one of our generated types so we keep the advanced types from React Query. Oh boy, this is going to be fun 😄

[Ionshard]

We are also migrating away from Redux ... so I might steal that example too 🤣