RTKQ: Data stays as old value and loading immediately jumps back to false when fetching fresh data from different endpoint + query param combination

[agusterodin]

Hey, I am experiencing an issue when using the useQuery auto-generated hook. If I change query parameters, the data remains the same (I expect it to be undefined so I can show loading placeholder) and loading jumps from "true" immediately back to "false" despite the data for that given combination not being loaded yet. I have keepUnusedDataFor set to 0 btw (not sure if relevant or not).

The docs claim:

isLoading refers to a query being in flight for the first time for the given endpoint + query param combination. No data will be available at this time.

This is really hard to reproduce in a Codepen since it relies on the server having some sort of delay. I wasn't aware of this bug until I used an endpoint that is extremely slow (4+ sec response time).

Hopefully this attached video, code snippet, and console log demonstrate the issue effectively. Please let me know if there are any other details I can provide!!

Notice that despite the argument changing from "monthly" to "weekly" it is still providing the "monthly" data instead of data being undefined while still loading.

Component

import { useSelector } from 'react-redux'
import MetricGraphs from './MetricGraphs'
import MetricStats from './MetricStats'
import { getOverviewMetricTimeframe } from 'state/campaigns/overview/overview'
import { useGetAggregateCampaignMetricsQuery } from 'api/campaign'
import MetricTimeframeSelector from './MetricTimeframeSelector'

export default function Metrics() {
  const currentlySelectedTimeframe = useSelector(getOverviewMetricTimeframe)
  const { data, isLoading, originalArgs } = useGetAggregateCampaignMetricsQuery(currentlySelectedTimeframe)
  console.table({ currentlySelectedTimeframe, originalArgs, isLoading, data })

  return (
    <>
      <div className="relative">
        <MetricTimeframeSelector />
      </div>
      <div className="relative grid grid-cols-1 gap-5 sm:grid-cols-2 lg:grid-cols-4 mt-5">
        <MetricStats metricResults={data} />
        <MetricGraphs metricResults={data} />
      </div>
    </>
  )
}

Recreation In Browser
https://user-images.githubusercontent.com/10248395/126681813-9656f46e-46a8-4a2e-b316-9229291699b5.mov

Have you tried using isFetching for this?

See: https://redux-toolkit.js.org/rtk-query/api/created-api/hooks#usequery

  isFetching: boolean // Query is currently fetching, but might have data from an earlier request.

[agusterodin]

isFetching wouldn't be the right tool for the job. If I am loading data from an entirely different endpoint + query param combination I would want the data to be undefined so that I can show loading placeholders since no data for that query param combination has been loaded.

I can't just set loading placeholders to go away if isFetching is true since that would mean anytime polling happens (user just sits on "monthly" screen with polling running for example), the data would disappear from the user while fetching the updated data.

[agusterodin]

A temporary workaround I am using is just to set the key of the component that contains the hook to the value of the query parameter. This causes React to create an entirely new component from scratch anytime that query parameter changes. This workaround is definitely not ideal though.

[phryneas]

Have you also taken a look at the rest of that query result? The most obvious would be isError in case you have some kind of error for some reason.

Also, take a look in the Redux Devtools and take a look what you see there. You could also export those actions and post them here.

Also: isLoading is only for the first fetch of a hook. If you are changing query args, it will never go back to true again. I'm not entirely sure what behaviour you would want there.

[agusterodin]

Just checked and don't see any errors in the browser console logs or in Redux DevTools.

To me this language in the docs is misleading:

isLoading refers to a query being in flight for the first time for the given endpoint + query param combination. No data will be available at this time.

To me based on the way this is worded I would expect isLoading to remain true if query param changes and the new, unrelated data is being loaded. This is also, in my opinion, desirable behavior. If the user selects "weekly", it would be inaccurate to show any data at all since that would be misleading. Typically this would go unnoticed, but the endpoint we use is obnoxiously slow AF.

I attached a video of my desired behavior: data goes away entirely when the tab changes. I achieved this by doing the aforementioned component key workaround.

Redux DevTools capture (sorry for zip, GitHub makes you do it for json files)
RTKQ Issue Reproduction.json.zip

Desired Behavior
https://user-images.githubusercontent.com/10248395/126702827-8eec90c6-1d3e-441f-8ed3-47426d884e2c.mov

[phryneas]

Yeah, that is a wrong wording in the docs.

See it from a few other perspective:

• Paginated data. On first load, you don't have data. Show a spinner. Changing to page 2 grays out the data (isFetching), but data from page 1 is still displayed to prevent the UI jumping unnecessarily.
• A potentially filtered list. On first load, you don't have data. Show a spinner. On filter change, data is grayed out, but still displayed until the server-side filter finishes with new data.

There are plenty cases where it just makes a better user experience to keep the original data around.

Even in your case, I would personally probably prefer everything going "gray" for a second instead of going UI -> nothing -> same UI with different data. If that data loads quickly, that could be some hard flickering.

But of course, your key hack works very well here.

We might also add an option to change this behaviour in the future, but for now it's more a reason for a docs correction ;)

[phryneas]

Can you give #1340 a short read-over and see if you think it explains it good for you?

[agusterodin]

Agreed, the desired behavior definitely depends on use case.

Another scenario I could imagine "reset data and isLoading when query params change" being desirable is in an e-commerce scenario. Imagine navigating from one store item page to another store item page by clicking a link in a "related items" sidebar. Technically the same component would be mounted since the router continues to show the same component. In this scenario I would expect to the old data from the old item to disappear and replaced with a loading skeleton while the new item contents load.

You are definitely right about violent loading spinner/skeleton flashes being a potential issue with this particular type of behavior. To prevent this phenomenon I created a hook that returns a boolean saying whether a provided "minimum loading time threshold" has elapsed. If the minimum time hasn't elapsed, I continue to pass the components undefined instead of the fetched data so that they continue to show placeholders. Here is my example hook for that: #1276 (comment). I am very strongly convinced that other big-tech applications implement a "minimum loading time threshold" when using skeletons. For example: I have never seen the loading skeletons on the Headspace Android app flicker violently regardless of how fast my connection is.

Would love to see an option you can pass the hook to control this behavior in the future.

Also looked over the doc change. Much clearer.

Much appreciated!

[agusterodin]

Another point that I realized about why in certain use cases it makes sense not to show data from old args and instead make it explicitly clear that data is loading:

Imagine someone using your product on an extremely low quality connection (2G or third world internet). Imagine it is bad to the point where every request takes 20 secs. Now imagine that someone clicks away from the "monthly" the "weekly" tab. Imagine that they look away for 8 secs and come back to their screen (or a colleague walks up to the screen). They will likely be under the full impression that what they are seeing in that moment is information for "weekly" despite actually being the data for "monthly".

This scenario sounds comical but there is definitely something to be said about considering low quality connection scenarios and potentially misleading UI.

It is personally hard for me to imagine experiencing the web with a low quality connection but there are definitely people out there that have this issue. I'd say creating a user experience that neglects poor connections or potentially misleads people with poor connection (in a general sense, not just my product scenario) is detrimental to accessability of information on the web.

[phryneas]

This scenario is why you should use the information isFetching to display to the user that actually, data is being fetched right now. Like I already said: gray it out, for example.

[phryneas]

Oh, by the way: if you want to circumvent this hook-specific behaviour:

const selector = useMemo(() => api.endpoints.myEndpoint.select(arg), [arg])
const dataWithIsLoadingJustForThisCacheEntry = useSelector(selector)

[agusterodin]

Yes using isFetching is definitely a solution. It would be really nice to differentiate initial content load from situations like polling though.

Based on the situation you may want the visuals of initial content load to be different than that of polling (full loading skeleton for initial load vs tiny spinner at top right of page when polling for example).

Update: saw your previous post, seems like a good temporary solution, thanks!

[phryneas]

I'll add an "enhancement" label on this one. Maybe we can add a switch to change behaviour or add a isLoadingFirstTimeForArg flag on top there.