queryVariables returned by updateQuery contain stale values

While implementing pagination for a graphQL+React app, the updateQuery method passed as an option to fetchMore also contains queryVariables as an argument, which are returned by fetchMore. However, queryVariables contain the variables for the original query, not the updated ones passed to fetchMore. This seems counter-intuitive, as one would expect the updated variables to be returned by the query.

Here is a replication of the code in the Githunt example:

const withData = graphql(FEED_QUERY, {
  options: props => ({
    variables: {
      type: (
        props.params &&
        props.params.type &&
        props.params.type.toUpperCase()
      ) || 'TOP',
      offset: 0,
      limit: ITEMS_PER_PAGE,
    },
    forceFetch: true,
  }),
  props: ({ data: { loading, feed, currentUser, fetchMore } }) => ({
    loading,
    feed,
    currentUser,
    fetchMore: () => fetchMore({
      variables: {
        offset: feed.length,
      },
      updateQuery: (prev, { fetchMoreResult, queryVariables }) => {
        // Here, queryVariables contains {offset: 0, limit: 10}
        // even though the value of offset is updated above and should be equal to feed.length.
        if (!fetchMoreResult.data) { return prev; }
        return Object.assign({}, prev, {
          feed: [...prev.feed, ...fetchMoreResult.data.feed],
        });
      },
    }),
  }),
});```

[HeatherZh]

Thanks for your comments @helfer. I tried both react-apollo 0.8.3 and the most recent release of 1.1.1 and both have the same issue of having queryVariables returning the original data. I was able to get the variables passed to fetchMore in the closure. I would think it might be better not having queryVariables at all since both the original variables and the ones used in fetchMore are available in updateQuery scope. I will add a short description to the use-cases and how I handled the scenario later today. Thanks again!

[helfer]

@HeatherZh I think this may be due to a bug. The variables you get should be the variables of the base query at the time the fetchMore request was made. Is that not the case?

As for knowing which fetchMore result is being returned, I think using a closure is probably the easiest and most flexible option. You could technically also use that to know what the query variables were at the time fetchMore was called (unless I’m missing something).

Your use case seems to be a common scenario for working with timeline data, so we’d like to make it as easy as possible. Could you add a short description to the use-cases issue on react-apollo so we can keep track of it? Thanks!