When pagination is enabled, the data is displayed in pages that can be browsed using the built in pagination selector.
If you wanted server based pagination, you could look at the external pagination tutorial or consider using infinite scroll, which also retrieves data in pages from the server.
Grid with native pagination controls
When pagination is enabled, the data is displayed in pages that can be browsed using the built in pagination selector.
For external pagination, implement the gridApi.pagination.on.paginationChanged callback
function. The callback
may contain code to update any pagination state variables your application may utilize, e.g. variables
containing
the pageNumber and pageSize. The REST call used to fetch the data from the
server should be called from within
this callback. The URL of the call should contain query parameters that will allow the server-side code
to have
sufficient information to be able to retrieve the specific subset of data that the client requires from
the
entire set.
It should also update the $scope.gridOptions.totalItems variable with the total count of
rows that exist (but
were not all fetched in the REST call mentioned above since they exist in other pages of data).
This will allow ui-grid to calculate the correct number of pages on the client-side.
Current page: {{ gridApi2.pagination.getPage() }} of {{ gridApi2.pagination.getTotalPages() }}
The infinite scroll feature allows the user to lazy load their data to gridOptions.data.
Documentation for the infiniteScroll feature is provided in the api documentation, in particular:
Once you reach the top (or bottom) of your real data set, you can notify that no more pages exist
up (or down), and infinite scroll will stop triggering events in that direction. You can also
optionally tell us up-front that there are no more pages up through infiniteScrollUp = true
or down through
infiniteScrollDown = true, and we will never trigger
pages in that direction. By default we assume you have pages down but not up.
You can specify the number of rows from the end of the dataset at which the infinite scroll will trigger
a request for
more data infiniteScrollRowsFromEnd = 20. By default we trigger when you are 20 rows away
from the end of
the grid (in either direction).
We will raise a needMoreData or needMoreDataTop event, which you must listen to
and respond to if
you have told us that you have more data available. Once you have retrieved the data and added it to
your
data array (at the top if the event was needMoreDataTop), you need to call
dataLoaded to tell us
that you have loaded your data. Optionally, you can tell us that there is no more data, and we won't
trigger
further requests for more data in that direction.
When you have loaded your data we will attempt to adjust the grid scroll to give the appearance of
continuous
scrolling. We basically assume that your user will have reached the end of the scroll (upwards or
downwards)
by the time the data comes back, and scroll the user to the beginning of the newly added data to reflect
that.
In some circumstances this can give "jumpy" scrolling, particularly if you have set your rowsFromEnd to
quite a high
value so that you're prefetching the data - if the user is scrolling slowly they might be 50 rows from
the end, and
when we process the dataLoaded we suddenly move them to what used to be the end. To avoid this, you can
explicitly
save the scroll position before you add data to your data array, through calling saveScrollPercentage,
and the
dataLoaded call will then take that position into account, and attempt to adjust the scroll
so that the same
rows are showing once the grid has ingested the data you have added.
We suppress the normal grid behaviour of propagating the scroll to the parent container when you reach the end if infinite scroll is enabled and if there is still data in that direction - so if there are pages upwards then scrolling to the top will get those pages rather than hitting the top and then scrolling your whole page upwards.
If you are using external sorting or external filtering you may
reload your data whenever scroll or filter events occur. In this situation you'll want to call resetScroll
to tell the
grid not to try to preserve the previous scroll position. You may also use this call when you've
otherwise reset the data
in the grid. You must also tell us whether you allow scrollUp or scrollDown from this position as part
of the call.
You may sometimes remove data, for example if you're keeping 10 pages of data in memory, and you start
discarding data
from the top as you add data to the bottom. You can use the dataRemovedTop and dataRemovedBottom
to tell
us that you've discarded data, and we'll aim to set the scroll back to where it was before you removed
that data.