Duplicate useQuery()s in the same component causes "Invariant Violation: Too many re-renders" during SSR

[ThomasJClark]

Describe the bug
After upgrading to urql 1.6.1, a component with two useQuery calls that previously worked is now causing React to throw invariant violation errors during SSR.

Steps to reproduce

In a functional component, call useQuery with the same query and variables more than once.

const MyComponent = () => {
  const [res] = useQuery({ query: DemoQuery, variables: { id: 569188001 } });
  const [res2] = useQuery({ query: DemoQuery, variables: { id: 569188001 } });
  return null;
}

Expected behavior
The component renders with res.data and res2.data containing the same data

Actual behavior
React throws an error Invariant Violation: Too many re-renders. React limits the number of renders to prevent an infinite loop.

[samkline]

Just to speculate a bit, we may not be able to reproduce this on the client because we use the dedupe exchange there. During server-side rendering, we do not use the dedupe exchange, and instead have a custom exchange to handle de-duping, batching, and execution.

This didn't cause a render loop in Urql 1.5.0, so I suspect the recent changes away from useImmediateState/useImmediateEffect caused it.

Edit: I added the dedupe exchange to SSR and it resolved one of the two instances of this problem. The two instances are on distinct pages and in distinct components so there are likely to be other differences between them.

[kitten]

That’s very interesting. I suppose it could be caused by updates that are being accidentally triggered on both hooks that keep triggering more mutual updates between them.

I’ll look into this and will see whether there’s an easy solution for this problem!

[kitten]

Hiya, on second thought, we may need a reproduction here. Your custom exchange sounds rather interesting and I’m wondering whether that’s what’s causing a weird interaction with the changes we’ve made and the ssrExchange.

[marcusdarmstrong]

Well, as it happens we've never gotten around to masking our jsx source from the public internet, so: https://www.tripadvisor.com/components/packages/platform/urql/ssrFetchExchange.jsx

That's the only exchange we've configured for our SSR pass.

[kitten]

Alright, I think I've finally narrowed down the problem and have a PR with a fix open, so this will be fixed in the next patch release

[samkline]

Thanks for the quick fix, @kitten !

[kitten]

This has now been published as part of https://github.com/FormidableLabs/urql/releases/tag/v1.6.2
Sorry for the delay! ❤️