blog/inside-react-query

[giscus[bot]]

blog/inside-react-query

Taking a look under the hood of React Query

https://tkdodo.eu/blog/inside-react-query

[devagrawal09]

Great write-up! I was looking for something exactly like this

[yuvalshimoni]

Hi great blog, thanks!
Small side question, why do you using 'useState' here instead of 'use useMemo'?

const [observer] = React.useState(
    () =>
      new Observer<TQueryFnData, TError, TData, TQueryData, TQueryKey>(
        queryClient,
        defaultedOptions,
      ),
  )

[Pelv]

https://beta.reactjs.org/apis/react/useMemo#should-you-add-usememo-everywhere

[yuvalshimoni]

It's not answered.. I trying to understand why memo with useState

[Pelv]

To ensure that the observer never change.

UseMemo is useful for perf optimisation, it's not a "real memorisation". It allows you to skip some re-render, not all.

[ivanjeremic]

also when you pass a function to useState it is for more expensive initial state

[TkDodo]

To ensure that the observer never change.

This is the correct answer. We want to create one instance of the Observer for the lifetime of the component. I do have a separate article on why useState is the best way to achieve that:

https://tkdodo.eu/blog/use-state-for-one-time-initializations

[yuvalshimoni]

Can you explain a bit about notifyManager?

[TkDodo]

The notifyManager is a mechanism for us to batch certain updates together. If multiple calls would trigger an update in the same microtask, we generally defer the update to produce fewer re-renders.

[praveenkumar66]

Two months back I texted you in twitter asking about this. Now it is here. Thanks for your commitment. Great blog.

[samuellawrentz]

Yo thanks for making it look so simple!! This is an awesome library.

[ghost]

Thanks so much for the explanation. Btw. what program did you use to create the charts? They are beautiful and I'd like to create similar ones =)

[TkDodo]

It's called excalidraw and it's open source. You can use it here: https://excalidraw.com/

[j0j032]

Thank you Dominik! always good to be backstage 😎

[meteor91]

Hi! Can you explain how you force react to rerender, when data is loaded or when refetch called?

[TkDodo]

before v4, it was just a forceUpdate:

const [, forceUpdate] = React.useState(0)

forceUpdate(x => x + 1)

now, it's useSyncExternalStore, where you can implement a subscribe callback that will re-render your component and return a snapshot:

  React.useSyncExternalStore(
    React.useCallback(
      (onStoreChange) =>
        isRestoring
          ? () => undefined
          : observer.subscribe(notifyManager.batchCalls(onStoreChange)),
      [observer, isRestoring],
    ),
    () => observer.getCurrentResult(),
    () => observer.getCurrentResult(),
  )

[raphaeljcm]

That was a great article! After using RQ a lot for the past months, It is nice to understand how it works under the hood. Thanks a lot!

[StyleShit]

Great article! 🚀

So the QueryObserver is responsible for avoiding re-renders (or actually "not notifying") when the response is the same?
If so, can you please point me to the area in the code where it happens?

Thanks 🙏

[StyleShit]

I see that there is shallow comparison of the data, but doesn't the data reference always change on each refetch even if the response is identical? (e.g. you JSON.parse() the same string)

If so, how does this comparison work? I think I'm missing something here

[TkDodo]

structuralSharing, a "smart, deep-equal" copying, happens on Query level:

• https://github.com/TanStack/query/blob/792e0b24368b1650fdd904c9e4c85cdcf7118867/packages/query-core/src/utils.ts#L424-L437
• https://github.com/TanStack/query/blob/792e0b24368b1650fdd904c9e4c85cdcf7118867/packages/query-core/src/query.ts#L201

you can read more about it here: https://tkdodo.eu/blog/react-query-render-optimizations#structural-sharing

[StyleShit]

Oh, interesting!

So just to make sure I got it right, this is the flow?

1. Got new result from the queryFn
2. Create a smart deep copy of the result
3. Put it in the cache
4. Observer will run (and eventually call queryObserver.updateResult( ... ))
5. Shallowly compare the prev & next data (since we keep references using structural sharing for both cache & selectors)
   5.1. If the data has changed - notify listeners
   5.2. Otherwise - do nothing

[TkDodo]

pretty much, yeah. What the observer will do additionally is keeping track of which fields of the result is actually used by the component. So if you use const { data, status } = useQuery(...), you will be notified of changes to the data and status field. If you also use isFetching, then your component will receive more updates, as this prop changes more often. This is know as "tracked queries", and is the default since v4: https://tkdodo.eu/blog/react-query-render-optimizations#tracked-queries

[StyleShit]

Just looked at the PR and it's really cool! (and smart with its simplicity)

Thanks for all of your work, you're awesome 🙏

[woohm402]

Hi, thank you for writing a great article :)

What I understood is: react-query is just an adapter of react and query-core. When calling useQuery, QueryObserver is created, and then query-core subscribes / calls queryFn itself.

I found that when using useQuery without any options like suspense, the queryFn is triggered at the same level of useEffect, because this useEffect triggers setOptions() and this calls queryFn.

I think it could be on render phase instead of effect phase. Because useEffect is called after rendering is done, "triggered in useEffect" vs "triggered while rendering" will have a performance difference (yes, it will be small - about 10ms, though. 😅).

like this way (briefly writed)

// as is
// of course, indeed - here are many many more complex steps & options
const useQuery = (queryFn) => {
  useEffect(() => {
    queryFn();  // <- called while effect phase
  }, [queryFn]);
}

// to be
// something like this would be better in performance
const useQuery = (queryFn) => {
  const prevRef = useRef();

  if (someConditionCalculatedFromPrevRefCurrentValue) queryFn(); // <- called while rendering phase
}

This would be a terrible code in plain react, but react-query uses its own observer, so this pattern seems not that wierd.

So my question is: is this behavior intended despite this can lead to a little poor performance?

Again, thank you for a great article and library! I love tanstack query :)

[TkDodo]

render functions need to be pure. triggering a side effect like data fetching in them is technically against the rules of react. This can be troublesome when combined with suspense or concurrent features, where rendering can be interrupted. We also need an active observer first, and that subscription happens in useSyncExternalStore, which has similar timings to useEffect.

[woohm402]

Ah... I see. Thanks! 🙏

[trongtai37]

It's awesome!

[debater-coder]

How does it know which fields are being tracked?

[TkDodo]

We use Object.defineProperty with custom getters and track which field gets accessed on the result returned from useQuery

[mechaniccoder]

Thanks for the great article!

[idiglove]

I love it! Thanks for this. I have a question, how do you handle clean ups on useMutation? Do you use fetch API in the background, how do you handle abort controllers?

[TkDodo]

mutations can't be aborted because they have side-effects on the server

[dovranJorayev]

I love it! Thanks for this. I have a question, how do you handle clean ups on useMutation? Do you use fetch API in the background, how do you handle abort controllers?

I guess you mean unsubcribe callbacks like in useEffect, then i guess generally it is unsafe to cancel mutations, and it is indeterminated what will happen on cancel, does data changed on the external storage or not. For this reason it is a page in docs about query cancelation and is not about mutation cancelation

And if you question about, how making a request happens inside useMutation, you are welcome to explore the source code of it 😄
It is interesting part of open source i think

[mechaniccoder]

Great explanation of architecture!

[alexl-shopware]

Very well written and clear. I'm impressed. I'm a dev with 6 years experience but still have a hard time grasping architectures and technical details. You laid it out masterfully and was easy to follow along.

[morijenab]

Hi,
Great blog thanks!
I have a question and hope here is the right place to ask.

What is the main question:
Where is the React Query cache stored?

more context:
We are using micro front end structure more specifically( Single Spa package).
Each applications has its own cache provider, when i switch between different applications the application is gone ( tested by useeffect cleanup function inside App level).

What is strange to me?
when switching btw different applications:
1-Application A mounted (react query cache is empty).
2-Application B mounted and Application A unmounted.
3-Application B unmounted and Application A mounted(now here before api calls finish the react query cache is exacllty like the last time it was mounted

Each application is a separate project being mounted/unmounted under the single spa management.

[TkDodo]

Where is the React Query cache stored?

In memory, in the queryClient. When you do new QueryClient(), this is actually:

const queryClient = new QueryClient({
  queryCache: new QueryCache(),
  mutationCache: new MutationCache()
})

the client holds the cache, and the client lives in memory.

[morijenab]

Thanks for your response

Lets consider this structure
this is the highest level in the project and as you can see the queryClient wrap the entire App.
if i switch the application i will see the console unMounted. here is the question what happen to the QueryClientProvider after this phase?
if it lives in the memory i expect this should be gone. however after i switch back to this app i can see the QueryClientProvider has the last data.

export const Index = () => {
    useEffect(() => {
        return () => {
            console.log('unMounted!');
        };
    }, []);
    return (
        <CacheProvider value={customCache}>
            <ThemeProvider theme={defaultTheme}>
                <QueryClientProvider client={ReactQueryClient}>
                    <I18nextProvider i18n={i18n}>
                        <App />
                    </I18nextProvider>
                </QueryClientProvider>
            </ThemeProvider>
        </CacheProvider>
    );
};```

[TkDodo]

the provider is just react context. The question is where is the ReactQueryClient coming from...

[pooooriya]

Hi, thanks for your explanation!

I have a question:

Why do you store the whole object inside the QueryCache class and within a property? Why not use something like WeakMap, which works well with garbage collection?

In the codebase, I saw a garbage collection timer that removes the whole object when an observer is removed (I think when the component unmounts). How do you handle storing large objects in memory and manage that effectively?

I have a lot of questions about storing data inside class properties versus other options. I noticed the useSWR codebase uses WeakMap internally, and seeing only a class handle all this logic made me wonder about your approach.

[TkDodo]

Why not use something like WeakMap, which works well with garbage collection?

This design pre-dates my involvement, so I can only guess. WeakMap will automatically garbage collect when there is no reference anymore. What we do is start a timer and then only remove if there is no reference after the timer has elapsed.

How do you handle storing large objects in memory and manage that effectively?

Not sure what you mean. We don't do manual memory management 😅