React-apollo: Nesting <Query> components results in infinite loop

[timsuchanek]

Intended outcome:
Having a nested structure of components, without them rerendering the whole time.

Actual outcome:
As soon as a graphql(Component) or <Query> component has a <Query> child,
the parent is constantly refetching.

Version

• [email protected]
• [email protected]

[excitement-engineer]

Hey @timsuchanek! Could you provide a reproduction of this as a test case?

Can I ask why you are nesting two Query components? You can retrieve all the data you want in a single query so I am wondering why you would nest query and make multiple roundtrips to the server

[lifeiscontent]

@excitement-engineer I could imagine a case where you want to grab the props of a user and then depending on those props you would query another resource.

[kandros]

Personally I use a lot of component-specific queries con containers, that are often nested

[LawJolla]

I have the same issue. This seems like it would be a common use case for reuseable components where each component defines its own data.

[LawJolla]

I've been trying to replicate this issue in a simple repo without much luck. I base this Codesandbox off this example.

Here's my code sandbox with nested queries that work. Please feel free to see if anyone can make it infinitely loop.

https://codesandbox.io/s/l7mlr10q8z

[geminiyellow]

same error

[maalej]

@LawJolla this code is infinite looping

export default () => (
  <Query query={GET_CURRENT_FILTERS}>
    {
      ({ loading, error, data, client }) => {
        if (loading) return <div>Loading...</div>;
        if (error) return <div>Error</div>;
        const {filters} = data;
        return (<Query
          query={GET_GLOBAL_INDICATORS}
          variables={filters}>
          {({ loading, error, data, client }) => {
            if (loading) return <div>Loading...</div>;
            if (error) return <div>Error</div>;

            return (
              (<MyComponent items={data.items} />)
            );
          }}
        </Query>)
      }
    }
  </Query>
);

[tgreen7]

@timsuchanek This is a huge issue. I just spent the past few days refactoring stuff for the new api and then hit this bug. We sometimes have up to 10 nested queries and it is crashing the app.

[LawJolla]

@maalej what's the relevance of that code?

[cigrainger]

@tgreen7 @timsuchanek I'm having the same problem.

[Jaynarol]

I'm having the same problem too.

[du5rte]

I've also come across this problem. Any resolutions?

[scfoxcode]

Came across this issue too. Some components are borderline unresponsive

[BipinBhandari]

I am facing this issue on react-native and there are no workarounds. I am facing 3 unique apollo specific issues, all open issues without any concrete solution :(

[LawJolla]

I worked very hard to distill this problem into a neat Codesandbox but couldn't do it. The problem occurred in my app but I couldn't extract it. That strongly suggests the problem is with my code.

It would be incredibly helpful if someone could extract that problem into an repo or sandbox.

[thomassuckow]

Ran into not quite the same issue today but I think it is related.

If I have the following:

compose(
  graphql(SlowQuery),
  graphql(FastQuery, {
    name: 'fastQuery',
  })
)(MyComponent);

Then in some* cases MyComponent gets remounted when SlowQuery completes.

* It doesn't seem to do it every time and seems to depend on the children of MyComponent, it may have to do with graphql queries in MyComponents children.

[booboothefool]

I think I'm encountering this. When I go to the only screen on my app with nested queries (query to get a set of filters from the local state, then query with those filters, very similar to @maalej), everything else just slows down and explodes. The app runs fine as long as I never go to that screen! Very interesting.

[lifeiscontent]

@booboothefool can you create a code sandbox with reproducible error?

[booboothefool]

@lifeiscontent My mistake - it so turns out the nested queries works just fine for me, and that my issue was caused by another component on that screen. Specifically, the other component was doing a ton of console.log which crippled performance, and I learned that Expo does not remove them for me on production publishes.

[lifeiscontent]

@timsuchanek do you still have this issue? Or can we close it? What's the status?

[rosskevin]

I have many nested queries in render trees and I don't have a problem. We do have reported unnecessary re-renders on Query and those issues are open to be addressed.

Since is quite old and I'm very sure that I have nested Query components in a render tree, I'm going to close. If you can reproduce- awesome! It would be fantastic if you could PR any kind of breaking test - this will get attention the fastest.

[scottburch]

For anyone who might read this, I had the same thing happen. Endless loop with a query. I could reproduce reliably. What I think I found was that I had two components that needed the same info, so they had very similar queries with the same name. I renamed one of the queries and the loop stopped.

As a test I put two queries in pointing to the same gql instance. Same thing happened. They don't have to be nested. Just two queries with the same name. The following caused a loop

const XXX = gql`
    query xxx($userId: id!) {
        user(id: $userId) {
            id
        }
    }  
`;


<div>
        <Query query={XXX}>
            {() => console.log('query 1') || null}
        </Query>

        <Query query={XXX}>
            {() => console.log('query 2') || null}
        </Query>
</div>

Hope this helps someone else.

@rosskevin FYI in case this helps. Seems like a pretty serious problem that needs to be fixed.

[rosskevin]

@scottburch I'm not sure there is a reasonable solution to that (effort wise). Two observers watching and updating the same observable will constantly fight in an infinite loop. This cycle is not something easily detected. In any case, react-apollo is a consumer of the observable and that code would reside in that apollo-client not here.

I suggest checking out the apollo-client unit tests and PRing a breaking test if it is something you are serious about solving. Every bit of effort helps.

[scottburch]

@rosskevin Thanks for the follow up. I mostly put it here in case it was easy, and to let others know about the issue if they search for it.