We are building&nbsp;<a href="https://github.com/apollostack/apollo-client" target="_blank" rel="noreferrer noopener">Apollo Client</a>&nbsp;— a GraphQL client that helps you fetch data, organize your store, and keep your client state in sync with the server.



In modern web and mobile applications, users often consume endless streams of data. In a way, apps provide a “window” into the vast array of information that a service can provide: posts, photos, comments, messages and more. It’s now a widely-adopted interface to show part of big list on a screen while loading it part by part in the background, giving the user the feeling of navigating seamlessly. This is what developers call “Infinite Scrolling”.



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="884" height="663" src="https://apollographql.wpengine.com/wp-content/uploads/2020/03/1_6727j2BrMrfiAqdzSEezdg.gif" alt="" class="wp-image-297"/><figcaption>Infinite Scrolling: new items are loaded as the scrolling reaches the bottom of the list</figcaption></figure>



Built-in infinite scroll support was one of the most-requested features in Apollo Client, and we had many discussions in the GitHub issues about possible designs.



One important concern was ensuring that Apollo Client’s normal caching behavior worked in a reasonable way with this new feature. When Apollo Client fetches a query from the server, the result is normalized from a big, tree-like query result into individual objects with IDs and fields, enabling Apollo Client to update these objects from mutations (and soon subscriptions), and have the new results show up in all queries that reference that object.



After investigating lots of possible solutions, we came up with the solution I want to show you today:&nbsp;fetchMore.



<h2 class="wp-block-heading" id="20c9"><a href="#the-solution-fetchmore" aria-hidden="true" class="aal_anchor" id="the-solution-fetchmore"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>The solution: fetchMore</h2>



The new&nbsp;fetchMore&nbsp;method on Apollo Client query observables provides a way for applications to query additional data and add it to the store, updating the original query result. This way, the application can take advantage of all the benefits of cache normalization while incrementally fetching new paginated data.



Here is an example of a query that fetches posts based on a cursor:



<pre class="wp-block-preformatted">const query = client.watchQuery({ query: gql` query Posts($cursor: String) { feed { nextCursor entries(cursor: $cursor) { id title content author { name } } } } `, // first fetch, no cursor provided variables: { cursor: null }, });</pre>



In Apollo Client,&nbsp;watchQuery&nbsp;returns an observable that can be fed into the UI or other parts of an application interested in this data. In this case, the result of the query includes a pagination cursor, which we would like to save and pass to the server with our next query to continue fetching from the same generated list.



When the application needs to load more data — for example, if the user scrolled through the whole list of available posts—you can simply call&nbsp;fetchMore&nbsp;with the new cursor to get more data. The&nbsp;updateQuery&nbsp;function specifies how the new results should be merged with the previous result:



<pre class="wp-block-preformatted">// fetch more data, reusing the same query, // but passing different variables query.fetchMore({ variables: { cursor: lastPaginationCursor }, // concatenate old and new entries updateQuery: (previousResult, { fetchMoreResult }) =&gt; { const newEntries = fetchMoreResult.data.feed.entries; return { feed: { nextCursor: fetchMoreResult.data.feed.nextCursor, entries: [...previousResult.feed.entries, ...newEntries], }}; }, });</pre>



Under the hood, Apollo Client figures out how the merged query results should be normalized into individual objects with updated fields based on their&nbsp;ids. The&nbsp;query&nbsp;observable will fire a new value and the UI listening to the observable will be updated accordingly.



Read more about using pagination features and&nbsp;fetchMore&nbsp;in the&nbsp;<a href="http://docs.apollostack.com/apollo-client/pagination.html" target="_blank" rel="noreferrer noopener">Apollo Client docs</a>.



<h2 class="wp-block-heading" id="be4f"><a href="#configuration-over-convention" aria-hidden="true" class="aal_anchor" id="configuration-over-convention"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Configuration over convention</h2>



This API favors manual configuration over a&nbsp;<a href="https://facebook.github.io/relay/graphql/connections.htm" target="_blank" rel="noreferrer noopener">more strictly specified</a>&nbsp;pagination structure, like you would see in Relay. This is intentional. Our goal was to build an API that would be easy to use, yet flexible enough to work with any pagination schema you could implement in your GraphQL server: cursor-based, offset/limit, etc. It’s important to us that Apollo Client doesn’t impose any requirements on your GraphQL schema to enable pagination.



Better yet, this feature can be used to implement something that has properties similar to pagination (i.e. fetching partial data for the query over time) but doesn’t just append or prepend pages of data to a list. Since the API allows you to supply a function that accumulates results of the query in an arbitrary way, you can merge the new results any way you like, deduplicate items, sort them, or anything else you need to do.



We’re especially excited that this feature is the result of an extensive collaboration with the open-source community. Together we went through&nbsp;<a href="https://github.com/apollostack/apollo-client/pull/335" target="_blank" rel="noreferrer noopener">multiple</a>&nbsp;<a href="https://github.com/apollostack/apollo-client/pull/350" target="_blank" rel="noreferrer noopener">iterations</a>&nbsp;of&nbsp;<a href="https://github.com/apollostack/apollo-client/pull/454" target="_blank" rel="noreferrer noopener">proposals</a>, implementations and review until we finally arrived to&nbsp;<a href="https://github.com/apollostack/apollo-client/pull/472" target="_blank" rel="noreferrer noopener">the solution we are shipping</a>&nbsp;with Apollo Client today. Thanks to everyone who provided their input along the way, especially&nbsp;<a href="https://medium.com/u/abc034e10a70?source=post_page-----59ff064aac61----------------------" target="_blank" rel="noreferrer noopener">Robin Ricard</a>!



<hr class="wp-block-separator"/>



If you’d like to use this feature yourself,&nbsp;<a href="http://docs.apollostack.com/apollo-client/index.html" target="_blank" rel="noreferrer noopener">try Apollo Client today</a>!

Pagination

Pagination and Infinite Scrolling in Apollo Client

Stay in our orbit