DEV Community: Abdullahi Hamisu

Intersection Observer API: A tool for optimizing Infinite Scroll

Abdullahi Hamisu — Wed, 28 May 2025 10:14:24 +0000

Background

I remember my first experience with infinite scroll on Facebook’s mobile app and how it significantly improved the user experience. For context, I have had to deal with slow internet, and the idea of having to wait for the browser to load a new page to access the next page was frustrating even for users with reliable connections.

The first resort for any developer is to set up an event handler that fires on scroll and triggers a function that makes an API call to fetch the next data as the scrollbar approaches the end of the scroll track.

This implementation works, but it's far from perfect, and this is where the Intersection Observer API shines, from infinite scroll, and lazy loading to complex scroll-based animations and storytelling —-you name it.

The Intersection Observer API

The Intersection Observer API is a browser feature that enables developers to detect when elements enter into the viewing area of a scrollable element.

Intersection is better explained in relation to a scrollable parent element, which is known as the root element.

Imagine a scrollable parent element with child elements. The child elements that are visible initially without scrolling are said to be intersecting the parent element. The other child elements, which are not initially visible, are considered intersecting only when the parent is scrolled to bring those child elements into view.

Why the Intersection Observer API?

As stated, traditional scroll animations and infinite scrolling relied on listening for the scroll event and triggering event handlers when the target element entered into view.

The downside to this working but not ideal implementation is that the browser calls the event handler function whenever the page or root element is scrolled. Even the smallest change in scroll will trigger the event handler to run. These function calls overload the browser’s memory and lead to overall poor performance.

Think of it this way. With every scroll, the browser repeatedly calls the same event handler function until eventually the target element is reached, which is usually the bottom-most element in the case of infinite scroll. You can only imagine how many of these function calls are made, and it’s no wonder why this implementation leads to performance issues.

With the Intersection Observer API, the callback function runs only once.

Scroll events vs. Intersection Observer

Here we take an evidence-based approach to compare the scroll-based implementation and the intersection observer API.

Scroll-based implementation of infinite scroll

The code below describes a page containing divs with some stylings. An event listener has been attached to the body element to execute a callback function whenever the container is scrolled.

This practical implementation may seem okay from the start, but not until you begin to scroll the page do you begin to notice just how many of those function calls are made.

From the attached image below, you can see that we’ve made a total of 32 function calls, and this is just by scrolling roughly halfway and not all the way through to the end of the page.

Now imagine if this callback function were to contain logical computations for animations or any other compute-intensive feature. With the Intersection Observer API, these excessive function calls are replaced with a single function call no matter the number of times a page is scrolled.

Advantages of Intersection Observer API over scroll-based event triggers

We’ve discussed performance as one of the main benefits offered by intersection observer implementations; however, the benefits go beyond performance benefits.

The following are some of the benefits of intersection observer API implementations over scroll-based event triggers.

Cleaner code

Much more code is written in scroll-based implementation, which may include targeting logic in the case of infinite scroll. This makes the codebase much more difficult to understand compared to Intersection Observer, where some aspects like element targeting are automatically handled, resulting in clean code.

Automatic element targeting

Intersection Observer was built to target elements when they enter into the viewport. Therefore, there is built-in logic to target elements without the need to implement complex logic, which might bloat the codebase and introduce memory and performance issues.

This automatic handling of element detection shifts the focus to other critical aspects like the callback functions as opposed to scroll-based implementations, where both element targeting and callbacks become the sole responsibility of the developer.

Productivity

Features like infinite scroll and scroll animations are easily implemented with the Intersection Observer API in a much shorter timeframe than scroll-based implementations, saving time and improving efficiency for developers.

Use cases of the Intersection Observer API

The Intersection Observer API has lots of use cases, from infinite scrolling, scroll animations, and lazy loading to not-so-common implementations like scroll-based form validation, as noticed on Discord, where scrolling to the bottom of a modal component enables a button that had been previously disabled.

Anatomy of the Intersection Observer API

The IntersectionObserver interface takes in two parameters during instantiation; these are

Options

The options parameter is a JavaScript object that determines the root element and how the target element is to be observed.

const options = {
       root: document.getElementById("body"),
       rootMargin: "0px 0px 0px 0px",
       threshold: 1.0
}

Anatomy of an options parameter

There are 3 key properties for the options property.

root

The root property accepts an Element object, which serves as the parent of the child elements to be observed.

The root element’s area will now serve as the reference area that determines whether a child element is intersecting or not.

If the root element is not specified, the browser will automatically use the body as the root element.

rootMargin

This parameter accepts a set of four values similar to the margin property in CSS.

The four values correspond to the top, right, bottom, and left margins, respectively.

A positive margin value will increase the bounding area of the root element, and a negative value will decrease or shrink the size of the bounding area.

The default value is 0px for all four directions, meaning the container stays as is.

threshold

Threshold determines the percentage level of visibility of the target element at which the callback function is executed.

The property takes either a single number ranging from 0 to 1 or an array of numbers, each number also being within the range of 0 to 1.

A threshold of 0.5 means that the callback function will be executed when 50% of the element intersects the root element, which also means half of the element is now visible in the root element.

A threshold of 1 means 100% of the element needs to be visible, at which point the callback is executed.

If an array of numbers is passed as the threshold, the callback function will run at each of the thresholds in the array.

Example: given a threshold of [0.3, 0.6, 1], the callback function will run successively each time the target element intersects its parent at 30%, 60%, and 100%.

If the threshold is not specified, the browser will use 0 as the default, and the callback function will run when the smallest part of the child element intersects its parent.

Callback

The callback parameter is the function that is executed when the target element intersects the root element at the specified threshold.

It is a normal JavaScript function that takes a single parameter, entries.

const callback = (entries) => {
       //entries
}

So, what are entries?

Entries

Entries is an array of information about all the elements observed by the intersection observer. Entries stores a collection of IntersectionObserverEntry objects, which represent information about the elements monitored for an intersection.

Below are some of the properties of the IntersectionObserverEntry object.

isIntersecting

This property tells us whether a target is intersecting its root element or not. It returns either true or false.

target

This property returns the HTMLElement object of the target that’s being observed.

Implementing the Intersection Observer API

Having discussed the necessary details, it’s time to implement the Intersection Observer.

A basic implementation of the Intersection observer has been discussed below.

Simple scroll animation

This section shows the practical implementation of the Intersection Observer API for a simple scroll animation.

Aim

A page containing 6 div elements with a class of box has been set up. The aim is to change the background color of each box and move it to the right by 20% whenever it intersects with the viewport.

The code below represents the default styling for the div elements.

Creating the options object

We want our div elements to be fully visible before we change their background color; therefore, the threshold property of the options objects will be set to 1.

We do not want to change the size of the viewport, so the rootMargin property will be set to the default value of 0px for all four sides.

Finally, we set the root property to be the body element; that way, our divs change color when the page is scrolled.

const options = {
       root: document.getElementById("body"),
       rootMargin: "0px 0px 0px 0px",
       threshold: 1.0
}

Creating the callback function

The callback function is the heart of the intersection observer, as it determines what happens when elements intersect their root element.

As stated above, we want to change the background color and move our target div by 20% whenever it intersects the root element 100%. Luckily, there are built-in functions that assess whether a target is intersecting the root element or not.

Since the callback function takes in an entries parameter, which is just an array of the elements being observed, we want to loop through each entry and check if the target is intersecting the root element by calling its isIntersecting property. If the target happens to be intersecting, then we call its target property to assess its Element object and add the styling class.

The implementation can be found below.

const callback = (entries) => {
    entries.forEach((entry) => {
        if(entry.isIntersecting){
            console.log("intersecting");
            entry.target.setAttribute("active", "active");
            console.log("target ", entry.target.classList)
        } 
        if (!entry.isIntersecting){
            entry.target.removeAttribute("active");
        }
    });
}

Putting it all together

Now that we have an options object and a callback function. All that’s left is to instantiate the IntersectionObserver interface and pass in the arguments and call.

const observer = new IntersectionObserver(callback, options);

There’s still one final piece left. To observe an element, you call the observe method of the IntersectionObserver object and pass the target element as an argument.

Since we’re watching several divs with a common class identifier, a better approach is to iterate through an array containing their objects and pass it to the observe method as an argument.

const arr = document.getElementsByClassName("box");

for(let item of arr){
    observer.observe(item);
}

Infinite Scroll

Aim

With Infinite scroll we want to load the next data whenever the the last item in the list intersects with the root element. After loading the new elements to the DOM, we ant to unobserve the previous last item on the list that served as the trigger for loading the new data, and we want to observe the last item from the recently loaded data to serve as the trigger.

<div id="root">
  <div class="box">1</div>
  <div class="box">2</div>
  <div class="box">3</div>
  <div class="box">4</div>
  <div class="box">5</div>
  <div class="box">6</div>
</div>

Implementing the options object

Since we want our list to be confined to a specified scrollable container, we want to set it as our root element and set the threshold to 1 to make sure the page trigger is fully visible before loading the next data.

const options = {
  root,
  threshold: 1.0,
}

Implementing the callback

In the callback function, we check for the trigger to intersect the root element. If that happens, we load a the next data.

To prevent loading same data multiple times, we create a loading variable and set it to false initially.

During data loading, we set the loading variable to true.

This way, we prevent loading the same dat multiple times.

const callback = (entries, observer) => {
  target = entries[0];
  if(target.isIntersecting && !loading){
    //load new data
    loading = true
    let newData;
    console.log("wait");
    setTimeout(()=>{
      newData = loadData(current);
      root.appendChild(newData);
      loading = false
      console.log("finished")
    }, 5000);
    observer.disconnect();
   current+=6;
   observer.observe(root.lastElementChild);
  }
}

Complete implementation

Below is the complete JavaScript implementation of infinite scroll with the Intersection Observer API.

let current = 6;
let loading = false;
const root= document.getElementById("root");

const options = {
  root,
  threshold: 1.0,
}

const callback = (entries, observer) => {
  target = entries[0];
  if(target.isIntersecting && !loading){
    //load new data
    loading = true
    let newData;
    console.log("wait");
    setTimeout(()=>{
      newData = loadData(current);
      root.appendChild(newData);
      loading = false
      console.log("finished")
    }, 5000);
    observer.disconnect();
   current+=6; observer.observe(root.lastElementChild);
  }
}

const loadData = (start) => {
  const fragment = document.createDocumentFragment();
  for(let i=start+1;i<=start+6;i++){
    const newElem = document.createElement("box");
    newElem.classList.add("box");
    newElem.textContent = i.toString();
    fragment.appendChild(newElem);
  }
  return fragment;
}

const observer = new IntersectionObserver(callback, options);
observer.observe(root.lastElementChild);

Pitfalls

When using the intersection observer API in frameworks like React, Vue, and Angular, it is usual for components to be re-rendered. If those components use the Intersection Observer API, it is important to unobserve all the observed elements before the component is removed from the DOM to prevent the introduction of memory leaks.

This can be accomplished by either calling the unobserving elements individually using the unobserved method or calling the disconnect method to unobserve all elements from the intersection observer in one go.

observer.disconnect();

Conclusion

This wraps up the article on Intersection Observer. Implementations like lazy loading and would have been featured here, but at the cost of making the article too long; we restrict ourselves to the basic implementation to serve as a building block.

However, links have been shared below to resources on infinite scroll with intersection observer as well as further readings on the intersection observer API.

Futher Readings

The rootMargin property

Intersection Observer Entry

Redux Middleware: How to use and create Middleware in Redux

Abdullahi Hamisu — Sun, 07 May 2023 17:59:07 +0000

Introduction

With Redux reducers being pure functions, It is impossible to run any side effect in the reducer function. Thus, tasks like fetching data from an API just wouldn't work in reducer functions. This presents a problem for developers unfamiliar with Redux. Luckily, Redux has an ace up its sleeve for running side effects and it's called a middleware.

What is a Middleware

Broadly speaking, middleware can be considered as a layer that connects two different entities. A Middelwares act as a translation layer to enable two different entities to communicate effectively, this is done by intercepting the incoming data, processing the data and sending it to the target entity. In Redux, the entities are actions and Reducers while the middleware acts as the translation layer.

However, middleware does not translate anything but rather allows us to run side effects between the time an action is dispatched and before it gets to the reducer.

The logic behind middleware is that since a Reducer function can not run side effects, middleware could act as a portal to an alternate universe where side effects can be performed based on the action that was dispatched before the actions reach a reducer.

Notable uses cases for middleware

Redux middlewares have several use cases but the following are the most notable:

Data Fetching - In JAMSTACK applications, data is usually fetched on page load, such a task is performed in Redux with the help of middleware.
Logging - This is applicable in scenarios where there's a need to capture the state before an action is dispatched.

Other notable uses cases include

Crash reporting.
Modifying actions.

Anatomy of a Middleware

To create a middleware in Redux, we simply define a function that returns 2 nested inner functions. The implementation can be found below

const myMiddleware = function(storeAPI) {
  return function(next) {
    return function(action){
      //do something
      return next(dispatch)
    }
  }
}

It is important to know what each parameter represents

The storeAPI parameter is an object with access to the dispatch() and getState() methods.
The next parameter is a function for passing the action to the next middleware in the middleware queue(to be discussed).
The action parameter represents the current action that was dispatched.

Integrating a middleware with the Store

Now that we have a middleware, it's time to integrate it with the store. Luckily, we can achieve that with the applyMiddleware function. The function takes in a middleware as an argument.

import { createStore, applyMiddleware } from "redux"

const store = createStore(reducer, applyMiddleware(middleware))

The applyMiddleware function can take as many arguments as possible

The Middleware Queue

When an action is dispatched, Redux sets up a queue of middleware for passing action much like how actions are passed between Reducers.

But Redux applications can have more than one middleware, thereby passing actions between middleware until they finally reach the reducer.

However, it is important to note that If the dispatch() method is called in a middleware, Redux restarts the pipeline process by passing the action from the first middleware in the queue until it reaches the last middleware.

Creating a Middleware

Having discussed the anatomy of middleware and the middle pipeline, we'll put our knowledge into practice by creating two middlewares for logging and fetching data from external servers respectively.

Although middlewares for the above purposes already exist, recreating one from scratch will you an idea of how the logic is structured.

Data Logging middleware

We'll create a basic middle for logging the state value before an action is dispatched and the current action as well.

The code below shows the implementation.

const logger = function(storeAPI){
  return function(next){
    return function(action){
      console.log("Current State\n", storeAPI.getState())
      console.log("Dispaching Action\n", action)
      return next(action)
    }
  }
}

The snippet below shows the Code in action.

%[https://codepen.io/Captain-Prinz/pen/ExdQjxN]

We can finally see the action being dispatched as well as the app state before the action was dispatched.

Data Fetching Middleware

We take things a little further here by creating a middleware for fetching data from external APIs.

To keep things simple, We're going to create a middleware that performs the following

Check if an action is a function.
Execute the API request function and dispatch another action with the API result as payload.

The function to be passed in the dispatch method will take the dispatch argument. That way, we can dispatch another action within the function.

The code below shows the structure of what we are trying to achieve.

const reducer = (state={data: {}}, action) => {
  if(action.type === "ADD_DATA"){
    return {data: action.payload}
  }
  return state
}

const getAPIData = async function(dispatch){
  try{
    const { data } = await axios.get("https://www.random-data-api.com/api/users/random_user/")
    dispatch({type: "ADD_DATA", payload: data});
    console.log(data)
}catch(e){
    console.log("error\n",e)
  }
}

const fetcher = function({dispatch}){
  return function(next){
    return function(action){
      if(typeof action === "function"){
        return action(dispatch) 
      }
      return next(action)
    }
  }
}

const store = createStore(userReducer, applyMiddleware(fetcher))

I would've shown a Live snippet but for some reason, Codepen seems to be messing up with the Axios request.

Anyways, We dispatch the function like a regular function and when that happens, the API result is taken to the reducer which saves it in the store.

Conclusion

We've finally seen how middlewares can be used to run side effects, especially Data Fetching. With this, we wrap up the article on Redux and focus on integration with popular UI libraries.

If there's any technology you want me to cover, please consider leaving a comment and sharing with others if you find the article useful.

Thank you

Redux for beginners

Abdullahi Hamisu — Sun, 30 Apr 2023 20:08:49 +0000

Introduction

Redux is still regarded as being a notoriously difficult library to work with by entry-level developers despite dominating the frontend world. This article aims to explain the basics of Redux.

Why developers avoid Redux

The following factors might be reasons why developers tend to avoid Redux:

Huge Boilerplate code
Steep Learning Curve

Even with the reasons mentioned above Redux is still one of the most used state management libraries among enterprises, startups and Independent developers. One such enterprise in Robinhood.

Redux Architecture

While Redux's boilerplate is one of the primary reasons why it is avoided by developers, it doe have a simple architecture; thereby simplifying the whole process of managing state in applications.

The Redux Architecture is made up of three basic components:

Store
Reducers
Action

Store

The store is essentially a container that stores the application's global state. There can only be a single store in a Redux application. Data kept in a Redux store cannot be changed. The only way to change the data already stored in a Redux store is to dispatch an action.

Under the hood, a Redux store is just a plain object containing state data that can be accessed at all levels within the application. However, the store has some special methods to control the flow of state data.

The most important methods include:

getState()
dispatch()
subscribe()

The getState() method returns the state data tree persisted in the store.

The dispatch() method is used to dispatch an action to the store to change the data stored in the application. It takes an action as an argument.

The subscribe() method allows us to run a callback function an action is dispatched. This provides a way to get the recent data in the store by calling the getState() method.

The createStore() function allows us to create a store by taking a reducer function as an argument.

import { createStore } from "redux"

const store = createStore(reducer)

Reducer

The Reducer is a function that contains the logic of how state data is saved in the store. The Reducer function simply takes the current state and the dispatched action as arguments and returns a new state based on the arguments.

The code below shows a basic implementation of a reducer function.

const initialState = {value: 0}

const myReducer = (state=initialState, action) => {
  if(action.type === "INCREMENT"){
    return {
      ...state,
      value: state.value + 1
    }
  }
}

As you can see, the initial state variable represents the current state in the application and a new state was returned based on the action that was dispatched.

However, a Redux application usually has more than one Reducer, each storing unique data for use in different parts of the application. Luckily redux provides us with the combineReducer() function.

The combineReducer() function takes an object whose values are reducing functions and returns a single reducer. This helps in projects with a large codebase where modularisation is needed for easy code maintenance.

const combination = combineReducers({
  posts: postReducer,
  counts: countReducer
})

The state in each reducer can be easily accessed by using the keys provided in the combineReducers function.

Since Reducers are pure functions, the following rules must be observed:

Reducer functions should not contain side effects like asynchronous functions.
Reducers should not modify the current state directly.
To modify the current state, reducers should make a copy of the current state and return the modification as a new state.

But One may ask, If Reducers can't run asynchronous functions, then how does one deal with data fetching in a Redux application? This is where middlewares come in.

Middlewares

A middleware is a function executed between the period an action is dispatched and before it gets to the reducer. This middleware, in turn, provides an environment to run asynchronous functions and other side effects, particularly data fetching. The resulting data from the side effects function is then passed to the Reducer to complete the data manipulation cycle.

In short, Reducers determine how the state data is changed and middleware intercept actions before they are passed to the Reducers.

Action

Actions are simply events which trigger a change in State. They sort of define a particular task in an application. For example, suppose a counter application has buttons for incrementing and decrementing a count variable, the task of incrementing and decrementing the count variable could be considered an action in redux.

In Redux, an action is a plain javascript object with two properties: type and payload.

The type property describes the action to be dispatched.
The payload property allows us to attach some data to the action object so we can access it in the Reducer to save it in the store.

Below is a simple implementation of Redux actions.

const action = {
  type: "INCREMENT"
}

const anotherAction = {
  type: "SAVE_TODO",
  payload: "Get Groceries"
}

If we consider the second action in the code above we could write a reducer function to access the payload and save it in the store. The implementation can be found below.

const initialState = {todos: []}

const anotherReducer = (state=initialState, action) => {
  if (action.type === "SAVE_TODO"){
    return {
      ...state,
      todos: [...state.todos, action.payload]
    } 
  }
}

This aspect wouldn't be complete without mentioning action creators.

Action creators are functions that return actions. Action creators allows us to create actions on the fly.

const actionCreator = (type, payload) => {
  return {
    type,
    payload
  }
}

We can now create actions easily by passing the necessary parameters to the function.

const customAction = actionCreator("DELETE_TODOS", "Buy Groceries")
// returns {type: "DELETE_TODOS", payload: "Buy Groceries"}

With the above implementation, we can pass payloads dynamically.

Stitching it together

At this moment, you should have grasped the basic concepts of Redux. We go further by building a simple counter application in Redux.

The application will have the following:

An HTML template
Two actions for incrementing and decrementing
A reducer function for the actions
A store for persisting data

We start by creating the UI template. We could decide to use the default value from the store but in this case, I'm just going to write the default value in the HTML.

<h1 id="target">0</h1>

<button id="increment">Increment</button>
<button id="decrement">Decrement</button>

We then create the Reducer function.

const countReducer = (state={value: 0}, action) => {
  if(action.type === "INCREMENT"){
    return {
      ...state,
      value: state.value+1
    }
  } else if(action.type === "DECREMENT"){
    return {
      ...state,
      value: state.value-1
    }
  } else {
    return state
  }
}

As a rule of thumb, you should always return the current state if the action doesn't match in your reducer function.

We then move on to create the store and use the subscribe() method to update the DOM when actions are dispatched.

const store = createStore(countReducer)

store.subscribe(() => {
 const { count } = store.getState()
 document.querySelector("#target").innerText = count
})

Finally, we create the actions and dispatch them when the buttons are clicked.

const increaseCount = {type: " INCREMENT"}
const decreaseCount = {type: "DECREMENT"}

document.querySelector("#increment").onclick = () => {
  store.dispatch(increaseCount)
}

document.querySelector("#decrement").onclick = () => {
  store.dispatch(decreaseCount)
}

The snippet below shows the complete implementation.

Conclusion

Save for its huge boilerplate, Redux can greatly simplify code maintainability, especially for projects with large codebases.

Other concepts will be discussed in subsequent articles.

If you find this article helpful, please leave a comment and suggestions on other web technologies.

Happy Learning!