The last topic that we’ll cover in this tutorial is pagination. You’ll implement a simple pagination approach so that users are able to view the links in smaller chunks rather than having an extremely long list of Link
elements.
Once more, you first need to prepare the React components for this new functionality. In fact, we’ll slightly adjust the current routing setup. Here’s the idea: The LinkList
component will be used for two different use cases (and routes). The first one is to display the 10 top voted links. Its second use case is to display new links in a list separated into multiple pages that the user can navigate through.
Make sure to import the Redirect
component, so you don’t get any errors.
You now added two new routes: /top
and /new/:page
. The latter reads the value for page
from the url so that this information is available inside the component that’s rendered, here that’s LinkList
.
The root route /
now redirects to the first page of the route where new posts are displayed.
Before moving on, quickly add a new navigation item to the Header
component that brings the user to the /top
route.
You also need to add quite some logic to the LinkList
component to account for the two different responsibilities it now has.
The query now accepts arguments that we’ll use to implement pagination and ordering. skip
defines the offset where the query will start. If you passed a value of e.g. 10
for this argument, it means that the first 10 items of the list will not be included in the response. first
then defines the limit, or how many elements, you want to load from that list. Say, you’re passing the 10
for skip
and 5
for first
, you’ll receive items 10 to 15 from the list. orderBy
defines how the returned list should be sorted.
But how can we pass the variables when using the <Query />
component which is fetching the data under the hood? You need to provide the arguments into the variables
prop right where you’re declaring the component.
You’re now passing first, skip, orderBy
values as variables
based on the current page (this.props.match.params.page
) which it’s used to calculate the chunk of links that you retrieve.
Also note that you’re including the ordering attribute createdAt_DESC
for the new
page to make sure the newest links are displayed first. The ordering for the /top
route will be calculated manually based on the number of votes for each link.
You also need to define the LINKS_PER_PAGE
constant and then import it into the LinkList
component.
Next, you need functionality for the user to switch between the pages. First add two button
elements to the bottom of the LinkList
component that can be used to navigate back and forth.
Before we continue, you can read some more about React Fragments - a common pattern for a component to return multiple elements without adding extra nodes to the DOM ✨
Since the setup is slightly more complicated now, you are going to calculate the list of links to be rendered in a separate method.
For the newPage
, you’ll simply return all the links returned by the query. That’s logical since here you don’t have to make any manual modifications to the list that is to be rendered. If the user loaded the component from the /top
route, you’ll sort the list according to the number of votes and return the top 10 links.
Next, you’ll implement the functionality for the Previous and Next buttons.
The implementation of these is very simple. You’re retrieving the current page from the url and implement a sanity check to make sure that it makes sense to paginate back or forth. Then you simply calculate the next page and tell the router where to navigate next. The router will then reload the component with a new page
in the url that will be used to calculate the right chunk of links to load. Run the app by typing yarn start
in a terminal and use the new buttons to paginate through your list of links!
Through the changes that we made to the FEED_QUERY
, you’ll notice that the update
functions of your mutations don’t work any more. That’s because readQuery
now also expects to get passed the same variables that we defined before.
Note:
readQuery
essentially works in the same way as thequery
method on theApolloClient
that you used to implement the search. However, instead of making a call to the server, it will simply resolve the query against the local store! If a query was fetched from the server with variables,readQuery
also needs to know the variables to make sure it can deliver the right information from the cache.
All that’s happening here is the computation of the variables depending on whether the user currently is on the /top
or /new
route.
Finally, you also need to adjust the implementation of update
when new links are created.
You have now added a simple pagination system to the app, allowing users to load links in small chunks instead of loading them all up front.