Initial implementation of fetchMore

[Slava]

TODO:

• Update CHANGELOG.md with your change
• Make sure all of the significant new logic is covered by tests
• Rebase your changes on master so that they can be merged easily
• Make sure all tests and linter rules pass

Design:

• fetchMore method on an observable query
• allows to fetch the same query, or a new query with any amended variables, fragments, etc
• the results of the fetchMore query always are fetched from the server
• the reducer function passed into fetchMore is responsible for merging the new result into the existing query results

[stubailo]

I don't think options should be "any" here

[Slava]

yeah, I should change these to have the precise fields.

[rricard]

If you need any help, just ask me @Slava, even if it's just writing tests!

[Slava]

The initial implementation completed. Have two tests covering all base cases. Still need docs, and some things.

@stubailo might want to look at the following "problem" in the API:

The reducer function receives two arguments: previousResult and the options with the fetchMoreResult.

• Since previousResult is coming from the store, currently it looks like a plain result of the query not wrapped into { data: { ... }, errors: [] }.
• On the other hand, we pass the query result from fetchMore options, directly into the reducer through fetchMoreResult and it is wrapped into { data: { ... }, errors: [] }.
• Working with this API, the application developers are forced to face this inconsistency.
• The same is true for mutations, the mutationResult is wrapped, the previous query result is not

The ways we can improve it include:

• never pass wrapped values (need to think more if any error handling is damaged by such change)
• always pass wrapped values (annoying to work with)

Either way, it will be a breaking change to mutations.

Resolution: Keep it as is for now. We can make another breaking change later if needed. The reasoning is to keep the wrapped objects, in case there is a different way of handling a query with errors. (cc @stubailo)

[rricard]

Hey @Slava ! Any progress on this ? Do you need any help ?

[Slava]

@rricard Hi! No, I think this implementation is complete. We are working on merging it right now.

[rricard]

ok, I'll try that right away and give you feedback since the react-apollo PR seems to be there too!