apollo-client: previousResult is undefined when using updateQuery in fetchMore

Intended outcome: The previousResult variable should contain the previous data.

Actual outcome: The previousResult is undefined

How to reproduce the issue: I followed the tutorial on this page using the Relay-style cursor pagination. After switching everything to the latest stable apollo version the previousResult variable contains the data.

fetchMore({
          variables: {
            cursor: comments.pageInfo.endCursor
          },
          updateQuery: (previousResult, { fetchMoreResult }) => {
            const newEdges = fetchMoreResult.comments.edges;
            const pageInfo = fetchMoreResult.comments.pageInfo;

            // Apollo v3 Beta
           // previousResult is undefined

           // Apollo latest stable version
           // previousResult contains the data

            return newEdges.length
              ? {
                  // Put the new comments at the end of the list and update `pageInfo`
                  // so we have the new `endCursor` and `hasNextPage` values
                  comments: {
                    __typename: previousResult.comments.__typename,
                    edges: [...previousResult.comments.edges, ...newEdges],
                    pageInfo
                  }
                }
              : previousResult;
          }
        })

Versions v3.0.0-beta.20

About this issue

  • Original URL
  • State: open
  • Created 4 years ago
  • Reactions: 4
  • Comments: 17 (4 by maintainers)

Most upvoted comments

@Thomazella - Did you add a console logger in the area I recommended above? It sucks to add a logger there, but it helped me track down some issues that weren’t escaping in an obvious way. If using npm to install it, you’ll have to add it to the transpiled code, but it isn’t so bad. Also, feel free to ignore this if not using the InMemoryCache.

I’m experiencing the same issue in @apollo/client@3.2.2 when using useQuery. Any updates on this issue? I’ve noticed also the error is not deterministic and seems to be related to network latency.

@soltysaleksandr workaround works but it would be nice if it would work out of the box

const { data, fetchMore } = useQuery(SOME_QUERY);

instead of this

fetchMore({
        variables: { ... },
        updateQuery: (prev: any, { fetchMoreResult }) => {
          if (!fetchMoreResult) return prev;
          return {
            fetchedData: {
              ...prev?.fetchedData,
              data: [...prev?.fetchedData?.data, ...fetchMoreResult?.fetchedData?.data],
            },
          };
        },
      });

I do something like that, and it’s solve the pb

fetchMore({
        variables: { ... },
        updateQuery: (prev: any, { fetchMoreResult }) => {
          if (!fetchMoreResult) return prev;
          return {
            fetchedData: {
              ...data?.fetchedData,
              data: [...data?.fetchedData?.data, ...fetchMoreResult?.fetchedData.?data],
            },
          };
        },
      });

Just to check, updateQuery as a property on the fetchMore API is deprecated, but updateQuery as a direct API call is still a valid property on a query result, correct?

Correct!

@benjamn - Sorry, I didn’t explain quite well enough. Let me try harder.

This is a simplification of my schema.

type Item {
  ID: Int
}

type Account {
  accountItems: [Item]
}

type User {
  accounts: [Account]
  topItems: [Item]
}

type Schema {
  mainUserQuery: User
  fetchSomeTopItems(inputs): [Item]
  fetchSomeAccountItems(inputs): [Item] 
}

The schema here is type Schema. Type User is meant to be the shape of the main user query.

Now, in my app I call fetchMore with fetchSomeTopItems at some point, and fetchMore with fetchSomeAccountItems at other times. With updateQuery I would append to topItems, or accountItems as needed using some factory reducer. With cache policies, I don’t see how I could do this.

Ah, I see your update. Okay, so I should just use the promise result from fetchMore and use the updateQuery API manually. That makes sense, thank you for your answer.

Just to check, updateQuery as a property on the fetchMore API is deprecated, but updateQuery as a direct API call is still a valid property on a query result, correct?

@benjamn - I don’t mean to spam you guys too much, but if you add a logger right here letting people know the mine cart just left the tracks a bit, you may have a lot less vagueness and confusion in which issues get reported:

https://github.com/apollographql/apollo-client/blob/a877d4b0d0a7a2c09a3ceb83c637d65e57b206bc/src/cache/inmemory/readFromStore.ts#L179

Generally, any time I am having issues on 3.x, my first step is to add a logger to this, and then I know which fires to fight before I get to undefined client data on an updateQuery call.

I’m not trying to spend too much of your time. I just wanted to recommend this logger to help keep others from being confused with your time.