Using setQueryData with Playwright cause circular reference

[yu-nobara]

Hello,

I have questions about react-query with playwright.

Context

I'm using Playwright component test for testing react components.

Experimental: components | Playwright

But, I wrote below codes and run test so undefined: Maximum call stack size exceeded error occurred.

import MyComponet "./my-component";
import { test, expect } from "@playwright/experimental-ct-react";
import { QueryClientProvider, QueryClient } from "react-query";

test("test sample", async ({ mount, page }) => {
  const queryClient = new QueryClient();

  queryClient.setQueryData("key", { username: "foo"});

  const component = await mount(
    <QueryClientProvider client={queryClient}>
      <MyComponent />
    </QueryClientProvider>
  );
});

I investigated react-query code and I found out that QueryCache object will be created circular reference when setQueryData is called.

query/packages/query-core/src/queryCache.ts

Lines 101 to 111 in 52acd78

	query = new Query({
	cache: this,
	logger: client.getLogger(),
	queryKey,
	queryHash,
	options: client.defaultQueryOptions(options),
	state,
	defaultOptions: client.getQueryDefaults(queryKey),
	meta: options.meta,
	})
	this.add(query)

On the other hand, when mount is called in Playwright code, queryClient object which has circular reference will pass to wrapFunctions finally.

https://github.com/microsoft/playwright/blob/3dc1920ce83b56a408d84e2d43e07ec8976d924d/packages/playwright-test/src/mount.ts#L117-L128

This function reference object recursively, so undefined: Maximum call stack size exceeded is occurred.

As workaround, I create wrapper component and import it, so well done.

import { QueryClientProvider, QueryClient } from "react-query";

export default function QueryClientProviderWithData({ children }: { children: JSX.Element }) {
  const queryClient = new QueryClient();
  queryClient.setQueryData("key", { username: "foo"});

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

import MyComponet "./my-component";
import { test, expect } from "@playwright/experimental-ct-react";
import QueryClientProviderWithData from "./query-client-provider"

test("test sample", async ({ mount, page }) => {
  const component = await mount(
    <QueryClientProviderWithData>
      <MyComponent />
    </QueryClientProviderWithData>
  );
});

Question

1. Do you have any other workaround?
2. Do you have plan to remove circular reference in QueryCache object?

Thank you,

[TkDodo]

I investigated react-query code and I found out that QueryCache object will be created circular reference when setQueryData is called.

I don't see the circular reference. All that setQueryData does is to create an entry in the cache...

your component looks fine if you only mount the component once, which is true for testing. Otherwise, I'd put the queryClient in state:

const [queryClient] = React.useState(() => {
  const client = new QueryClient()
  client.setQueryData(...)
  return client
})

[nishitaniyuki]

All that setQueryData does is to create an entry in the cache...

• The entry has a reference to the cache(Query.cache).
• And the cache has a reference to the entry(QueryCache.queries).

Both of these are private members in terms of TS, but that seems not the case for the generated JS.
And this results in a circular reference at runtime.

Do you have any plan to replace TypeScript private keywords with ECMAScript private fields?

[TkDodo]

Do you have any plan to replace TypeScript private keywords with ECMAScript private fields?

I've looked into this once, especially because private class fields can be safely minified and thus reduce bundle size. However, the browsers we are currently targeting (https://tanstack.com/query/v4/docs/installation#requirements) do not all support private class fields (https://caniuse.com/mdn-javascript_classes_private_class_fields). According to this blog post, the runtime overhead added is probably not worth it.

If this request came before we released v4, we could've considered it :)

[nishitaniyuki]

Thanks for a reply. Then looking forward to the v5 :)