Question about useQueries

[ericpatey]

My project takes advantage of useQueries quite a bit so that we can adhere to the rules of hooks.

While debugging a potential perf issue in our code, I happened to notice that useQueries hooks seemed to be triggering rendering every time the hook was called. It looks like the triggering was happening because of this useEffect which includes defaultedQueries in its dependency list. defaultedQueries is created here. The problems is that defaultedQueries is not identity stable, so its value changes every time the hook is called.

I know that my code should be prepared to render whenever - even if called redundantly with the same properties. This leads to my questions.

• Does react-query, in general, try to avoid triggering renders like this?
• If so, would this be considered a bug?
• If so, could it be easily fixed by wrapping the creation of defaultedQueries in a useMemo like this:

const defaultedQueries = useMemo(() => queries.map(options => {
    const defaultedOptions = queryClient.defaultQueryObserverOptions(options)

    // Make sure the results are already in fetching state before subscribing or updating options
    defaultedOptions.optimisticResults = true

    return defaultedOptions
  }), [queries])

[TkDodo]

I do think that this is indeed a bug / not ideal behaviour of useQueries. At leat the effect dependency is superfluous because, as you said, since we .map, the effect will run in every render anyhow.

However, does running the effect really trigger another re-render? Because if that were the case, we would likely be looking at an infinite loop, because with an additional re-render, the useQueries hook would be called again, scheduling the effect again ...

If so, could it be easily fixed by wrapping the creation of defaultedQueries in a useMemo like this:

yes it could, but it would also shift the responsibilities to consumers of useQueries. Most people call it with:

useQueries(someIds.map(id => ({ ... }))

or just with an inline array with multiple entries, so if that happens, we'd just get a new queries identity into useQueries every time. With that, we've made it worse because now we run useMemo every time for no reason, as well as the effect afterwards.

of course, if it enables an optimization for consumers (they memoize their input, gaining something because if it), we could do that.

The question from above remains: What does calling the effect in every render really do? A codesandbox reproduction would be appreciated.

[ericpatey]

Thanks for the response. I'll work on a codesandbox repro as soon as I can get my head above water at work this week.

[ericpatey]

Thanks for pushing for me to clarify.

It looks like I was confused about what was causing the renders and went down the wrong path thinking it was related to useQueries.

What I'm actually seeing looks like notifyOnChangePropsExclusions not working the way I expected. I use notifyOnChangePropsExclusions: ["isStale", "isFetching", "dataUpdatedAt"] to suppress renders for data that I'm never interested in.

Here's a sandbox that shows a constant stream of renders when only dataUpdatedAt changes.

[TkDodo]

I'm very sorry - we recently added an isRefetching boolean flag that will be true for refetches only, and you would need to add that as well to the exclusions.

I even mentioned that on the PR when I introduced it, because I had to update a test for it as well. See here: #2469

one concern is that if you currently use notifyOnChangePropsExclusion: ['isFetching'] to avoid renders during background updates, you will now get those renders again because of the new flag, which you would need to include again. Not sure if that is a blocker for this feature

Tbh, I wouldn't really work with the exclusions props, because I can't guarantee that we won't add more props in the future.

What works best for render optimizations is using tracked queries:

notifyOnChangeProps: 'tracked'

it makes sure that your component re-renders depending on the properties of the query the render function actually uses. I've written about that here: https://tkdodo.eu/blog/react-query-render-optimizations

[ericpatey]

Thanks for the insight, @TkDodo