I'm seeing this error logged in a production app every so often:
undefined is not an object (evaluating 'this.store[o].networkStatus=t.NetworkStatus.ready')
I believe I've traced it to here:
https://github.com/apollographql/apollo-client/blob/6abcd727818398bff53bcd73e09a29b902557cc2/packages/apollo-client/src/data/queries.ts#L128-L130
I see above this function checks for the existence of this.store[queryId], would it make sense to do a similar check for this.store[fetchMoreForQueryId] inside of this conditional? Happy to open a PR, if so.
Trying to think through what could be happening....a fetchMore is triggered, and then resolves after the component is unmounted perhaps? Not sure of how the lifecycle on the graphql HOC plays here.
I noticed this as well. Does your app use SSR? The way I can reproduce it 100%:
fetchMore queryfetchMore completes (trigger a slow network in dev tools)I am unable to reproduce this without that initial SSR. So if I load a page on the client that fires a fetchMore, it completes without error, even if the component has dismounted.
In my mind, a dismount should not cause any queries in flight to fail, but it looks to be related to SSR.
No, this is a React native app. So doesn鈥檛 seem to be the case for us
I am facing similar issue.
same
馃憢 Surfing in here from Google. To add more background to this for anyone else, we encountered this error as well, but only on some of our FlatLists. Then I figured out they differed in how we were working around this bug in FlatList which fired our onEndReached function multiples times on component unmount. By avoiding these spurious calls in "user-land", it fixed the crash in this issue (also saving wasted network requests!).
So while I don't know _exactly_ what's going on in Apollo when a component is unmounted when multiple queries are in flight, I believe this is the a deeper, root cause.
Why is this closed? I'm still encountering the issue and submitted a PR #3914
Most helpful comment
馃憢 Surfing in here from Google. To add more background to this for anyone else, we encountered this error as well, but only on some of our FlatLists. Then I figured out they differed in how we were working around this bug in FlatList which fired our
onEndReachedfunction multiples times on component unmount. By avoiding these spurious calls in "user-land", it fixed the crash in this issue (also saving wasted network requests!).So while I don't know _exactly_ what's going on in Apollo when a component is unmounted when multiple queries are in flight, I believe this is
thea deeper, root cause.