Introduction

When developing applications, we often need to deal with large data-sets. Imagine a scenario where we have one million records in the database, and we require to show it on a web page.

We generally want to avoid sending all the data at once. The reasons for that are 1) We want a faster initial page load. 2) We don’t want to bloat the user’s machine memory.

Instead, server-side paging is used, where the server sends just a single page at a time.

In addition to that, we also want to cache pages that already have been fetched, to spare the need for an additional request. To save you the hassle and help you manage this whole thing, we created the PaginatorPlugin.

The Paginator Plugin

The Paginator API provides two useful features:

Caching of pages which have already been fetched. Pagination functionally, which gives you all the things you need to manage pagination in the application.

Here is the plugin in action:

Let’s learn how to use it.

Create the Scaffold

We need to maintain a collection of contacts, so we’ll use an EntityStore . You can think of an entity store as a table in a database, where each table represents a flat collection of entities.

Let’s create a contacts table, i.e. an EntityStore managing a Contact object:

We created the basic building blocks of Akita. Now, let’s create the ContactsService which is responsible for fetching the data:

The getContact function is a mock implementation which returns the required server data with a one-second delay.

Basic Pagination:

First, we need to create a new provider for our contacts:

You should already be familiar with the above code. This is the regular process of creating a factory provider in Angular.

We are creating a new PaginatorPlugin() , passing the query we want to use in our pagination.

Calling withControls() will give us an array of pages so we ngFor on them and withRange() which will give us the from and to values to display to the user.

Now, we can use it in our component:

Paginator exposes a pageChanges observable (which fires the first page immediately). When this observable emits, we call the paginatorRef getPage() method, passing the HTTP request we want to initialize when the page doesn’t exist in the cache

Paginator expects to get the following fields as part of the response from the server (in our case, the request service method):

In addition to that, Paginator also exposes all the data that you need to display as well as methods for controlling the page from the UI, for example:

isLoading$ , isFirst , isLast , prevPage() , nextPage() , setPage() , isPageActive() , pageControls , etc.

Let’s see how can we use it in the component’s template:

That’s all you need in order to get fully working pagination including caching.

Router Integration

There are times where we want to persist the current page in the URL address, for example: http://app.com/contact?page=3 .

Here is an example of how can we implement it with the plugin:

Each time the page query parameter changes, we notify the plugin about the current page.

Advanced Pagination

There are times where we want to give our users the ability to filter the data, sort it, or change the number of entries per page. The vital step here is that when we change a filter, sort, etc. We want to invalidate the cache, because it may alter the server response.

For example, let’s add a sortBy filter:

When the sortBy value changes, we need to invalidate the cache, so the Paginator will know that it needs to re-fetch the data from the server.

Pagination Metadata

Sometimes you want to save the current filters, so if the user navigates from the current route and comes back you want the filter values to persist. Paginator exposes a metadata property where you can set these values.

For example:

Thank you for reading! If you liked the article hit the 👏🏻 button and share it 🎉