Pagination
The database can store collections of hundreds of millions of records. Therefore, returning the entire collection at each GET request is too resource-intensive. The response body will be too big, and the request will take tens of seconds or even minutes: the more data the response from the back-end contains, the longer it travels over the network.
In addition, you need to think about the users – they hardly need all the millions of records at once. Processing such a large amount of data in the response and rendering the interface will require huge resources of the device used for page viewing. According to statistics, users find the information they want on the first few screens.
Let's say our back-end, my-api.com, stores a very large collection of posts in the resource called /posts, represented by twelve items in the image.
For every GET request, the back-end will have to return the entire collection, and you will face the problems described earlier. To solve them, there is pagination – a technique in which not the entire collection is returned at the first and each subsequent GET request, but a certain part of it. Pagination is implemented on the back-end and used on the front-end by means of special request parameters.
Number of response items
The first parameter defines the number of items in the response from the back-end. For example, call it per_page. There is no standard for naming pagination parameters, so their names depend on the back-end developer.
In such GET request, the back-end will not return the entire collection of twelve items, but only the first four. If you pass a negative value or a value greater than the number of items in the collection, the back-end may respond differently – to ignore them or return the 400 (BAD REQUEST) error, depending on its implementation.
Public JSONPlaceholder API also supports pagination; the _limit parameter controls the number of items in the response. There are 100 items in the /posts collection in total. Change the value of the _limit parameter in the example and check the back-end response in the interface and in the Network tab.
Item group number
By specifying the required number of items in the response, you will always get the same result: the first per_page items of the collection, the so-called first group or "page". The second pagination parameter controls offset within the collection – the number of the group of items that you want to get. If the back-end does pagination, the default value of this parameter is one – the first group or "page" of items. Let call it page.
By changing the value of the page parameter, you tell the back-end what next group of items you want to receive, and so on until the collection runs out of items. If you set a value that is negative or exceeds the number of groups in the collection, the back-end's response will depend on its implementation.
In JSONPlaceholder API, the parameter that controls a group of items is called _page. Change its value in the example and check the back-end response in the interface and in the Network tab.
In order to know when the collection runs out of items and to display a relevant message to the user, the back-end in each response returns not only an array of items, but also metadata relating to the available number of groups ("pages"), depending on the value of the per_page parameter, or just the total number of items in the collection, in which case the number of groups should be calculated by the front-end developer. Unfortunately, JSONPlaceholder API does not have this feature.
“Load more” technique
In order to dynamically change the group number at each subsequent request, it is enough to declare one more global variable. Call it page and set the initial value to 1 – the first group of items. After each successful request, in the callback of the then() method, increase the value of page by one. When setting request parameters, use its value.
After loading the first group of items, the text on the button will change, and the button will drop under the list of posts. When the user scrolls the page and clicks it again, the request will be executed for the second group of items, which will be added to the existing markup of the list of posts. If there are no more posts to load when clicking the “Fetch posts” button, an alert will be displayed.
End-of-collection check was added to the front-end because JSONPlaceholder API does not support this feature on the back-end. In this case, it is enough to divide the total number of items in the collection by the number of items in one group. This is similar to the case where the back-end returns not the number of available pages, but the total number of items in the collection.