Building custom pagination component with Angular

Pagination is undoubtedly one of the most popular approaches to dozed content representation. And it’s absolutely fine to use some out-of-the-box solutions for it if your application uses some library like NgBootstrap or Material UI all round and the designs and functionality they provide is satisfactory to you.
But once you bump into the need of re-styling or customisation of it you usually may choose the way of creating a wrapping component which uses this out-of-the-box component inside and re-define its behaviour or styles by breaking original component encapsulation.
This is a legit approach of course if there are few changes to make. But when you start modifying it over and over trying to satisfy some special customer needs there may be a point when you say: “Come on! It would be easier and faster to create it from scratch than to do all these customisations!”
And you will be absolutely right here! Let’s explore together the way how to implement it in your Angular app.

Impatient readers can find the whole project here. The rest are welcome to follow with me step by step.

I like to think about pagination as about select control: we have the list of options (pages) and select one of them. And this is the reason to implement it as a form control. And speaking in terms of Angular it means that we want to implement ControlValueAccessor interface. There is an official documentation and a lot of other instructions and descriptions how to implement it. So, we’re not going to dwell on it and only will deal with pagination specific of it.

Of course you may say that we could make this component without implementing ControlValueAccessor interface just using @Output property for handling page change events. This point of view is absolutely reasonable and furthermore we’ll have this version of our component here at first as well. But the benefit of implementing ControlValueAccessor is that it gives us more flexibility: we can use or pagination component either as a template form with one- or two-way data binding ([(ngModel)] or [ngModel]+ (ngModelChange)) or as a reactive form control ([formControl]).

The reactive approach can be very handy when our pagination is supposed to be used in combination with other form controls. For example, we may have a table component which offers user a possibility to sort and filter data by columns, use pagination and table lookup. In this case we can use RxJS combineLatest method to subscribe and listen to the changes of all these controls only once:

As we you can see above with this approach we have to pipe startWith to each control, otherwise our subscription won’t start until each control emits at leas one value. In this example we use the initial form values to start with.

Another advantage of reactive approach is the possibility to use debounceTime to particular controls which allows us to avoid triggering requests on each key stroke in search input or on each click on pagination Previous / Next button.

So, let’s finally start with pagination itself!

At the first step for the visualising purpose we create a simple array of 100 elements which we’ll paginate later:

As a rule the backend sends us a paginated response, which have at least 2 properties:

items — array of items for the particular (requested) page

total — how many matching items they have in the whole.

We’re going to follow this structure in our example even though we don’t have any backend in this example. We’ll just be slicing needed range of the initial array imitating backend responses.

On the second step we create a simple pagination component which would allow us to navigate to the first, previous, next, last and particular page from the visible range with no interactions with parent component.

I’m saying visible range because we may have our content split into dozens or hundreds of pages, and we definitely don’t want to show all of them to the user. So we provide visibleRangeLength property to limit the visible pages count.

The only tricky part here I guess is updateVisiblePages method. The main points of it are the following:

we always want to have visible as many pages as we set in visibleRangeLength property
if visibleRangeLength turns out to be bigger than totalPages count (and this is absolutely possible as we never know how many pages the backend has for us, especially if we request filtered results) we want to display totalPages count
the selected page should be in the middle of the visible range if possible

Now this component is already functional but it can’t interact with external environment. To turn our component into useable configurable solution we need to:

convert value, totalPages, visibleRangeLength into component inputs
to add component output valueChange and extend selectPage method with the line this.valueChange.emit(this.value)

Though we can refactor it a little bit. As we have said previously we usually don’t get totalPages value from the backend, but we do get total items quantity and then we calculate the totalPages on our side depending on the page size. So, instead of having this logic in the AppComponent let’s put it in the PaginationComponent:

convert totalPages back into the regular public property
provide input properties total (for the total items count) and pageSize

add re-calculation of the totalPages value each time our total or pageSize change

After finishing it our component looks like this:

Now we can apply the pagination to our list of items:

On the third step I want to make our component responsible not only for the page but also for the page size selection. So we’ll add the select element to our pagination template and extend and refactor the component logic a bit more.

Obviously, our component should emit page size change event outside. But the business logic may be different here depending on the customer preferences. One may want the page content not to be updated on page size change and only request new data set on page number change. Another may have different thoughts about it.

I personally think that the most transparent way to handle it would be to request the new range of data on the page size change reseting the selected page to 1 in the same time. And this is the approach we’re going to implement further.

At first we’ll extend value interface so that it includes two properties page and pageSize. This will also need to do some refactoring in the existing PaginationComponent code (like replacing value with value.page etc.).

Then we’ll add the following changes:

And finally let’s turn our component into the ControlValueAccessor. For this we only need to remove everything related to the output property valueChange and add the following:

And now we can use the pagination as a form control:

Thank you for reading it and for your feedbacks!