Use react-query as a context provider for local data

[dpyzo0o]

React-query is very powerful when managing remote data fetching, but I also find that it's somehow very convenient to use it to share local state. I came up with a pattern for this use case, you can play with it here

import React from "react";
import { useQuery, queryCache } from "react-query";
import "./styles.css";

export default function App() {
  return (
    <div className="App">
      <h1>Shared state using react-query</h1>
      <Comp1 />
      <Comp2 />
    </div>
  );
}

function useSharedState(key, initialValue) {
  const { data: state } = useQuery(key, () => queryCache.getQueryData(key), {
    initialData: initialValue
  });

  const setState = value => queryCache.setQueryData(key, value);

  return [state, setState];
}

function Comp1() {
  const [count, setCount] = useSharedState("count", 1);

  console.log("comp1 rendered");

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>add</button>
    </div>
  );
}

function Comp2() {
  const [count, setCount] = useSharedState("count", 2);

  console.log("comp2 rendered");

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>add</button>
    </div>
  );
}

Basically here react-query is used as a global state manager, I want to get some comments/suggestions for this pattern. Because I notice some unnecessary renders with this pattern, see below

Each component is rendered 4 times and I don't know why this is happening, maybe related to the initial data?

Thus I would like to ask if I use this pattern a lot in an app, is it going to have some perf issues?

[dpyzo0o]

Anyone interested?

[naomei]

@dpyzo0o

I also come across a situation where I want to use react-query as a simple global-state.

It is written elsewhere that it is not a use case, but I feel that there are still necessary scenes.
(I think vercel's swr is relatively easy to implement, but I personally prefer react-query.)

[morellodev]

Though it works, this is not the use case react-query has been built for. There are other libraries highly optimized for managing the state globally, here I list just a few:

• Recoil from Facebook
• Zustand from the react-spring team

[smooJitter]

Have used both. What’s your preference?

[tommmyy]

and redux

[TkDodo]

() => queryCache.getQueryData(key)

I thought the fetchFn passed to react-query needs to return a Promise...?

All in all, I don’t see the need to use react-query for synchronous client-state. Zustand is pretty good at that.

[JuanmaMenendez]

Though it works, this is not the use case react-query has been built for.

Why add another library if we can have this in react-query too? For example Apollo Client supports this https://www.apollographql.com/docs/react/local-state/local-state-management/

Something like "reactive vars" would be definitely a great feature for react-query

[Karthik-B-06]

https://codesandbox.io/s/vigilant-jennings-j21km?file=/src/App.js
@dpyzo0o
I have handled the local state with react-query, storing an object, and minimizing the component re-renders.
While it can be used to manage the local state, I think it can get cumbersome with complex objects.
I don't think it was ever intended to use this way, but as it's fetcher agnostic, it can still fetch from my store.
@tannerlinsley what are your thoughts on using react query for something like this?

[TkDodo]

Why add another library

react-query is good at a manager for async state (promise based). Even if you just return data directly, you will still get:

• 1 render in loading state
• 1 render in success state with the data

what would you need all the good features of react-query for with client state? Background updates will needlessly re-render your component two times (isFetching transition), and you'd not want auto garbage collection either.

So you'd need to customize your queryClient to opt out of everything that RQ gives you, by setting staleTime and cacheTime to infinity and you'd need to use initialData. And even then, you'd still have an inferior manager for synchronous state because you need to invent unique keys for no benefit.

zustand is about 800 bytes minzipped, has a great api, supports one or multiple stores, is composable, scales and checks all boxes for a great client state manager.

For years, we've made the mistake of treating every state equally by treating our server data like client state. We've finally realized that this is sub-optimal, because they have different needs. Let's not make the same mistake again in the other direction by wanting to do everything with react query please :)

[JuanmaMenendez]

@TkDodo that feature could be implemented differently/''outside" the main react-query features, like a utility function the library provides, Apollo Client reactive variables is the perfect example https://www.apollographql.com/docs/react/local-state/reactive-variables/

I am sure zustand is great (and small) but still an extra dependency and another library to learn.

[TkDodo]

what's the difference between having to learn how createVar works vs how createStore from zustand works? If I were to add this feature right now, I would add zustand as a dependency to react-query and re-export it 1:1. I couldn't find a more performant, scalable and bundle-size friendly solution if I tried :) Everything else also means additional maintenance effort, getting typescript type right etc for really no advantage...

[gitcatrat]

@TkDodo I'm split on this. react-query local state shortcomings are so small and easy to fill in and we already have 100 different packages and APIs to learn and maintain, why add a new one? But yeah, e.g valtio is probably 100 times better than RQ would be in most basic form.

[ivan-kleshnin]

@gitcatrat I personally disagree with @TkDodo though I 👍 this article: https://tkdodo.eu/blog/react-query-as-a-state-manager
I agree with the inputs but not with the conclusion.

react-query is good at a manager for async state (promise based). Even if you just return data directly, you will still get:
1 render in loading state
1 render in success state with the data

That's easy to suppress with notifyOnChangeProps: "tracked",

So you'd need to customize your queryClient to opt out of everything that RQ gives you, by setting staleTime and cacheTime to infinity and you'd need to use initialData.

Create custom hooks to hold the complexity.

function useAlerts() {
  return useQuery(["_alerts"], async () => Promise.reject("...should never be called..."), {
    initialData: [],
    staleTime: Infinity, // this data/cache will be updated manually
    cacheTime: Infinity, //
  }).data
}

function Component1() {
  const alerts = useAlerts()
  // will be updated when alerts change
  ...
}

function Component2() {
  const alerts = useAlerts()
  // will be updated when alerts change
  ...
}

function Component3() {
  // won't be updated when alerts change

  const queryClient = useQueryClient()

  React.useEffect(() => {
    queryClient.setQueryData(["_alerts"], ...) // change global alerts
  }, [])

  ...
}

And even then, you'd still have an inferior manager for synchronous state because you need to invent unique keys for no benefit.

I wouldn't call this solution "inferior" just because it doesn't have gimmicks like reactive vars. Every option that reduces a bundle size and a list of dependencies is at least worth considering.

Cache keys are just paths to data fragments. Just a longer variant of smth. like global.alerts.

---

In my experience React-Query is good at representing global states of easy-to-intermediate complexity. Consider that many people still use ad-hoc context-based global states which are objectively worse (...one shared subscription per context).

To model, e.g. an interactive game state I would look for something more advanced. But many web apps don't need that.

[TkDodo]

That's easy to suppress with notifyOnChangeProps: "tracked",

good point, it will also be the default in v4.

Create custom hooks to hold the complexity.

yep, totally possible.

Consider that many people still use ad-hoc context-based global states which are objectively worse

Also true. I use context only for things that rarely ever change for dependency injection, but not for state management.

Every option that reduces a bundle size and a list of dependencies is at least worth considering.

zustand has 954b minzipped. At some point, this should become irrelevant :)

---

The points that remain for me are:

• no type safety when calling queryClient.setQueryData
• const alerts = useAlerts() will still be potentially undefined, unless you do type assertions or use the bang operator in the custom hook.
• having to manually manage query keys to make sure they don't overlap.
• the fact that you need a queryFn that should never be executed is 🤯

[ivan-kleshnin]

the fact that you need a queryFn that should never be executed is 🤯

I added that line to highlight that () => queryCache.getQueryData(key) code is not even necessary.
To feel safe about corner cases and potential library changes I'd surely pick getQueryData over throw.

In general, I accept your counter-arguments, thanks for replying! Type Safety is sometimes tricky to achieve in R-Q.
In my experience, the problem is minimal if I don't forget to provide explicit types:

const [alerts] = useGlobalState<Alert[]>(["alerts"]) // alerts are typed!

In which case it's not really different from how we typically use basic useQuery.

zustand has 954b minzipped. At some point, this should become irrelevant :)

You'll probably need Immer which is another 5.6 Kb minzipped. And Redux-Devtools (in dev mode).

And yes, another downside of NOT using React-Query as a single state manager is that you'll need 3 different devtools (chrome, redux, r-q) instead of 2.

I dunno, I'm probably on the minimalist side of things. Or I just don't like Zustand API 🤷

[Martynas-K]

HI!
So I'm late to this thread, but I had this almost exact same idea independently and found it's already discussed here.

I'm relatively new to RQ, and I understand the reasoning against this, but I also think this could be considered in some use cases.

For example, we have a small project where almost all state comes from the server and RQ handles it perfectly. But there's a couple of props the user selects on client side and they are needed throughout the app, and for these few state props we use Zustand.

However in this case we need to add a whole new library and all the boilerplate just for few simple props, and naturally you think if RQ is already used and can handle the more complex api data, why not use (abuse..?) it for something way more primitive and have less dependencies?

I'm not saying it should be used to handle complex global states, because as mentioned it's not what it's built for and there are more efficient libs for that, but maybe it could be used for simple cases? Or let's say at the start of the project when you don't know how complex the state is going to be?

Also, I've made my example slightly different. If you pass empty function to the query, it's never loading, fetching or refetching, it renders only once. Seems like it just handles the state perfectly and does nothing else, and with minimal markup.

export const useCounter = () => {
  const { data: count } = useQuery(['counter'], () => {}, {
    initialData: 0,
  });

  const setCounterQueryData = (value) => {
    queryClient.setQueryData(['counter'], value);
  };

  return { count, setCounterQueryData };
};


export const Counter = () => {
  const { count, setCounterQueryData } = useCounter();

  const onClick = () => {
    setCounterQueryData(count + 1);
  };

  return (
    <div>
      <p>Counter: {count}</p>
      <button type="button" onClick={onClick}>+ 1</button>
    </div>
  );
};

As usual all options have pros and cons and tradeoffs to consider, but seems like this could be a nice to have, especially if some legit API is made for it that doesn't require 'faking' a query, useCache or something :)

[lorkel]

Couldn't you just use React's baked-in context providers? I've been playing with this recently:

• Create a user / theme provider under QueryProvider and above <App />
• Use RQ within that provider to get values
• Pass those values down to the context provider

<UserContext.Provider value={{ theme, avatar }}>
  {children}
</UserContext.Provider>

Seems to be working really well thus far, and no need for an additional library. Would love to hear if there are things I'm not considering with this approach!

ETA: found this post from TkDodo and am going down a rabbit hole; seems like React's context is less performant/requires re-renders.

ETA2: oh also this analogy:

...prop drilling is taking the stairs. Context is an elevator because you’re still stopping at every floor, even if it avoids the arduous stairs. Anything wrapped in context will get updated.

So, yikes. Man am I glad you posted on this thread @Martynas-K !