-
Notifications
You must be signed in to change notification settings - Fork 16
Description
prefetchQuery eats errors, which has the very annoying consequence that any error we run into in a loader manifests as the ensurePrefetched invariant failure in the component. We never see the real error, only the invariant failure. This means opening the browser console tells you nothing about what went wrong. See #2614 for an example of something made much harder to debug by this. It might also help a little with #2573.
Options
-
fetchQuery(docs, source) fetches data unless it's cached and non-stale. -
prefetchQuery(docs, source is the same asfetchQueryexcept it eats errors and returns nothing. 😶prefetchQuery<...>( options: FetchQueryOptions<TQueryFnData, TError, TData, TQueryKey>, ): Promise<void> { return this.fetchQuery(options).then(noop).catch(noop) }
-
ensureQueryData(docs, source) only callsfetchQueryif there is no data in the cache, regardless of staleness. IfrevalidateIfStaleistrue(defaultfalse), it will callprefetchQueryto revalidate if there is data in the cache but it's stale. By default, it will not do this, meaning it will simply return cached data if it's present, regardless of staleness.
I'm a little torn between fetchQuery and ensureQueryData. I'm not sure we need the extra logic in ensureQueryData — I think when we run a loader, we do want to make sure the data is fresh because it's a page navigation. I think we want the app to behave as much like a traditional web app as possible. I also don't want to have to pass in revalidateIfStale: true everywhere, so I'd probably add a loaderPrefetch function to the QueryClient object if I wanted to use ensureQueryData.