Query and Query Instance separation

[khmm12]

Greeting 👋

Sometimes the same query can be used simultaneously in different places of the application with different fetch and cache strategies.

The most common case is information about current/active user. It can be used in navbar to show user name, on profile form to give user ability to change their data, on actual application scene to build permissions, inside authentication boundaries to protect routes, e.t.c.

It's pretty clear that different cases require different fetch and cache strategies.

• Navbar can be 100% optimistic, rely on cache and do fetch when cache is missing (cache-first).
• Profile form can be optimistic as well, but it makes sense to actualize data in background after mount (cache-and-network).
• Authentication boundaries (route handler) can't rely on cache and must always use actual data (network-only). The exception is first render after rehydration.

In all cases the query is the same. The key difference is how the query is consumed.

react-query provides cacheTime and refetchOnMount.

• network-only partially can be emulated with cacheTime: 0.
• cache-and-network is default behavior.
• cache-first can be emulated with refetchOnMount: false.

Looks good so far until you declare the same query with different options at same time in different places. Oooops. Different query consumers shares a single strategy. network-only received cached data.

Possible temporary solutions:

• Include cacheTime and refetchOnMount to query keys. It really works. But it's not a rescue, because brings extra network requests and conceptually is wrong.
• Override queryInfo inside hook until refetch promise is settled to emulate network-only. Looks like dirty-hack.

Any thoughts on that?

[tannerlinsley]

Yeah, this is interesting. Shared query context between query instances is something that has been interesting in RQ from the beginning. What I've always strived for is a system where lower-priority requests do not interfere with higher priority requests. For example, if you have a cache-first query that occasionally gets updated because of the same query being used in an instance set up as a network-only query, then I think that is preferred. However, if you have a network-only query that somehow stops requesting because of the same query being configured in another instance to be cache-first, we've got a problem. And if that's what's happening today, then we should work on fixing it. A good example of this "spirit" is the way that refetchIntervals currently work. Multiple instances can have their own interval timings, but the fastest one always takes precedence. We should do the same with query refetching strategies.

As far as I know the worst scenario I see in this is where you have a cacheTime: 0 query that is killing the cache out from underneath a cache-first query. Even then, I feel like you are more describing the volatility of the data in contrarian ways. staleTime: 0, cacheTime: 0 essentially means that you have zero trust in any cached data beyond persisting it in the current view. If you had the same data dependency in another part of the app, but with full trust (cache and network, long staleTime, etc), then you would essentially be contradicting the volatility of the data. I think this is a pretty rare scenario, but not an impossible one. And now that I've talked through it a bit, I think the best way to solve this is what you said, realizing that you are technically caching two different segments of data and giving them different cache keys. That way you can control the volatility of each piece of data independently. Even in multiple network requests became an issue between those two scenarios (maybe 2 simultaneous requests?), you could get around this by sharing the same promise queued function between both of them.

At the end of the day, I think this is okay. We can always improve on making each query instance behave as independently as possible, but at the end of the day, if they cache on the same key, they need to play nice with each other and the user needs to understand the implications of defining contradicting query and data volatility configurations.

[khmm12]

Hey @tannerlinsley 👋

As far as I know the worst scenario I see in this is where you have a cacheTime: 0 query that is killing the cache out from underneath a cache-first query.

That's why I told partially 🙂. Of course it shouldn't destroy other queries.

From other side at first glance the hook below gives exact network-only behavior.

hook snippet

export function useQuery(...args) {
  const [queryKey, config = {}] = useQueryArgs(args)

  const queryInfo = useBaseQuery(queryKey, config)

  // Dirty hack
  const [noCache, setNoCache] = useState({ noCache: !config.cache && queryInfo.isStale })
  
  if (noCache) {
    queryInfo.data = undefined
    const overrides = { status: 'loading', ...getStatusBools('loading') }
    Object.assign(queryInfo, overrides)
  }

  const { refetch } = queryInfo

  useEffect(() => {
    if (noCache) {
      refetch().finally(() => {
        setNoCache(false)
      })
    }
  }, [noCache, refetch])

  handleSuspense(queryInfo)

  return queryInfo
}

• It doesn't destroy other queries.
• It actualizes their data.
• It always uses actual data on mount.
• It subscribes to query updates.

So IMO with network-only it's a matter of component behavior, not query. The same as for refetch interval.

[tannerlinsley]

It's weird because if you're doing network only, one of the only benefits you're getting is the promise deduping of potentially multiple instances of the query being used at once.

[khmm12]

I admit there may be confusion with these naming. Many years of apollo-client usage leaves some cliche. I'm sorry 🙇‍♂️.

I meant something that apollo-client does. with network-only it doesn't retrieve data from cache on mount, but after that it behaves like cache-and-network. For cache-less strategy they have no-cache, it doesn't read and write anything from/to cache.

useInitialCache, useCacheOnMount, cacheOnMount? Nothing special doesn't come to mind 😁.

[tannerlinsley]

I see. So:

• Network only: Do not use cached data on mount, force refetch, then behave normally. You're right that this would require a new option. Other ideas: initialCache: false. I actually like useCacheOnMount: false.
• No cache: Share data and fetching across active instances, but do not cache anything. This is achievable via staleTime: 0, cacheTime: 0, right?

[khmm12]

Now I completely understood why you did mention volatility of the data and query priorities. With staleTime and cacheTime I completely agree with you, they're query related configurations and should be shared between different query producers (instances). But IMO they should be merged via smart strategy, like shorter staleTime has higher priority. Today seems they're merging via "last in, last assigned" 🙂.

Network only: Do not use cached data on mount, force refetch, then behave normally. You're right that this would require a new option. Other ideas: initialCache: false. I actually like useCacheOnMount: false.

👍

No cache: Share data and fetching across active instances, but do not cache anything. This is achievable via staleTime: 0, cacheTime: 0, right?

Ooh, if to combine with useCacheOnMount, that's partially truth for query. But it may confuse, because it's more related to query instance itself. At least for people who migrate from apollo-client. When I set noCache: true (suppose), I expect the hook doesn't get data from cache and doesn't affect to cache. There may be confusion between options which affect to query and options which affect to query instance.

BTW Personally I used no-cache strategy only once time to avoid some issues in apollo-client cache. But from other hand it still may useful for some people.

[boschni]

Yeah I also think the instance/query behaviour could be a bit confusing to some users.

Say for example, we have a user resource on the server:


id: string
username: string
messages: Message[]
email: string

With each field having different caching characteristics. While not recommended, sometimes this is the API you are given.

In a top navigation we then show the username, but because we know this field will never change, we define the query as:

useQuery('user', getUser, { staleTime: Infinity })

As long as only the top navigation is rendered, we never want to revalidate.

Then the user navigates to a page to view his messages. Here we want to show the cached data, but because messages could be updated more frequently, we also want to revalidate and define the query on the messages page as:

useQuery('user', getUser, { staleTime: 10 * 1000 })

As long as the messages page is rendered, we want to revalidate after 10 seconds (or maybe even set some interval).

Then the user navigates to another page. Because the messages are not shown anymore (only the top navigation) we never want to revalidate.

Then the user navigates to his edit profile page. Here we might not want to show any cached data, but always show the latest data. So we define the query as:

useQuery('user', getUser, { staleTime: 0, useCacheOnMount: false })

When thinking in this way, we are not really defining the lifetimes of the user query, but we are defining what the lifetimes should be in specific places, while sharing the same cached data and request deduplication.

Conceptually this is a bit different, but I think it would also be my first intuition.

[khmm12]

Regarding to staleTime I completely agree with @tannerlinsley. This is query specific configuration. And I agree with you API shouldn't be ambiguous and confuse developers.

So IMO:

• It should be clear for developers which options affect to query instance and query itself. May even like that:

useQuery('user', getUser, {
  query: {
    staleTime: 0
  },
  useCacheOnMount: false
})

• It should use smart merge strategy. Lower staleTime values should have greater priority while they alive.

function Navbar() {
   useQuery('user', getUser, { staleTime: Infinity })
}

function Settings() {
   useQuery('user', getUser, { staleTime: 10 * 1000 })
}

function Application() {
  <Layout>
     <Navbar />
     <Switch>
        <Route path="/" component={Landing} />
        <Route path="/settings" component={Settings} />
     </Switch>
  </Layout>
}

render(<Application />)

• Landing: staleTime = Infinity
• Settings: staleTime = 10_000
• Return to Landing: staleTime = Infinity

Today in that case staleTime will be ambiguous, depending which query instance rendered last.

[boschni]

Maybe the query stale, cache and refetchInterval values can be automatically updated to match the current priorities when instances subscribe, unsubscribe or change configuration? Then the query would always reflect the current needs without any separate configuration. The isStale property would need to be calculated and returned by the instance though, because otherwise it would not match with the instance stale time.

Something like that together with these options?

• fetchOnMount to force a fetch when mounting, regardless of stale time
• useCacheOnMount to not return any data from the cache when mounting