blog/react-query-render-optimizations

[utterances-bot]

React Query Render Optimizations | TkDodo's blog

An advanced guide to minimize component re-renderings when using React Query

https://tkdodo.eu/blog/react-query-render-optimizations

[lgenzelis]

Excellent article TK! 🙌 I love learning about these little details. Out of sheer curiosity, did you use proxys to implement the 'tracked' option for notifyOnChangeProps?

[TkDodo]

It started out with proxies, but in the end was made with Object.defineProperty. Have a look at the PR: TanStack/query#1578

[lgenzelis]

Very cool! Thanks! :) For anyone else wanting to take a quick peek as well, this is where all the magic happens.

[paragdeka]

Is there a way to use isFetching and still don't re-fetch on re-render?

Like, when implementing infinite-loading with useInfiniteQuery we need to show a spinner. If notifyOnChangeProps option is used with ['data', 'error'], then unnecessary refetch problem is fixed, but isFetchingNextPage doesn't trigger.

How to show the spinner during fetch but do not refetch the same data again?

[TkDodo]

@paragdeka react-query will not refetch just because of a re-render, so there must be something else going on. Do you have a codesandbox example?
isFetching will be true for every fetch, while isFetchingNextPage is only true when the next page is fetched in an infinite query. So to display a spinner at the bottom of an infinite list, isFetchingNextPage is likely what you want.

[paragdeka]

@TkDodo codesandbox example - https://codesandbox.io/s/epic-haslett-45vef?file=/src/App.js

[paragdeka]

@TkDodo The issue was with react-infinite-scroller. It's working fine now with react-infinite-scroll-component.

Thanks for all the informative posts about React Query! 🙌

[NicBathgate]

@TkDodo - thanks for the great writeup on react-query performance optimisations! I'm currently trying to optimize a map based app that needs to display 1000+ assets (vehicles, aircraft, people, vessels etc) on the map as well as in an asset list,

I've rewritten the whole API layer to use React Query (which has been amazing), however the asset list (which can be over 1000) is stored in Redux in the success() function of the query so that the Redux selectors that the rest of the app is built on can keep working. The problem I'm facing is the app locks up for a few seconds when the asset list (which I'm conveniently polling using react-query!) re-fetches.

My question for you: is there a way to access the structural sharing results myself? I'd like to only update the Redux store for assets that have changed in the re-fetched results to eliminate the UI lockup.

[TkDodo]

I'm afraid not, but what you can do is move the data syncing from onSuccess to a useEffect that has data as a dependency. That way, it will not run if nothing changed in the refetch - but onSuccess would be called every time.

or, you rewrite your selectors to select from the query cache rather than the redux store - that would be even better :)

[NicBathgate]

Thank you for replying @TkDodo 🙏 !

Unfortunately at least a few of the 1000 assets will change on each refetch, there are always a few aircraft flying or vehicles driving, but this will cause the useEffect to fire every time like onSuccess would. Ideally I'd like to know which of the 1000 assets have changed and only call my SET_ASSET redux action to update those ones instead of all 1000.

You have a nice point about refactoring the selectors to use the query cache instead of the redux store. I've thought about doing this before but was looking for the easy option 😉 It sounds like I'll need to do this work to get this app to run smoothly.

Thanks again for your advice!

[aliakbarazizi]

I just start using react query and I think the default value for notifyOnChangeProps is changed to tracked. Is it true?

By default, access to properties will be tracked, and the component will only re-render when one of the tracked properties change.

[TkDodo]

Yes 😅
It would be cool if we would have a lint rule that detects object spread on a useQuery result and warns you about that 🤔

[lgenzelis]

Got it! I'll refrain from doing that then 😅 Thanks for your answer @TkDodo !

[limaho]

Excelent post. I have learned a lot @TkDodo Thanks for all the knowledge you sharing. I have a question regarding the tracked feature:

am I defeating the whole purpose of tracked queries, with this way of return ?

async function fetchUsers () {
  const response = await axios.get("....")
  return {
     users: response.users,
     contacts: response.contacts,
  }
}

function useUsers() {
  const queryInfo =  useQuery(['users'], fetchUsers);
  
 return { 
   ...queryInfo,
   users: queryInfo?.data?.users || [],
   contacts: queryInfo?.data?.contacts || []
  };
}

// Then in my component
const {isLoading, contacts, users } = useUsers();

[limaho]

or

async function fetchUsers () {
  const response = await axios.get("....")
  return {
     users: response.users,
     contacts: response.contacts,
  }
}

function useUsers() {
  const queryInfo =  useQuery(['users'], fetchUsers);
  
 return { 
   queryInfo,
   users: queryInfo?.data?.users || [],
   contacts: queryInfo?.data?.contacts || []
  };
}

// Then in my component
const {queryInfo, contacts, users } = useUsers();

if(queryInfo.isLoading) {
   // ...
}

[TkDodo]

am I defeating the whole purpose of tracked queries, with this way of return ?

yes to the first example, no to the second.

we have a lint rule that should be able to catch this: https://tanstack.com/query/v5/docs/eslint/no-rest-destructuring

[erezrok]

Hi,
question regarding the optimistic approach,
I have 2 APIs, one for getSiteSetting and the other one is updateSiteSetting single attribute(exist in first get API),
the issue i facing is that updating API is taking 2-3 sec to take effect in the server side, getting the following :

1. call to updateSiteSetting API
2. onMutate(for updateSiteSetting) - I'm updating the getSiteSetting query by using queryClient.setQueryData .
3. onSettled I'm calling to the getSiteSetting that NOT reflecting the new update.
   To solve it I call to getSiteSetting and checks if it updated, if not continue to call(with limitations of timeout and number of calls),
   do you see more elegant options??
   Thanks

[TkDodo]

seems like the backend returns from the mutation request without actually having finished the mutation. I would solve this on the backend, so that the first fetch in onSettled already returns the updated data.

[angusd3v]

Hi @TkDodo this is super useful. I have a question about the usage of structuralSharing with a select also provided. You mention that

structural sharing will be done twice: Once on the result returned from the queryFn to determine if anything changed at all, and then once more on the result of the selector function

But how does this work with Typescript? Wouldn't you need to provide one structuralSharing function which received old/new data of the type of TQueryFnData, and one which received the type returned by your selector (TData from what I can tell)? Otherwise your structuralSharing function expecting only TQueryFnData according to types, would sometimes instead receive TData at runtime

[angusd3v]

Interesting -- seems like it would be tough to work with under unknown types.

Does having structuralSharing run on the results of select actually make sense?

I would have assumed that a custom structuralSharing would act as a gate for whether the select function actually needs to be called again. If you can determine identity/no meaningful changes on TQueryFnData inside structuralSharing, then why even call the selector again? I'm probably missing something obvious

[TkDodo]

yeah, so if the response is the exact same, like, my user list:

[
  { id: 1, name: 'foo' },
  { id: 2, name: 'bar' },
]

then we know we can re-use the last select result, thanks to structural sharing. But, if something changed, we need to re-run select, e.g. if it changes to:

[
  { id: 1, name: 'foo' },
  { id: 2, name: 'new name goes here' },
]

now, we don't know the result of select, but it might still be the same, e.g. if we only did:

select: (data) => ({ ...data[0], some: 'thing' })

or whatever. In this case, we would get a completely new object with:

{ id: 1, name: 'foo', some: 'thing' },

that would trigger a re-render of your component, even though the only thing that changed is the name of id 2. That's why we re-run structural sharing on the result of select again.

[angusd3v]

That does make sense. I wonder how you'd use enforce this design consideration from the codebase types on "returning resolved data of the same type" without adding some kind of property to discriminate on in userland to the signature of a structuralSharing function?

https://github.com/TanStack/query/blob/main/packages/query-core/src/types.ts#L83

[angusd3v]

As in to discriminate between whether you're receiving TQueryFnData or TData. Just thinking that unknown would probably be a massive headache for consumers.

[TkDodo]

yeah we added "structural sharing running on select" later on. I don't think many consumers use a custom function here. I need to think about it 😅

[Aboagye-Dacosta]

very good article