Angular Material Pagination Datasource

Reusing pagination logic with dynamic data filtering and sorting

Nils Mehlhorn
Dec 24, 2019 · 8 min read

In the course of this article we’re developing a reactive datasource for the Angular Material library that’ll be reusable for many different paginated endpoints allowing you to configure search and sorting inputs on a per-instance basis. The final result is available on StackBlitz.

Although there is a bunch of stuff you can do with JavaScript, on many occasions we’re using it to fetch and display some data. In Angular, the fetching part is mostly done via HTTP while the displaying part can be performed by a variety of different user-interface components. This could be a table or a list or a tree-like structure or whatever else you might require.

Angular Material offers a couple components that could be used here — such as the table component. The creators even anticipated the need to disconnect data retrieval from data display and are therefore providing us with the concept of a DataSource.

For most real-world applications, providing the table a DataSource instance will be the best way to manage data. The DataSource is meant to serve a place to encapsulate any sorting, filtering, pagination, and data retrieval logic specific to the application. — Angular Material Documentation

Often times the amount of data we’d like to display is too big to be fetched in one batch. You can get around this by slicing your data and delivering it through pagination. Users will then be able to navigate from page to page smoothly. This is something we’ll probably need for many different views that display data - it makes sense to encapsulate this behaviour so we don’t have to write it over and over again.

Pagination and Sorting Datasource

Let’s have a look at a datasource implementation enabling you to sort data and fetch consecutive pages. First, we’ll simplify the Material datasource a bit:

Usually, the methods connect() and disconnect() would accept a CollectionViewer, however, it seems ill-advised to have the component displaying the data also decide which part of the data it's displaying. The official datasource for the Material table is ignoring the parameter as well.

Next we’ll define some reusable types for paginated data in a separate file called page.ts.

The generic parameter T always refers to the type of data we're dealing with - later on in our example it's User.

The Sort<T> type defines a sorting to be applied (aka. send to the server) to the data. This sorting could be created through the headers of a Material table or via selection.

A PageRequest<T> is what we'll eventually pass to a service which in turn will kick off a corresponding HTTP request. This service will then respond with a Page<T> containing the requested data.

A PaginatedEndpoint<T> is a function accepting a PageRequest<T> and returning an RxJS stream aka. observable containing a corresponding Page<T>.

Now we can put these types to use by implementing our paginated datasource as follows:

Let’s go through this step-by-step starting at the constructor. It accepts three parameters:

  • a paginated endpoint which we’ll use to fetch pages
  • an initial sorting to start with
  • an optional size for the pages to fetch, defaulting to 20 items per page

We initialize the instance property sort with a RxJS subject. By using a subject we can have the sorting change over time based on calls to the class method sortBy(sort: Sort<T>) which just provides our subject with the next value. Another subject pageNumber is also initialized during construction allowing us to tell our datasource to fetch different pages through the method fetch(page: number).

Our datasource will expose a stream of pages through the property page$. We construct this observable stream based on changes to the sorting. The RxJS operator startWith() allows us to easily provide a starting value for the sorting.

Then, anytime the sorting changes we’ll switch over to the stream of page numbers by leveraging the switchMap() operator. Now, as long as the sorting doesn't change, we'll just be looking at page numbers starting with the first page of any sorting - again using startWith().

When the datasource is supposed to fetch a different page - triggered by a call to fetch(page: number) - we'll query the paginated endpoint with the required parameters. Eventually this observable now provides data pages to possibly multiple consuming components. Therefore you might use share() to synchronize those subscriptions.

Finally, inside connect() we just provide a stream of lists of items by mapping any page to its contents using the pluck() operator. This method will eventually be called by the Material table or any other component compatible with the DataSource interface. You might be wondering why we don’t map our pages directly to just their contents - that’s because we need other page properties like size and number which can then be used by a MatPaginator.

The disconnect() method won't have to do anything here - our datasource will close automatically when all consuming components unsubscribe.

Using the Datasource in a Component

Inside a component that is dealing with specific data we can now utilise our datasource with the Material table. We do this by creating a new instance and passing a function that’ll forward page requests to a corresponding service. We also pass a default sorting.

The UserService will be responsible for converting the PageRequest<User> to a proper HTTP request that is in line with your server API inside the page() method.

Again, in order to now change the sorting you can call data.sortBy(sort) once the user selects a new sorting.

In your template you’ll pass the datasource to the Material table. You’ll also define a MatPaginator allowing the user to switch pages. The paginator can also easily consume the stream of pages from our datasource through the AsyncPipe and call upon data.fetch(page: number) to get a different page.

Adding Query Parameters

When there’s a lot of data you probably want to assist your users in finding what they’re looking for. You might provide a text-based search or structured inputs for filtering the data by a certain property. These query parameters will differ based on the data you’re querying. To compensate for this we’ll adapt our datasource to work with a generic set of query parameters.

First we’ll add a generic parameter Q to the datasource's type representing a query model for some data, ending up with the type PaginatedDataSource<T, Q>.

We’ll then add a constructor parameter for an initial query and create a subject property with this.query = new BehaviourSubject<Q>(initalQuery). This type of subject allows us to access its last value. We use this characteristic to enable partial updates to our query through an instance method:

This method is accepting a partial representation of our query model. We combine this new query with the last one by accessing the BehaviorSubject<Q> and merging both queries via the spread operator. This way old query properties won't be overridden when only one parameter is updated.

Then, instead of just basing our observable stream of pages on the sort subject, we’ll combine both changes to sort and query by using the RxJS operator combineLatest(). Both parameter streams are started off with their initial values - sort through startWith(), query through the constructor parameter of BehaviorSubject.

Subsequently we’ll also pass the query to the pagination endpoint. In order to do this we need to adapt its type like follows:

Now we can update our component to provide some query inputs. First adapt the initialization of PaginatedDataSource<T, Q> with a type for a specific query like UserQuery. Then provide a paginated endpoint that forwards page request and query to UserService. And lastly pass an initial query.

In our example we’ll allow users to be searched through text-based input and a date selection for a user’s registration date:

Inside the template we can simply forward input values to the datasource by calling data.queryBy() with a partial query model containing the query parameter:

Now anytime you change the inputs, the displayed page will update accordingly - provided you properly forwarded the query parameters to your servers and handle them there correctly.

Loading Indication

If you like to indicate to the user that you’re fetching a page, you can extend the PaginatedDataSource<T, Q> with a corresponding observable property based on a private subject:

Then you can either manually update the subject’s value before and after calling the PaginatedEndpoint<T, Q> or rather use the operator indicate(indicator: Subject<boolean>) I've introduced in my article about loading indication in Angular. Just attach it to the observable returned by the paginated endpoint and you're good:

You can then display a loading indicator like this:

Wrapping Up

Through clever behavior parameterization we can reuse a bunch of logic and thus are able to write powerful yet configurable components for displaying any kind of data. Our extension of the Material datasource allows us to perform pagination, sorting and filtering of remote data in just a couple of lines.

Here’s the full example on StackBlitz. I’ve also included a functional version of the datasource omitting the need for classes.

Angular In Depth

The place where advanced Angular concepts are explained

Thanks to Tim Deschryver

Nils Mehlhorn

Written by

freelance software engineer, founder, blogger |

Angular In Depth

The place where advanced Angular concepts are explained

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade