Describe the bug After upgrading to react-query 3.5.11 from 2.26.4 last week, our project's Cypress tests started failing randomly because the app started showing a loading spinner at random times. After a lot of head-banging, we finally tracked down the issue: even though, based on the network inspector, the request had gone through successfully, react-query's useQuery was returning an object with isLoading as true and data as undefined. Reverting back to react-query 2 fixed the problems.

Most of the requests in our Cypress tests are stubbed using cy.server and cy.route. This probably shouldn't affect react-query but mentioning it here just in case.

Our cache is configured in the following manner at the top of one of our source files, so this shouldn't be caused by us accidentally creating multiple caches:

const queryCache = new QueryCache({
  defaultConfig: {
    queries: {
      staleTime: 10 * 60 * 1000,
      cacheTime: 15 * 60 * 1000,
      retry: (
        _failureCount,
        error: any,
      ) => error.status !== 403 && error.status !== 401,
    },
  },
});

// Further down:

class AppProvider extends Component<{}, State> {
  public render() {
    return (
      <ReactQueryCacheProvider queryCache={queryCache}>
        {/* ... */}
      </ReactQueryCacheProvider>
    );
  }
}

To Reproduce Unfortunately, this happens randomly and is thus very hard to reproduce. The randomness does point towards some type of race condition. Our app performs many (~10) requests on startup.

Even though which tests fail is random, I can consistently get at least one test to fail. Is there something I can do to help track down what could be the issue?

Expected behavior useQuery should return the data it receives in the response once the request is successful.

Desktop (please complete the following information):

• OS: MacOS
• Browser: Chrome
• Version: 87

Additional context Happens on both Cypress version 5.3.0 and 6.2.1.

Describe the bug

When upgrading from [email protected] to [email protected], getting the following error in the browser console:

QueryClientProvider.js:36 Uncaught (in promise) Error: No QueryClient set, use QueryClientProvider to set one
    at useQueryClient2 (QueryClientProvider.js:36)
    at ReactQueryDevtoolsPanel2 (devtools.js:267)

To Reproduce

git clone [email protected]:5ae9c1e18b571bafe17da22775b28329.git react-query-1936
cd react-query-1936
npm install
npm run dev

Open the dev server in the browser. You should see a blank page and observe the following error in the browser console:

QueryClientProvider.js:36 Uncaught (in promise) Error: No QueryClient set, use QueryClientProvider to set one
    at useQueryClient2 (QueryClientProvider.js:36)
    at ReactQueryDevtoolsPanel2 (devtools.js:267)

Now change the version of react-query in package.json to 3.12.0, run npm install and re-start the dev server (interrupt npm run dev and run it again). You should now see App on the page and no error in the console.

This PR adds back discriminated union types, I don't know where they create overhead and why they were removed, but I would argue that they are one of the few things that bring real benefits when using typescript.

https://github.com/tannerlinsley/react-query/discussions/1102#discussioncomment-85980 https://github.com/tannerlinsley/react-query/discussions/922#discussioncomment-56912

Hello @tannerlinsley!

Merry Christmas and thank you for react-query; it's awesome! 🎄

I've just been trying out useQueries in react-query 3 and it's really cool! However one of the things I bumped on was the return type reliably being QueryObserverResult<unknown, unknown>[]. This means I have to assert the type before I can use it.

This can be improved by supporting generics for useQueries just as useQuery does. This PR adds that support; very much modelled on the code of useQuery. It also adds a test which asserts that types flow through in the way we'd hope for.

This should be a backwards compatible change; all existing users will be experiencing QueryObserverResult<unknown, unknown>[] and then having to subsequently assert types. That should all still work, but if they would like, they'll no longer need that code.

What do you think?

Below are the official breaking changes and features for v3. If you have a feature request or idea, please use the Discussions tab to open a new discussion about that idea.

Global:

• [x] Remove usePaginatedQuery.
• [x] Remove ReactQueryConfig.shared as it only contains one value.
• [x] Change QueryConfig.enabled type to boolean but keep behavior.
• [x] Change query key type to match with documentation (string | any[]).
• [x] Remove react-query.mjs in favor of unbundled ESM files.
• [x] QueryCache and Query async methods should throw and hook methods should not.

Query:

• [x] Rename clear() to remove().
• [x] Remove refetch() in favor of QueryObserver.refetch(). The refetch() method on Query is redundant as the functionality is the same as fetch().
• [x] Remove subscribe() as it is only used in the tests.
• [x] Remove fetchMoreVariable argument from fetchMore() in favor of FetchMoreOptions.

QueryCache:

• [x] Remove global query cache.
• [x] Remove makeQueryCache in favor of new QueryCache().
• [x] Remove resetErrorBoundaries().
• [x] Remove prefetch() options (force/throwOnError).
• [x] Rename prefetchQuery() to fetchQuery().
• [x] Change isFetching to isFetching() and do not store state.
• [x] Remove true predicate option from getQueries() in favor of undefined.

ReactQueryCacheProvider

• [x] Make usage required. (Non-breaking, documented)
• [x] Do not create query cache automatically.

QueryObserver:

• [x] Rename clear() to remove(). (Non-breaking deprecation)

Query Config:

• [x] Remove forceFetchOnMount.
• [x] Change refetchOnMount false behavior to disable refetch on mount for that specific hook

Describe the bug In my scenario I need to host more than one react application on one page. Each of app uses react-query v3, app wrapped with QueryClientProvider (I can reproduce it with CRA apps with just your "overview" sample code (https://codesandbox.io/s/github/tannerlinsley/react-query/tree/master/examples/simple)). When I open page with these apps, only one of them running fine, and others fails with error: No QueryClient set, use QueryClientProvider to set one Maybe it's because of using window.ReactQueryClientContext for context storage of app, what makes impossible to use many react-query context on one page with many apps (https://github.com/tannerlinsley/react-query/blob/master/src/react/QueryClientProvider.tsx#L9).

If I use just one app with many QueryClientProviders it's works ok.

If you can suggest any workarounds for this issue, I will appreciate it. Thank you.

To Reproduce Steps to reproduce the behavior:

1. Build 2 apps with example from here: https://codesandbox.io/s/github/tannerlinsley/react-query/tree/master/examples/simple
2. Host these 2 apps with one html page (I just build two CRA apps and then add div and scripts from one app index.html to another).
3. Serve this overall html (I did just serve -s build).
4. See error. First app crashes, but second runs fine.

Expected behavior Every separate apps runs without react-query related errors and with react-query functionality.

Additional context I tried to add some timeout for render of second app, and it's works but only for the first serve of html. Than, after page reload errors returns.

setTimeout(() => {
  ReactDOM.render(
    <React.StrictMode>
      <App />
    </React.StrictMode>,
    document.getElementById("app2")
  );
}, 1000);

This is a continuation of things described in issue #461. It's a breakout from the closed PR #570 and builds on the merged PRs #584 and #917.

This PR adds a couple of new public APIs:

• dehydrate(queryCache, dehydrateConfig)
• hydrate(queryCache, dehydratedQueries)
• A new hydration/ReactQueryCacheProvider-component with the additional dehydratedState-prop
• useHydrate(dehydratedQueries) - A hook that does hydrate for you in a React-compatible way

Together, this provides a way to dehydrate a cache, pass its serialized form over the wire or persist it somehow, and later hydrate those queries back into an active cache. Main goals are to improve support for server rendering and help with things like persisting to localstorage or other storage.

An important feature of these new APIs is that the shape of the dehydrated cache is meant to be a private implementation detail that consumers should not rely on, which needs to be emphasized in the docs. This means that the de/rehydrate functionality can more easily be built upon in the future without breaking changes.

SSR Example with Next.js

❗ This example previously looked different, but has been updated for useHydrate

A minimal example:

// _app.jsx
import { ReactQueryCacheProvider } from 'react-query/hydration'

export default function MyApp({ Component, pageProps }) {
  return (
    <ReactQueryCacheProvider initialQueries={pageProps.initialQueries}>
      <Component {...pageProps} />
    </ReactQueryCacheProvider>
  )
}

// pages/posts.jsx
import { makeQueryCache } from 'react-query'
import { dehydrate } from 'react-query/hydration'

export async function getStaticProps() {
  const queryCache = makeQueryCache()

  await queryCache.prefetchQuery('posts', getPosts)

  return {
    props: {
      initialQueries: dehydrate(queryCache)
    }
  }
}

function Posts() {
  // This useQuery could just as well happen in some deeper child to
  // the "Posts"-page, data will be available immediately either way
  const { data } = useQuery('posts', getPosts)

  // This query was not prefetched on the server and will not start
  // fetching until on the client, both patterns are fine to mix
  const { data: otherData } = useQuery('posts-2', getPosts)

  // ...
}

Config options

There are a few config options that you can set when dehydrating and hydrating. Most notably is the shouldDehydrate-function, that can filter the queryCache for queries to dehydrate. Usecase when dehydrating is to filter out only the queries you want to persist to localstorage for example.

With or without shouldDehydrate, only successful queries are dehydrated from the cache

dehydrateConfig

type ShouldDehydrateFunction = <TResult, TError = unknown>(
  query: Query<TResult, TError>
) => boolean

interface DehydrateConfig {
  shouldDehydrate?: ShouldDehydrateFunction
}

Questions

These are a few questions I'm not totally certain about myself and might be worth an extra look when reviewing.

~~Should hydration be its own entry point?~~

Solved, is now its own entry point

~~Should dehydrateQuery be included in the official APIs?~~~

Solved, was removed in favour of a shouldDehydrate-function to keep the API lean. Could be exposed publically later on if there is need for it.

~~How should we handle updatedAt?~~

Solved, updatedAt is now hydrated and also used for determining how far into the future staleness should be scheduled.

Can naming be improved?

There are a bunch of new public APIs, so let's get the naming juust right!

I'm sure I've missed a bunch of stuff I wanted to highlight and/or ask, but hopefully this is a good start for getting feedback and questions. 😅

Describe the bug

I have a monorepo with yarn 3 workspaces consisting of the following (as well as other components):

• contracts which uses Orval to create typed react-query hooks from OpenAPI
• ui, a next.js project that has a workspace dependency on contracts and is using above hooks

The only direct dependencies on react-query are through contracts, my UI project does not directly use react-query.

I'm now running into a few issues to do with module resolution, and am not sure how much of this relates to yarn, workspaces, react-query, or next magic.

React-query cannot find QueryProvider

If I make react-query a peer dependency of contracts, then initialize react-query in my next project (set a query provider, etc), then the hooks that use react-query under the hood from contracts do not find the QueryClient. It appears to "see" its own version of react-query even though this is a peer dependency of contracts and I provide it as a direct dependency in ui.

I am able to work around this by having contracts instead directly depend on react-query, and re-export the symbols from react-query (export * from 'react-query'). This appears to give the hooks incontracts` access to the same react-query and the context / query provider is found.

... or at least it was. Without any meaningful changes (I'm working on pinning down the exact change), I am no longer able to do it this way, as react-query now fails to find react. Inside the compiled code of react-query, I am getting React as an undefined symbol and this line blows up var defaultContext = /*#__PURE__*/React.createContext(undefined); iin react/QueryClientProvider.js

I appreciate that this isn't much to go on, but in general, what is the recommended method for providing custom hooks based on react-query in a library in terms of dependencies and configuration of the query client?

Your minimal, reproducible example

N/A

Steps to reproduce

1. Build a library that leverages react-query in custom hooks with react-query as a peer dependency
2. Use the library from above in a different project, providing react-query as a direct dependency
3. Configure react-query with a QueryClientProvider in the dom where the hooks from 1 are being used

Expected behavior

React-query can "see" the context and query provider wired up in the react DOM, even when using peer dependencies and the react-query library is provided as a dependency form the parent project.

How often does this bug happen?

Every time

Screenshots or Videos

No response

Platform

• OS: Ubuntu 20
• Yarn: 3.2.0
• Next.js: 12.1.6

react-query version

3.39.0

TypeScript version

4.6.4

Additional context

No response

This is sort of related to #270. Filing in case we can improve the docs to help others avoid this issue.

When running tests, I ran into this error:

console.error node_modules/react-dom/cjs/react-dom.development.js:88
    Warning: An update to _default inside a test was not wrapped in act(...).

Here's the test:

test('renders the component', async () => {
  await act(async () => {
    const { getByText } = render(<Component />);
    const linkElement = getByText(/Hello/i);
    expect(linkElement).toBeInTheDocument();
  });
});

And here's the component (simplified):

const getPing = async () => {
  const { data } = await axios.get<{ content: string }>(
    getRoutePrefix() + 'ping'
  );
  return data;
};

export default function () {
  const { status, data, error, isFetching } = useQuery('ping', getPing);

  return (
    <>
      <div>Hello!</div>

      <div>{JSON.stringify(status)}</div>
      <div data-testid="testdata">{JSON.stringify(data)}</div>
      <div>Err: {JSON.stringify(error)}</div>
      <div>{JSON.stringify(isFetching)}</div>
    </>
  );
}

In #271 there was some cleanup logic added, however the error in my case appears to have been thrown before the cleanup call was fired.

I can fix the issue by adding to my tests at the end of each act call:

- import { render, wait } from '@testing-library/react';
+ import { render, wait, cleanup } from '@testing-library/react';

test('renders the component', async () => {
  await act(async () => {
    const { getByText } = render(<Component />);
    const linkElement = getByText(/Hello/i);
    expect(linkElement).toBeInTheDocument();
+   cleanup();
  });
});

Doing the cleanup outside the act does not help; that appears to be too late.

Is it necessary to add the cleanup call inside every act call? If so, can we update the react-query docs on how to test with jest + react-testing-library? I bet others will run into this issue as well and hoping to save some time as more users adopt the library.

Here's some screenshots with a debugger attached indicating the warning is originally caused by a call to refetch:

Versions:

@testing-library/[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

This adds support for passing in a context as other robust libraries (such as Redux) support: https://react-redux.js.org/api/provider#props.

This is important as right now React Query supports creating multiple queryClient instances but does not currently support the ability to specify which queryClient instance should be used with useQueryClient. In the case of nested QueryClientProvider instances in an application, the ability to specify which context (and thus which QueryClientProvider and queryClient) should be used is critical. This adds such capability.

These changes should be 100% backwards compatible.

Describe the bug

Hi,

I'm trying out 4.0.0-beta.7 to implement offline support in our application.

Everything is upgraded including all the breaking changes, but my queries are not being executed anymore. To be sure it's not a problem inside my application, I've created a fresh expo app with just the App.tsx file.

When opening the app, my queries remain in a loading state. If I use the refetch of the useQuery, and run this in a useEffect, I'm able to execute the query.

Your minimal, reproducible example

Couldn't get react-query to work in expo snack

Steps to reproduce

1. Create a react-native application with the following package.json file

{
  "name": "reactqueryv4",
  "version": "1.0.0",
  "main": "node_modules/expo/AppEntry.js",
  "scripts": {
    "start": "expo start",
    "android": "expo start --android",
    "ios": "expo start --ios",
    "web": "expo start --web",
    "eject": "expo eject"
  },
  "dependencies": {
    "expo": "~44.0.0",
    "expo-status-bar": "~1.2.0",
    "react": "17.0.1",
    "react-dom": "17.0.1",
    "react-native": "0.64.3",
    "react-native-web": "0.17.1",
    "react-query": "4.0.0-beta.7"
  },
  "devDependencies": {
    "@babel/core": "^7.12.9",
    "@types/react": "~17.0.21",
    "@types/react-native": "~0.64.12",
    "typescript": "~4.3.5"
  },
  "private": true
}

2. Create a query with a simple async function

import { Text, View } from "react-native";
import { QueryClient, QueryClientProvider, useQuery } from "react-query";

export default function App() {
  const queryClient = new QueryClient();

  return (
    <QueryClientProvider client={queryClient}>
      <Todos />
    </QueryClientProvider>
  );
}

function Todos() {
  // Queries
  const query = useQuery(["todos"], async () => {
    console.log("this should log but doesn't");

    return Promise.resolve("ok");
  });

  console.log(query.data);

  return (
    <View>
      <Text>lol</Text>
    </View>
  );
}

3. Open your application and you will see undefined query data, a status loading and no console.log.

Expected behavior

I expect this query to be executed. If I change my package.json to the latest v3 version, my query get's executed as it should.

How often does this bug happen?

Every time

Screenshots or Videos

No response

Platform

• iOS, Android

react-query version

4.0.0-beta.7

TypeScript version

No response

Additional context

No response

Export defaultShouldDehydrateQuery and defaultShouldDehydrateMutation to make it easier to retain the default behavior when extending these in the dehydrateOptions

Describe the bug

The data returned by useQuery is wrapped in a Ref object with an additional layer of Reactive wrapping inside. When I attempted to modify it, Vue gave me a warning that it is not modifiable.

Your minimal, reproducible example

null

Steps to reproduce

In the Vue devtools, it shows as Reactive.

Expected behavior

[Vue warn] Set operation on key "desc" failed: target is readonly. Proxy {id: 67, name: 'library/xmrig/xmrig:v1', desc: '', image_list: Array(1), node_list: null, …}

How often does this bug happen?

Every time

Screenshots or Videos

No response

Platform

Win11 Chrome latest Vue latest

TanStack Query version

vue-query 4.20.5

TypeScript version

4.9.4

Additional context

No response

This PR attempts to close https://github.com/TanStack/query/issues/3706

Opened questions

• How to write a test for my fix? It looks quite complex, so I need an e2e test?

@TkDodo fyi, cause you have the context of the issue)

This PR attempts to close #4681, one of the v5 react query milestone issues.

I have:

• Removed contextSharing from react-query and updated / removed the tests.
• Removed contextSharing from solid-query and updated / removed the tests.
• Removed contextSharing from vue-query and updated / removed the tests.
• Removed the contextSharing documentation from the QueryClientProvider reference documentation
• Added a section to the v5 migration guide about the removal of this property. I think this documentation could probably be better, I used information from both the issue #4681 and the linked discussion in #2810 to try and explain this. I suppose I could add an example of what I have described in this documentation, are there any good examples of how to document a code example for multiple packages like this within other parts of the documentation?