Skip to content

Change all prefetchQuery calls to ensureQueryData or fetchQuery #2616

@david-crespo

Description

@david-crespo

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 as fetchQuery except 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 calls fetchQuery if there is no data in the cache, regardless of staleness. If revalidateIfStale is true (default false), it will call prefetchQuery to 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions