Provide a way to manage globally shared queryKey

[s33h0w]

When using React Query, we may find that sometimes the query key depends on some local states of components, but the query result needs to be shared globally. For this, we usually need to use some client state management tools (react context, redux, etc.) to raise these local states to the global level so that other components can use them to compose a same query key to get the current query result. But introducing these client state management tools brings much burden to us, and that's not what we want. I'm thinking how about RQ providing a way to manage its query key by itself?

My vision is as follows.

// `useSharedQueryKey` is a hook for managing globally shared query keys.
import {useSharedQueryKey} from 'react-query';

const reducer = (currentQueryKey, action) => ({...currentQueryKey, ...action})

// query hook
export const useGetData = (): SharedQueryResult => {
    const [sharedQueryKey, dispatch] = useSharedQueryKey(reducer, initialKey);

    return [
        useQuery(['XXXData', sharedQueryKey], () => fetchData(sharedQueryKey)),
        dispatch
    ];
};

// local component1
export const LocalComponent1 = () => {
    const [value, setValue] = useState('');
    const [{data}, dispatch] = useGetData();

    const handleChange = (e) => {
        const value = e.target.value;
        setValue(value);
        dispatch({param1: value});
    };

    return (
      <div>{data} <input onChange={handleChange} value={value}/> </div>
    );
}

// local component2
export const LocalComponent1 = () => {
    const [value, setValue] = useState('');
    const [{data}, dispatch] = useGetData();

    const handleChange = (e) => {
        const value = e.target.value;
        setValue(value);
        dispatch({param2: value});
    };

    return (
      <div>{data} <input onChange={handleChange} value={value} /> </div>
    );
}

RQ will provide a hook useSharedQueryKey outside to manage those query keys which need to be shared globally.
Through this hook, each component can fetch and update the query key and hence get the latest query result.

Here is a similar implementation I have done using createReducerContext provided by react-use. The final result is shown as below.

Here is another previous discussion for reference. (#3200) If the above idea works, I can contribute to adding this.

[TkDodo]

no, this is out of scope for react-query. There are already lots of ways to handle global client state. My recommendation is to use the url, or zustand for this.

But introducing these client state management tools brings much burden to us

Not sure I understand that, it's like 5 lines of code with zustand, or even less if you use an atom from jotai:

import { atom, useAtom } from 'jotai'

const sharedQueryKeyAtom = atom(['my', 'key'])

function MyComponent() {
  const [sharedKey, setSharedKey] = useAtom(sharedQueryKeyAtom)
}

that's it.

[s33h0w]

Sorry for the late reply. I think@lukemorales/query-key-factory is really a good tool for organizing queryKeys, but what I want to discuss is how to manage globally shared queryKeys, specifically those that depend on local component client states but the query result needs to be shared globally. There are many ways to do this, such as the ones (context, jotai, redux...) mentioned above. But in my opinion, RQ should have this capability itself. QueryKey is a core concept of RQ, we manage query results by queryKey, but RQ does not provide the ability to manage queryKey. The benefit of doing so brings flexibility, as users can choose a solution that suits them to manage their query key. But the downside is that they have to find such a solution since they can't do that via RQ. So I think maybe managing those globally shared queryKeys is not outside the scope of RQ.

[TkDodo]

query keys are composed of client state, as the key needs to contain the input to the query function. This is often ids, filters and selections applied by the users. Most people do store this somewhere already: redux, zustand, the url, context, jotai, ...

an example:

const filters = useFilters()
useQuery(['todos', { filters }], () => fetchTodos(filters)

so filters are { done: true } or { tag: 'chore' } or whatever, something that the user can input. how is it react-query's responsibility to tell you how you should store this information? useFiters can read from the url, or from context, or from local state.

If you need your todo filters to be available in many applications, they are no longer "local state", but global client state. I really don't see how react-query could come along and say: "put this data additionally into our QueryKeyProvider" because that would just be state duplication that needs to be synchronized ...

[s33h0w]

If you need your todo filters to be available in many applications, they are no longer "local state", but global client state. I really don't see how react-query could come along and say: "put this data additionally into our QueryKeyProvider" because that would just be state duplication that needs to be synchronized ...

I'm not sure if my implementation here is the same as described above. I illustrate my point with the following example. FullName is obtained from the API based on the state of the local component FirstName and LastName. Here we have two ways of thinking. One is to promote the fistName and lastName from the component's local state to the global state as mentioned above. The other is to keep them still local and promote the derived value queryKey to global, as shown in the code below. The latter is what I recommend, it doesn't cause the component to go from uncontrolled to controlled.

The idea of the latter is to separate the local state and the derived value queryKey, and always only upgrade the queryKey to global, which is why I suggest that RQ provide a way to manage the queryKey.

[TkDodo]

The other is to keep them still local and promote the derived value queryKey to global

if that's want you want to do, then do that, even though that means storing derived state, which is not ideal. It still means you would make the fullName value globally available somehow so that you can put it into a query as the key.

Just because you take a global value and make it a query key doesn't mean it becomes react-query's responsibility to manage it. You might want to use that value for something else, too...

What you are basically suggesting is that react-query needs a way to manage synchronous, global client state just so that we can put it into the query key. We've said time and time again that this is not going to happen and that there are dedicated libraries that do exactly that. Jotai's atoms and derived atoms would make a lot of sense for this use-case!

[s33h0w]

Just because you take a global value and make it a query key doesn't mean it becomes react-query's responsibility to manage it.

It's not about taking existing global data as a queryKey, as opposed to turning a queryKey into global data. Because the only use of this derived value is as a queryKey, which is why it needs to be derived. So I'm always talking about how to maintain the queryKey, not how to maintain the client state. I don't think we can understand each other's ideas after all the times we've said it. It's frustrating. I will close this discussion, thanks for your reply, and sorry again for not replying in time during the discussion.