Polling interval for entire API

[tomchambers2]

We are refactoring our redux store to use RTK query. For a while I was under the impression that the caching had a timer that went stale and then it refetched the data silently. I have discovered now that the cache is only deleted when all the subscriptions are removed and the timer has expired.

What we would really like is for the user to have the most up to date data regardless of whether they have nagivated away. For example the user is looking at a list of team members leaving the tab open. Someone adds a team member. The user should see the updated list after a short time (like a minute).

I realise there is a pollingInterval option for individual hooks, but this has to be added to every single use of the hook which makes it cumbersome to update and error prone if you forget one, especially because it's a difficult thing to test.

What's the rationale for keeping the cache around forever as long as there are subscriptions? And can we have a pollingInterval option for createApi?

[phryneas]

What's the rationale for keeping the cache around forever as long as there are subscriptions?

That there are subscriptions means "it is displayed on screen". And then we keep it for a (configurable) bit longer in case you do a very fast forward-backward navigation or some kind of component transition.

I believe you want to use something like refetchOnMountOrArgChange which you can also pass a number into - which would refetch if a component is mounted and data is older than X seconds.

Tbh, I do not see a common use case for just polling everything as in most cases that would just kill every server.

[web-bert]

Hi @phryneas

Thanks for the reply, I work with @tomchambers2 and we have a specific case that refetchOnMountOrArgChange doesn't work for. Here is some pseudo code to illustrate:

function Layout(){

   const company = useCompanyQuery(); // refetchOnMountOrArgChange doesn't not work for these two as it doesn't unmount
   const user = useUserQuery(); // the subscription count for these hooks is always 1

   return (
      <>
         <Header company={company.data} user={user.data}/>
         <Switch>
            <Route exact path="/">
               <Dashboard />
            </Route>
            <Route exact path="/company">
               <CompanyDetails company={company.data} />
            </Route>
            <Route exact path="/teams">
               <Teams />
            </Route>
         </Switch>
      </>
   );
}

In this example the Header has links to the routes below and so the user can click between the different routes, but RTK query will never get any updated user or company information. What we want: after 5 minutes, mark the company and user data as stale and then when they next click a link (making the Layout re-render) it will fetch the latest data.

We have tried this with pollingInterval but the issue here is that it keeps getting the data, so if the user is not clicking around for an hour it is still fetching the latest data every 5 minutes. What we want is to have marked the data as stale and then on the next render (i.e. the next interaction from the user) it will get the latest data - in this example after 1 hour, so 1 call instead of 12.

It would be good if you could provide some insight into the decision behind the "Active subscription reference counts" as I can't understand why you would want this. To me data starts getting stale from the moment it is rendered, not from the moment it has been removed from the screen (unmounted), we expected RTK query to work like so: fetch the data once and let many components render it, once the timeout has elapsed, mark the data as stale and then on the next re-render fetch it again.
Where as what it really does is fetch the data once and let multiple components render it and only after they have all unmounted does it start the timer to get new data, therefore if a component stays mounted for hours the data won't get updated for hours - I struggle to understand why you would want that behaviour and feel I must be missing something?

[phryneas]

Your use case sounds to me as if refetchOnMountOrArgChange: 300 would exactly solve it, assuming "clicking a link" in some way mounts a new component.

It would be good if you could provide some insight into the decision behind the "Active subscription reference counts" as I can't understand why you would want this.

Imagine you have a full page rendered with all the data of, let's say, a post. At the bottom, there are comments. Those only get rendered once they scroll into view, or after some other kind of user interaction, but rely on the same query as the data above.
Now, just mounting a component should not just make everything else rendered on the screen plop around wildly unless you explicitly tell it to fetch new data - that is what refetchOnMountOrArgChange is for: tell it to do a refetch if the data is already in the store over X seconds. Otherwise, not.

"Automatic refetches" that are not configured in any way by you as the library user should only happen when nothing is on the screen - otherwise, RTK-Q would run risk of making your UI flicker in completely unexpected ways.

[web-bert]

refetchOnMountOrArgChange doesn't solve it because Layout never gets unmounted, as the links in the Header are effectively selecting which child of Layout to render - therefore Layout is never unmounted.

Here is a little more verbose code to illustrate:

function Layout(){

   const teams = useTeamsQuery(); // refetchOnMountOrArgChange doesn't not work for these two as it doesn't unmount
   const user = useUserQuery(); // the subscription count for these hooks is always 1

   return (
      <>
         <header>
            Hello {user.data.name}, you are a member of {teams.data.count} teams
            <Link to="/">Dashboard</Link>
            <Link to="/teams">Teams</Link>
            <Link to="/company">company</Link>
         </header>
         <Switch>
            <Route exact path="/">
               <Dashboard />
            </Route>
            <Route exact path="/teams">
               <Teams />
            </Route>
            <Route exact path="/company">
               <CompanyDetails />
            </Route>
         </Switch>
      </>
   );
}

The user name and team count will never get updated in the header for the lifetime of that particular layout. Other users can be adding/removing the current user to/from other teams, so we want to make sure the teams data gets fetched periodically, but currently the only way to do that is to refresh the page or go to another area of the app which will unmount the Layout.

[phryneas]

I guess in that case you will have to manually call teams.refetch() in a useEffect on route change, I'm sorry.

[web-bert]

Ok, thank you, as long as we aren't missing a feature that is already supported.

I wonder if there is room to add an option such as staleAfter: 300 where instead of waiting for 300 seconds after the last subscriber is unmounted, it starts a 300 second timer after the first subscriber has called the hook?

As an example, if there are 3 subscribers to the same data the life cycle would be:

First render:
subscriber 1: no data, initiate fetch, start timer
subscriber 2: fetch in progress, wait for data
subscriber 3: fetch in progress, wait for data

There are re-renders in less than 300 seconds:
subscriber 1: use cached data, render
subscriber 2: use cached data, render
subscriber 3: use cached data, render

After 300 seconds the cache is marked as stale/invalidated by the timer, on the next render:
subscriber 1: use cached data, initiate new fetch, start timer
subscriber 2: render
subscriber 3: render

[phryneas]

We will not tie anything to re-rendering. When and how something is re-rendered is absolutely not deterministic and will just get less deterministic in the future.
For all I know, React could at some point decide to rerender everything once every three seconds. Even now, React calls render twice in dev environments and I would encourage you to always see rerenders as an implementation detail of React and not as something to build any logic upon. Rerendering can have some connection to user behaviour, but there is absolutely no need for that to be true.

The only thing we can determine is if time has passed - and that would be polling.

[web-bert]

I'm not suggesting to tie it to re-rendering, I'm using that as analogous to the "next useFooQuery hook call". So I am suggesting that a timer is set on the first call to useFooQuery and then once that timer has expired the cache is marked as stale and the next call to useFooQuery would trigger a re-fetch - which could be close to when the timer expires or hours after. The point being that it doesn't just go and fetch the data because a timer has expired (like pollingInterval does), but it waits for a call to useFooQuery to trigger the fetch - which saves unnecessary calls to the API while the app is inactive.

[tomchambers2]

@phryneas I think the general point is that rtk query's design works very well for a high volume, low change site like a content-based news site. Our site is a low-volume, high change site where we want users to be able to cleanly have the content updated (every 5 minutes for instance). So if the user remains on the same page and is active performing actions, they should see the updated content after a reasonable interval.

[phryneas]

That is pretty much polling. You could decide to disable the polling option when you detect that the user is not moving the mouse or something like that, but I would really not take "something rerendered" as an indicator of "the user is active". There are just too many different reasons for rerenders, some of them might be completely React-implementation-specific.