A common theme in web development, and the crux of the so-called "Web 2.0" is scrolling through dynamic lists of content. Tildes is such an example: you can scroll through about 50 topics on the...
A common theme in web development, and the crux of the so-called "Web 2.0" is scrolling through dynamic lists of content. Tildes is such an example: you can scroll through about 50 topics on the front page before you reach a "next" button if you want to keep looking.
There's a certain beauty in the simplicity of the next/previous page. When done right it's fast, it's easy, and fits neatly into a server-side rendered model. However, it does cause that small bit of friction where you need to hit the next button to go forward -- taking you out of the "flow", so-to-speak. It's slick, but it could be slicker. Perhaps more importantly, it's an interesting problem to solve.
A step up from the next/previous button is to load the next page of content when you reach the end of the list, inserting it below. If the load is pretty fast, this will hardly interrupt your flow at all! The ever-so-popular reddit enhancement suite does precisely that for reddit: instead of a next button, when you reach the bottom, the next page of items simply plops into place. If the loading isn't fast enough, perhaps instead of loading when they reach the last item, you might choose to load when they hit the fifth from last item, etc.
To try to keep this post more concrete, and more helpful, here's how this type of pagination would work in practice, in typescript and using the Intersection Observer API but otherwise framework agnostic:
/**
* Allows the user to scroll forever through the given list by calling the given loadMore()
* function whenever the bottom element (by default) becomes visible. This assumes that
* loadMore is the only thing that modifies the list, and that the list is done being modified
* once the promise returned from loadMore resolves
*
* @param list The element which contains the individual items
* @param loadMore A function which can be called to insert more items into the list. Can return
* a rejected promise to indicate that there are no more items to load
* @param triggerLoadAt The index of the child in the list which triggers the load. Negative numbers
* are interpreted as offsets from the end of the list.
*/
function handlePagination(list: Element, loadMore: () => Promise<void>, triggerLoadAt: number = -1) {
manageIntersection();
return;
function handleIntersection(ele: Element, handler: () => void): () => void {
let active = true;
const observer = new IntersectionObserver((entries) => {
if (active && entries[0].isIntersecting) {
handler()
}
}, { root: null, threshold: 0.5 });
observer.observe(ele);
return () => {
if (active) {
active = false;
observer.disconnect();
}
}
}
function manageIntersection() {
const index = triggerLoadAt < 0 ? list.children.length + triggerLoadAt : triggerLoadAt;
if (index < 0 || index >= list.children.length) {
throw new Error(`index=${index} is not valid for a list of ${list.children.length} items`);
}
const child = list.children[index];
const removeIntersectionHandler = handleIntersection(child, () => {
removeIntersectionHandler();
loadMore().then(() => {
manageIntersection();
}).catch((e) => {});
});
}
}
If you're sane, this probably suffices for you. However, there is still one problem: as you scroll,
the number of elements on the DOM get longer and longer. This means they necessarily take up
some amount of memory, and browsers probably have to do some amount of work to keep
track of them. Thus, in theory, if you were to scroll long enough, the page would get slower and
slower! How long "long enough" is would depend mostly on how complicated each item is: if each one
is a unique 20k element svg, it'll get slow pretty quickly.
The trick to avoid this, and to get a constant overhead, is that when adding new items below, remove the same number of items above! Of course, if the user scrolls back up they'll be expecting those items to be there, but no worries, the handlePagination from before works just as well for loading items before the first item.
However, this simple change is where a key problem arises: inserting elements below doesn't cause any layout shift, but inserting an item above ought to--right?
The answer is: it depends on the browser! Back in 2017 chrome realized that it's often convenient to be able to insert items into the dom above the viewport, and implemented scroll anchoring, which basically ensures that if you insert an item 50px tall above the viewport, then scroll 50px down so that there's no visual layout shift. Firefox followed suite in 2019, and edge got support in 2020. But alas, safari both on mac and ios does not support scroll anchoring (though they expressed interest in it since 2017)
Now, there's two responses to this:
- Surely Safari support is coming soon, they've posted on that bug as recently as April! Just use simpler pagination for now
- Pshhhh, just implement scroll anchoring ourself!
Of course, I've gone and done #2, and it almost perfectly works. Here's the idea:
- Right before
loadMore, find the first item in the list which is inside the viewport. This is the item whose position we don't want to move. Use getBoundingClientRect to find it's top position.
- Perform the DOM manipulation as desired
- Use getBoundingClientRect again to find the new top of that item.
- Insert (or remove) the appropriate amount of blank space at the top of the list to offset the change in client rect (note that if there's scroll anchoring support in the browser this should always be zero, which means this effectively works as progressive enhancement)
Now, the function to do this is a tad too long for this post. I implemented it in React, however, and combined it with some stronger preloading object (we don't need all the items we've fetched from the API on the DOM, so we can use before, onTheDom, after lists to avoid getting a bunch of api requests just from scrolling down and up within the same small number of items).
What's interesting is that it still works perfectly on chrome even with scroll-anchoring disabled (via overflow-anchor: none), but on Safari there is still, sometimes, 1 frame where it renders the wrong scroll position before immediately adjusting. Because I implemented it in react, however, my current hypothesis is I have a mistake somewhere which causes the javascript to yield to the renderer before all the manipulations are done, and it only shows up on Safari because of the generally higher framerates there
If it's interesting to people, I could extract the infinite list component outside of this project: I certainly like it, and in my case I do expect people to want to quickly scroll through hundreds to thousands of items, so the lighter DOM feels worth it (though perhaps it wouldn't if I had known, when starting, how painful getting it to work on Safari would be!).
What do you think of this type of "true" infinite scrolling for web? Good thing, neutral thing, bad thing? Would you use it, if the component were available? Would you remove it, if you saw someone doing this? Are there other questions about how this was accomplished? Is this an appropriate post for Tildes?