fetchMore warning : missing __typename & loadingKey not decreased

[SebT]

Hi.

First problem
If I define a query in my component like this:

export default {
  // ...
  apollo: {
    users: {
      query: myQuery,
      update: (data) => data.users.getAll,
      loadingKey: 'loading',
      watchLoading(loading, modifier) { console.log(loading, modifier) },
      variables () { return this.emailFilter }
    }
  }
// ...
}

The code above works fine.

this.apollo.queris.users.fetchMore({
  // ... variable here for pagination "limit" (page size) and "after" (cursor)
 updateQuery: (previousResult, { fetchMoreResult }) => {
    return {
      user: {
        getAll: [
          ...previousResult.user.getAll,
          ...fetchMoreResult.user.getAll,
        ],
        __typename: previousResult.__typename
    }
  }
})

This works fine. But if I have to set __typename manually or I get a warning about it missing.
Is this normal ?

Second, actual problem
In updateQuery if fetchMoreResult.user.getAll is an empty array (when the pagination is over), the loadingKey is never decreased and watchLoading doesn't print false, -1.

Steps to reproduce :

1. Call fetchMore: new users received : everything is fine, the loading key is increased then decreased
2. Repeat step one several time : as long as some users are returned, everything is fine
3. Call fetchMore: no new users received (empty array from graph). The loading key was correctly increased but never decreased.

[Akryum]

This works fine. But if I have to set __typename manually or I get a warning about it missing.
Is this normal ?

This is as intended. There is no magic, you have to return the _typename if you create a new object.

[SebT]

@Akryum, yes I figured that later. But the second (actual) problem is still happening when I set the typename. So please don't close the issue yet.

A workaround would be to edit the sever to add a 'hasMore' property and don't call fetchMore if it's false. But there's still an issue with the loadingKey.

[Akryum]

Did you try the latest version?

[SebT]

You're right, it's working now. Thanks.

[Akryum]

You even have the commit fixing it ⏫