If you have any experience developing web interfaces, you have most likely encountered pagination. When there is too much data to present at once, pagination allows the user to explore the data one batch at a time. A common alternative to pagination is scrolling.
At first glance, paging and scrolling are interchangeable ways to present data. Both display the same information to the user in the same order.
However, consider how different the experience would be if popular user interfaces had been implemented using pagination instead. Endlessly paging through Twitter or Instagram. Missing a slack message because you skipped to the last page. The shame of clicking page 14 while surfing Netflix. Clicking page, after page, after page, quickly becomes a tedious and error-prone experience for users.
What is Infinite Scrolling?
Infinite scrolling is a technique that eliminates the need for pagination by loading content continuously as the user scrolls down the web page, creating a seamless experience. One way to do this is by using a function that listens for all scroll events on the page:
|
window.addEventListener('scroll', function(e) {
// calculate how far the user has scrolled
// if the user has reached the end of the list
// then fetch more data and append
})
|
As we’ll see, there is another way we can detect when we need to load more data: the Intersection Observer API.
Intersection Observer API
Instead of listening to browser events to manually perform calculations, we can implement the same behavior in a more efficient, maintainable way, using Intersection Observer API.
“The Intersection Observer API provides a way to synchronously observe changes in the intersection of a target element with an ancestor element or with a top-level document’s viewport.” – Mozilla
In the example below, we step through a basic example implementing a callback using Intersection Observer API.
First, assume we have a div element, called root, that contains some number of loaded results. Next, we define a callback that will be called each time an element intersects with root. Then, we instantiate a new IntersectionObserver object, observer, that receives both the callback and root. Finally, we use observer to call the function observe on whichever DOM elements we want to trigger the callback.
|
const root = theDivContainer;
let last = theLastElement;
const callback = entries => {
entries.forEach(entry => {
if (entry.target.id === last.id) {
handleFetch();
}
});
}
// callback runs every time an observed element intersects with container
let observer = new IntersectionObserver(callback, { root });
observer.observe(last);
|
A Few Key Points
Now that the intention of our code is clear, there are a few points to address. In this example, I included a redundant check: entry.target.id === last.id. This would be useful in the case where the user can load by scrolling in either direction. Since we are only observing one sentinel, the check will always return true, but we could handle data differently depending on the scroll direction.
Additionally, it should be made clear is what intersecting means. Intersection Observer allows the programmer to control what defines an intersection by setting rootMargin and threshold when instantiating the IntersectionObserver. Threshold controls how much of the entry must pass the viewport before the callback is called. For excellent documentation please refer to Mozilla.
“The biggest improvement of this API over the use of an event listener is that the computation of both the target elements and the actual observing behavior of the intersecting elements are not run on the main JS thread, thus freeing us from potential noise and blocking nature of the language.” – Phong Lam (Medium)
Room for Improvement
There are further improvements that we can add to our code depending on the use case. Consider what happens when the user has to scroll through many entries before they navigate away. Once the user reaches the end of the results, more results are added but never removed, which might result in poor page performance. We can use the same pattern above to observe when elements leave the viewport and are safe to detach from the DOM. DOM recycling uses this idea to keep a constant number of elements to display results and cycles them as the user scrolls.
Caching is another consideration for both pagination and scrolling. When data is removed from the screen, it should remain in memory. Otherwise, your application might fetch the same information multiple times as the user scrolls back and forth.
Disadvantages of Scrolling
While it is always fun to try out a new tool, it’s important to use the right tool for the right job. Just as scrolling has its advantages, there are many cases where pagination is preferable.
Since pagination has regular groups, it could be helpful when the number of results is meaningful. If there is a common user action to skip to the end of the list, the user would surely prefer to simply click a button than scroll to the end. Pagination can also be used as a UX tool to dissuade the user from scrolling through progressively worse results.
Going Forward
Hopefully, it is now clear that from the user perspective, pagination and scrolling are not interchangeable. The implementation you choose might heavily impact how users interact with your site. Take the time to reflect on the user experience and choose the right tool for the job!
About OrderMyGear
OrderMyGear is an industry-leading sales tool, empowering dealers, distributors, decorators, and brands to create custom online pop-up stores to sell branded products and apparel. Since 2008, OMG has been on a mission to simplify the process of selling customized merchandise to groups and improve the ordering experience. With easy-to-use tools, comprehensive reporting, and unmatched support, the OMG platform powers online stores for over 3,000 clients generating more than $1 billion in online sales. Learn more at www.ordermygear.com.
Media Contact: Hayley Bell | hayley@ordermygear.com | 214-396-2110
