Apollo-client: @connection causing query not to refetch when props change

[wesbos]

I'm using @connection to rename my queries as they are really long and contain pagination data:

export const ALL_ITEMS_QUERY = gql`
  # Import the Fragment
  ${itemDetails}
  query AllItemsQuery($skip: Int = 0, $first: Int = 3) {
    itemsConnection(orderBy: createdAt_DESC, first: $first, skip: $skip) @connection(key: "itemsConnection") {
      aggregate {
        count
      }
    }
    items(orderBy: createdAt_DESC, first: $first, skip: $skip) @connection(key: "items") {
      ...itemDetails
    }
  }
`;

and the Query:

        <Query
          query={ALL_ITEMS_QUERY}
          variables={{
            skip: this.props.page * perPage - perPage,
            first: perPage,
          }}
        >
          {({ data, error, loading }) => {
            if (loading) return <div>Loading</div>;
            if (error) return <div>Error</div>;
            return <Items key={this.props.page}>{data.items.map(item => <Item key={item.id} item={item} />)}</Items>;
          }}
        </Query>

Intended outcome:

When the page changes, the Query should re-fetch the data based on the new props.

Actual outcome:
The query re-runs the function, the variables object is updated with the correct data, but the query is not refetched. No network activity is present.

If I take the @connection off, it works as normal.

I'm wondering if because the query's name doesn't change when the props are updated, it's not triggering a refetch

[email protected]

I talked to @jbaxleyiii and @peggyrayzis on Slack about this but I thought I'd document it incase anyone else is having a similar issue

[wesbos]

An update on this - still an issue.

If I set fetchPolicy="cache-and-network" it forces the network request to fire and updates the cache

So it seems the problem is with @connection normalizing the query, and then when the props change, it things it's still the same query, and just pulls the values from the cache...

[wesbos]

This might be related to this:

https://github.com/apollographql/apollo-client/issues/3248

And this:

https://github.com/apollographql/apollo-client/issues/2119

[baleeds]

This is a large problem for us. We have a paginated list with a search filter:
<SelectorSearchQR inputString={searchText} />

Which loads a paginated list based on the search query. When adding @connection to our query, we can no longer run the Apollo query when the search string changes.

[ffxsam]

Is this still an issue? I tried to use @connection so that various combinations of options supplied to my query (sort column, sort order, search text) would be cached under a single object. That way, if sort=name and order=asc, and someone removes ID 21, that item is purged from the cache no matter what the sort/order values are. It doesn't work for me, though.

[agu-z]

This is still an issue in 2.5.1

[jbaxleyiii]

Thanks for reporting this. There hasn't been any activity here in quite some time, so we'll close this issue for now. If this is still a problem (using a modern version of Apollo Client), please let us know. Thanks!

[raysuelzer]

This is still an issue in 2.6.4. It actually seems to be that String variables are not handled properly by the @connection filter directive... The filter key works fine with the other types I have tried, but it doesn't seem to update if the filter key is a StringValue. I've been looking at this for a few hours, still haven't 100% figured it out. Unfortunately, I can't upgrade right now due to the lack of angular support for apollo 3, as well as the breaking changes.

Edit:

calling .setVariables(variables) before fetchMore seems to work. Although, it might have other side effects I haven't noticed yet.

       this.resultsQuery.setVariables(variables);


        return this.resultsQuery.fetchMore({
            variables: variables,
            updateQuery: (prev, { fetchMoreResult }) => {
                const nextState = produce(prev, (draft) => {
                    draft.searchTags.nodes = _uniqBy([...draft.searchTags.nodes, ...fetchMoreResult.searchTags.nodes], n => n.id);
                });
                return nextState;
            }
        });

[raysuelzer]

Spent a long time debugging this. The issue appears to be that the previous results are being fetched before the new variables are applied, this makes sense since we are fetching more.

In my case, I am searching on a keyword, and then paginating the results. keyword is a filter on the @connection directive.

This essentially means that it is an entirely new query as their are no previous results. However, since fetchmore uses the previous variables to find the previous results, it doesn't know that it's an entirely new query.

So, I guess what I need to do is detect if the keyword input variable has changed, and if it is has, then i need to create a new query and then do fetchMore.