Build your Own Virtual Scroll - Part I
Tags: javascript, virtualscroll, webdev, tutorial
Published: 2019-08-05 05:00:58

This is a 2 part series:
- [Part I - Concept and Math](https://dev.to/adamklein/build-your-own-virtual-scroll-part-i-11ib)
- [part II - Dynamic Height and Performance](https://dev.to/adamklein/build-your-own-virtual-scroll-part-ii-3j86)

# Part I
Building your own virtual scrolling (windowing) is not as hard as it sounds. We will start by building a simple one where the height is fixed for every row, and then discuss what to do when the heights are dynamic.

Before we dive into the technical details, let's understand the basic concept behind virtual scrolling

> Important note:
> This is not a "you should build your own virtual scroll" article, merely an article explaining how to do it. I think knowing how things work even if you don't implement them yourself can be very beneficial.


# What's a Window?

In Regular scrolling, we have a scrollable container (or a viewport), and content, let's say - a list of items.

The scrollable container has a smaller height than the internal content, thus the browser displays a scroller, and displays only a portion of the content, depending on the scroller position.

You can imagine the viewport as a window, and the content is behind it. The user can only see the part that's behind the window:
![](https://thepracticaldev.s3.amazonaws.com/i/03t6jv572tqe7015387w.png)

Scrolling the container is like moving the content up or down:
![](https://thepracticaldev.s3.amazonaws.com/i/cry29ofd5mg8jaf0vth0.png)

## Virtual Scrolling

In virtual scrolling, we don't display the entire content on the screen, to reduce the amount of DOM node rendering and calculations.

We "fool" the user to think the entire content is rendered by always rendering just the part inside the window, and a bit more on the top and bottom to ensure smooth transitions.

Notice that we still need to render the content in its full height (as if all the list items were rendered), otherwise, the scroller would be of the wrong size, which leaves an empty space at the bottom and the top:
![](https://thepracticaldev.s3.amazonaws.com/i/v32a8h6v64jhg2nbl8lp.png)

As the user scrolls, we recalculate which nodes to add or remove from the screen:
![loading gif...](https://thepracticaldev.s3.amazonaws.com/i/ngc09kno8zfltxloo7nj.gif)

You can also imagine this as if walking on a bridge that's currently being built right in front of you and destroyed right behind you. From your perspective, it would feel like walking on a complete bridge, and you wouldn't know the difference.


# Let's Do Some Simple Math
For the simple solution, we will assume we know the list length and that the height of each row is fixed.

The solution is to:
1) Render the entire content as an empty container
2) Render the currently visible nodes
3) Shift them down to where they should be.

Let's break down the math of that:

Our input is:
- viewport height
- total number of items
- row height (fixed for now)
- current scrollTop of viewport

Here are the calculations we make in each step:
## Render the Entire Content
As mentioned earlier, we need the content to be rendered at its full height, so that the scrollbar's height is accurate. This is just **number of nodes** times **row height**.
![](https://thepracticaldev.s3.amazonaws.com/i/ybsk0ktmx1381z669exa.png)

## Render the Currently Visible Nodes 
Now that we have the entire container height, we need to render only the visible nodes, according to the current scroll position.  
The first node is derived from the **viewport's scrollTop**, divided by **row height**. The only exception is that we have some padding of nodes (configurable) to allow for smooth scrolling:
![](https://thepracticaldev.s3.amazonaws.com/i/jfhliy4gc6f81unf4oz8.png)

The **total number of visible nodes** is derived from the **viewport's height**, divided by **row height**, and we add the padding as well:
![](https://thepracticaldev.s3.amazonaws.com/i/wzq4mj1uu6aosyum12r0.png)

## Shift the Nodes Down
When we render the visible nodes inside the container, they render at the top of the container. What we need to do now is shift them down to their correct position, and leave an empty space.  
To shift the nodes down, it's best to use **transform: translateY** to offset the first node, as it will run on the GPU. This will ensure faster repaints and better performance than, for example, absolute positioning. The **offsetY** is just the **start node** times the **row height**
![](https://thepracticaldev.s3.amazonaws.com/i/2gzbk726dfnx9el42lsj.png)

# Example Code
Since the implementation may vary depending on the framework, I've written a psuedo implementation using a plain function that returns an HTML string:
{% gist https://gist.github.com/adamkleingit/b40c0d3e3b530b2d7160dd0b5dc270f2 %}

And here is a working example using React:
{% codesandbox 214p1911yn %}

# Performance & Dynamic Heights
So far we've handled a simple case where all rows have the same height. This makes calculations into nice simple formulas. But what if we are given a function to calculate the height of each row?

To answer this question, and further discuss performance issues, you can view [**part II**](https://dev.to/adamklein/build-your-own-virtual-scroll-part-ii-3j86), in which I'll show how to accomplish that using binary search.