apollo-client: QueryObservable `currentResult` behavior seems to be buggy

QueryObservable returned from client.subscribe seems to assign the immediate query result (from APOLLO_QUERY_RESULT to lastResult and returns an empty object from currentResult immediately following.

This seems to break react-apollo here.

This bug appears to express itself only in areas of our app where we are rendering a list server-side and then clicking a link on that list to navigate to a “more details” view for the list item.

  • If I set ssr to false for the list view, the bug does not occur.
  • If the user navigates to the list and the data is fetched from the client, this bug doesn’t present itself.
  • If I click the back button from the details view and select the same, or a different, list item the bug doesn’t present itself a second time without a browser refresh.

It seems to be some sort of bug with state somewhere in either apollo-client or react-apollo. The bug causes the details view to remain in “loading state” forever because the query result is never passed into the view via @graphql#props callback even when loading becomes false and the query result has been digested into redux.

Screenshots

Query result during breakpoints screen shot 2017-03-09 at 10 01 00 am

QueryObservable#lastResult contains the query result and QueryResult#currentResult() returns an empty object screen shot 2017-03-09 at 10 14 32 am

props callback in @graphql does not contain user screen shot 2017-03-09 at 10 18 14 am screen shot 2017-03-09 at 10 16 41 am

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 2
  • Comments: 17 (11 by maintainers)

Most upvoted comments

Some more debugging… FWIW when a refetchQueries: myQuery is called for an unmounted graphql(myQuery), this bug seems to occur when it is mounted again. Trying to repo in the error template repo…

FWIW, we discovered today that running the graphql HoC twice on a single component with two different queries caused this to happen. By merging both queries together, the bug went away. I’ve been planning on implementing a test case to reproduce, and will hopefully have time to do so pater this week