How to prevent query data selector function from running

[seanforyou23]

Hello, we use react-query in a lot of places within our UI and recently moved some complex sorting logic into these select handlers. I'm noticing that one select handler in particular that deals with somewhat large amount of data gets called many many times, and is leading to OOM issues for us.

Is there a way to programmatically prevent the select handlers from running? Or do they always run?

I have tried setting notifyOnChangeProps and notifyOnChangePropsExclusions to various configurations but even if I make those as strict as possible, when an unrelated query resolves this one query's select seems to get fired off either way. I have also tried turning refetch* configs off and also setting staleTime cacheTime to overcome it but no luck just yet.

Anything you can think of I should try to limit the number of times this query is running its select handler? Thanks!

[TkDodo]

So selectors generally run on every render, because most of the time, they are very inexpensive. Technically, they always run if the functional reference changes or if the input (request data) changes. To improve this, you an memoize the selector function, either by extracting it to have it outside of the component, or with useCallback if it has dependencies.

You can read more about that in my blog here: https://tkdodo.eu/blog/react-query-data-transformations#3-using-the-select-option

I'd also happily accept a PR to the docs that somehow mentions this behaviour, on some page where it fits :)

[seanforyou23]

Ah, that sounds solid! Let me give it a spin and if it works and I can contribute to the docs I'd be happy to. Will send an another update soon.

[seanforyou23]

Yep that worked for me, thank you so much for the quick response.. really helped me out. On the one fussy query, in addition to moving the select handler into a callback hook, I ended up using a combination of enabling keepPreviousData and setting cacheTime to 0. It's the only combination that seems to prevent the issue.

Do I understand it right that by setting cacheTime to 0 it allows GC to cleanup at the next available opportunity, and by using that along with keepPreviousData it actually does the thing one would hope and keeps just the one copy of the data in memory until an update happens, at which point it has opportunity to purge the old from memory and replace it with the new?

That was the thing I was sort of looking for in the docs (hopefully I didn't overlook it) to know which properties where allowed/expected to be used with one another, for staleTime/cacheTime/keepPreviousData anyway. And especially if any were not supposed to be used together - in the context of a larger payloads of course.

[TkDodo]

Do I understand it right that by setting cacheTime to 0 it allows GC to cleanup at the next available opportunity, and by using that along with keepPreviousData it actually does the thing one would hope and keeps just the one copy of the data in memory until an update happens, at which point it has opportunity to purge the old from memory and replace it with the new?

Yes, that sounds right. With cacheTime: 0, cache entries will be garbage collected as soon as there are no active observers anymore. If you change the query key, you'll get a new observer, so the old one will vanish after cacheTime. If you add keepPreviousData to the mix, you should still see the old data on screen until the new data arrives, while still only having one cache entry.

I have to say, that's a pretty genius combo 🚀