Which is Better React Scroll and Intersection Libraries?
react-intersection-observer vs react-scroll vs react-waypoint vs react-scrollspy vs react-in-viewport
1 Year
react-intersection-observerreact-scrollreact-waypointreact-scrollspyreact-in-viewportSimilar Packages:
What's React Scroll and Intersection Libraries?

These libraries are designed to enhance user experience in web applications by providing functionalities related to element visibility and scrolling behaviors. They allow developers to create dynamic and interactive interfaces that respond to user scrolling, making it easier to implement features like lazy loading, animations, and navigation highlights based on the user's viewport and scroll position.

NPM Package Downloads Trend
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
react-intersection-observer1,772,4035,045129 kB1a month agoMIT
react-scroll428,2614,357134 kB230a year agoMIT
react-waypoint220,8934,07960.7 kB61-MIT
react-scrollspy44,882427-844 years agoMIT
react-in-viewport32,033350110 kB3a month agoMIT
Feature Comparison: react-intersection-observer vs react-scroll vs react-waypoint vs react-scrollspy vs react-in-viewport

Visibility Detection

  • react-intersection-observer: react-intersection-observer utilizes the Intersection Observer API to efficiently monitor the visibility of multiple elements. This library is optimized for performance and can handle complex scenarios, such as lazy loading images or triggering animations when elements come into view, without the need for manual scroll event listeners.
  • react-scroll: react-scroll does not focus on visibility detection but rather on managing scroll behavior within a page. It allows you to create smooth scrolling effects and navigate between sections seamlessly, enhancing the overall user experience during scrolling actions.
  • react-waypoint: react-waypoint allows you to define waypoints in your application that trigger actions when scrolled into view. This can include loading additional content, triggering animations, or changing styles, making it a flexible tool for scroll-based interactions.
  • react-scrollspy: react-scrollspy tracks the scroll position of the page and highlights the corresponding navigation links based on the current section in view. This feature improves navigation usability, especially in long single-page applications, by providing visual feedback to users as they scroll.
  • react-in-viewport: react-in-viewport provides a simple way to detect when an element enters or exits the viewport. It uses a higher-order component to wrap your target elements, allowing you to easily manage visibility states and trigger actions based on whether the element is visible or not.

Performance

  • react-intersection-observer: react-intersection-observer is highly performant as it leverages the native Intersection Observer API, which is designed to handle visibility checks efficiently without causing layout thrashing or excessive reflows, making it ideal for applications with many elements to observe.
  • react-scroll: react-scroll is optimized for smooth scrolling and provides a good user experience, but it may not handle performance as well when many scroll events are triggered simultaneously. It is best for applications where scroll navigation is a primary feature.
  • react-waypoint: react-waypoint is designed to be lightweight and efficient, allowing you to trigger actions based on scroll position without significant performance overhead. It is suitable for applications that require dynamic interactions based on scrolling.
  • react-scrollspy: react-scrollspy is efficient in tracking scroll positions and updating navigation links, but it is dependent on the overall performance of the scroll event handling in the application. It works best in conjunction with other performance optimizations in the app.
  • react-in-viewport: react-in-viewport is lightweight and easy to implement, but it may not be as performant as other libraries when dealing with many elements due to its reliance on manual visibility checks. It is best suited for simpler applications where performance is not a critical concern.

Ease of Use

  • react-intersection-observer: react-intersection-observer has a slightly steeper learning curve due to its reliance on the Intersection Observer API, but it provides a powerful and flexible solution once understood. It is suitable for developers who need advanced visibility management features.
  • react-scroll: react-scroll is straightforward to implement for creating smooth scroll effects and navigation. Its API is intuitive, making it easy for developers to get started with scroll-based navigation without much overhead.
  • react-waypoint: react-waypoint is also easy to use, with a clean API that allows developers to define waypoints and trigger actions with minimal code. It is suitable for developers looking to add scroll-triggered events quickly.
  • react-scrollspy: react-scrollspy is easy to integrate into existing navigation systems, providing a simple way to enhance user experience with minimal configuration. Its API is user-friendly, making it accessible for developers of all skill levels.
  • react-in-viewport: react-in-viewport is very easy to use, with a simple API that allows developers to wrap components and manage visibility states with minimal setup. It is ideal for developers looking for quick implementation without extensive configuration.

Use Cases

  • react-intersection-observer: react-intersection-observer is perfect for complex applications that require monitoring multiple elements' visibility, such as infinite scrolling lists or triggering animations for various components as they enter the viewport.
  • react-scroll: react-scroll is ideal for single-page applications where smooth scrolling navigation is essential. It is commonly used for creating landing pages or documentation sites that require easy navigation between sections.
  • react-waypoint: react-waypoint is versatile and can be used in various scenarios, such as triggering animations, loading content, or changing styles based on scroll position. It is suitable for applications that require dynamic interactions based on user scrolling.
  • react-scrollspy: react-scrollspy is best suited for long single-page applications where you want to provide users with a clear indication of their current section. It enhances navigation usability and is often used in portfolio sites or documentation pages.
  • react-in-viewport: react-in-viewport is best used for scenarios where you need to manage the visibility of specific elements, such as lazy loading images or triggering animations when elements come into view. It is ideal for applications with limited visibility requirements.
How to Choose: react-intersection-observer vs react-scroll vs react-waypoint vs react-scrollspy vs react-in-viewport
  • react-intersection-observer: Select react-intersection-observer for a more robust and performant solution that leverages the Intersection Observer API. It is ideal for complex scenarios where you need to observe multiple elements and manage their visibility efficiently, especially in large applications.
  • react-scroll: Opt for react-scroll if your primary goal is to create smooth scrolling navigation within a single-page application. It is perfect for implementing scroll-to-anchor functionality and provides a simple way to manage scroll behavior with customizable options.
  • react-waypoint: Choose react-waypoint if you need to trigger actions based on scroll position, such as animations or loading data when an element comes into view. It is versatile for implementing scroll-based events and can be combined with other libraries for enhanced functionality.
  • react-scrollspy: Use react-scrollspy when you want to highlight navigation links based on the current scroll position. This is particularly useful for creating a dynamic navigation menu that updates as users scroll through different sections of your page, enhancing usability and engagement.
  • react-in-viewport: Choose react-in-viewport if you need a straightforward solution for detecting when elements enter or leave the viewport. It is simple to use and provides a clean API for managing visibility without the overhead of additional features.
README for react-intersection-observer

react-intersection-observer

Version Badge GZipped size Test License Downloads

React implementation of the Intersection Observer API to tell you when an element enters or leaves the viewport. Contains both a Hooks, render props and plain children implementation.

Features

  • 🪝 Hooks or Component API - With useInView it's easier than ever to monitor elements
  • ⚡️ Optimized performance - Reuses Intersection Observer instances where possible
  • ⚙️ Matches native API - Intuitive to use
  • 🛠 Written in TypeScript - It'll fit right into your existing TypeScript project
  • 🧪 Ready to test - Mocks the Intersection Observer for easy testing with Jest or Vitest
  • 🌳 Tree-shakeable - Only include the parts you use
  • 💥 Tiny bundle - Around ~1.15kB for useInView and ~1.6kB for <InView>

Open in StackBlitz

Installation

Install the package with your package manager of choice:

npm install react-intersection-observer --save

Usage

useInView hook

// Use object destructuring, so you don't need to remember the exact order
const { ref, inView, entry } = useInView(options);

// Or array destructuring, making it easy to customize the field names
const [ref, inView, entry] = useInView(options);

The useInView hook makes it easy to monitor the inView state of your components. Call the useInView hook with the (optional) options you need. It will return an array containing a ref, the inView status and the current entry. Assign the ref to the DOM element you want to monitor, and the hook will report the status.

import React from "react";
import { useInView } from "react-intersection-observer";

const Component = () => {
  const { ref, inView, entry } = useInView({
    /* Optional options */
    threshold: 0,
  });

  return (
    <div ref={ref}>
      <h2>{`Header inside viewport ${inView}.`}</h2>
    </div>
  );
};

Render props

To use the <InView> component, you pass it a function. It will be called whenever the state changes, with the new value of inView. In addition to the inView prop, children also receive a ref that should be set on the containing DOM element. This is the element that the Intersection Observer will monitor.

If you need it, you can also access the IntersectionObserverEntry on entry, giving you access to all the details about the current intersection state.

import { InView } from "react-intersection-observer";

const Component = () => (
  <InView>
    {({ inView, ref, entry }) => (
      <div ref={ref}>
        <h2>{`Header inside viewport ${inView}.`}</h2>
      </div>
    )}
  </InView>
);

export default Component;

Plain children

You can pass any element to the <InView />, and it will handle creating the wrapping DOM element. Add a handler to the onChange method, and control the state in your own component. Any extra props you add to <InView> will be passed to the HTML element, allowing you set the className, style, etc.

import { InView } from "react-intersection-observer";

const Component = () => (
  <InView as="div" onChange={(inView, entry) => console.log("Inview:", inView)}>
    <h2>Plain children are always rendered. Use onChange to monitor state.</h2>
  </InView>
);

export default Component;

[!NOTE] When rendering a plain child, make sure you keep your HTML output semantic. Change the as to match the context, and add a className to style the <InView />. The component does not support Ref Forwarding, so if you need a ref to the HTML element, use the Render Props version instead.

API

Options

Provide these as the options argument in the useInView hook or as props on the <InView /> component.

| Name | Type | Default | Description | | ---------------------- | ------------------------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | root | Element | document | The Intersection Observer interface's read-only root property identifies the Element or Document whose bounds are treated as the bounding box of the viewport for the element which is the observer's target. If the root is null, then the bounds of the actual document viewport are used. | | rootMargin | string | '0px' | Margin around the root. Can have values similar to the CSS margin property, e.g. "10px 20px 30px 40px" (top, right, bottom, left). Also supports percentages, to check if an element intersects with the center of the viewport for example "-50% 0% -50% 0%". | | threshold | number or number[] | 0 | Number between 0 and 1 indicating the percentage that should be visible before triggering. Can also be an array of numbers, to create multiple trigger points. | | onChange | (inView, entry) => void | undefined | Call this function whenever the in view state changes. It will receive the inView boolean, alongside the current IntersectionObserverEntry. | | trackVisibility 🧪 | boolean | false | A boolean indicating whether this Intersection Observer will track visibility changes on the target. | | delay 🧪 | number | undefined | A number indicating the minimum delay in milliseconds between notifications from this observer for a given target. This must be set to at least 100 if trackVisibility is true. | | skip | boolean | false | Skip creating the IntersectionObserver. You can use this to enable and disable the observer as needed. If skip is set while inView, the current state will still be kept. | | triggerOnce | boolean | false | Only trigger the observer once. | | initialInView | boolean | false | Set the initial value of the inView boolean. This can be used if you expect the element to be in the viewport to start with, and you want to trigger something when it leaves. | | fallbackInView | boolean | undefined | If the IntersectionObserver API isn't available in the client, the default behavior is to throw an Error. You can set a specific fallback behavior, and the inView value will be set to this instead of failing. To set a global default, you can set it with the defaultFallbackInView() |

InView Props

The <InView /> component also accepts the following props:

| Name | Type | Default | Description | | ------------ | ---------------------------------------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | as | IntrinsicElement | 'div' | Render the wrapping element as this element. Defaults to div. If you want to use a custom component, please use the useInView hook or a render prop instead to manage the reference explictly. | | children | ({ref, inView, entry}) => ReactNode or ReactNode | undefined | Children expects a function that receives an object containing the inView boolean and a ref that should be assigned to the element root. Alternatively pass a plain child, to have the <InView /> deal with the wrapping element. You will also get the IntersectionObserverEntry as entry, giving you more details. |

Intersection Observer v2 🧪

The new v2 implementation of IntersectionObserver extends the original API, so you can track if the element is covered by another element or has filters applied to it. Useful for blocking clickjacking attempts or tracking ad exposure.

To use it, you'll need to add the new trackVisibility and delay options. When you get the entry back, you can then monitor if isVisible is true.

const TrackVisible = () => {
  const { ref, entry } = useInView({ trackVisibility: true, delay: 100 });
  return <div ref={ref}>{entry?.isVisible}</div>;
};

This is still a very new addition, so check caniuse for current browser support. If trackVisibility has been set, and the current browser doesn't support it, a fallback has been added to always report isVisible as true.

It's not added to the TypeScript lib.d.ts file yet, so you will also have to extend the IntersectionObserverEntry with the isVisible boolean.

Recipes

The IntersectionObserver itself is just a simple but powerful tool. Here's a few ideas for how you can use it.

FAQ

How can I assign multiple refs to a component?

You can wrap multiple ref assignments in a single useCallback:

import React, { useRef, useCallback } from "react";
import { useInView } from "react-intersection-observer";

function Component(props) {
  const ref = useRef();
  const { ref: inViewRef, inView } = useInView();

  // Use `useCallback` so we don't recreate the function on each render
  const setRefs = useCallback(
    (node) => {
      // Ref's from useRef needs to have the node assigned to `current`
      ref.current = node;
      // Callback refs, like the one from `useInView`, is a function that takes the node as an argument
      inViewRef(node);
    },
    [inViewRef],
  );

  return <div ref={setRefs}>Shared ref is visible: {inView}</div>;
}

rootMargin isn't working as expected

When using rootMargin, the margin gets added to the current root - If your application is running inside a <iframe>, or you have defined a custom root this will not be the current viewport.

You can read more about this on these links:

Testing

In order to write meaningful tests, the IntersectionObserver needs to be mocked. You can use the included react-intersection-observer/test-utils to help with this. It mocks the IntersectionObserver, and includes a few methods to assist with faking the inView state. When setting the isIntersecting value you can pass either a boolean value or a threshold between 0 and 1. It will emulate the real IntersectionObserver, allowing you to validate that your components are behaving as expected.

| Method | Description | | --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | mockAllIsIntersecting(isIntersecting) | Set isIntersecting on all current Intersection Observer instances. The value of isIntersecting should be either a boolean or a threshold between 0 and 1. | | mockIsIntersecting(element, isIntersecting) | Set isIntersecting for the Intersection Observer of a specific element. The value of isIntersecting should be either a boolean or a threshold between 0 and 1. | | intersectionMockInstance(element) | Call the intersectionMockInstance method with an element, to get the (mocked) IntersectionObserver instance. You can use this to spy on the observe andunobserve methods. | | setupIntersectionMocking(mockFn) | Mock the IntersectionObserver, so we can interact with them in tests - Should be called in beforeEach. (Done automatically in Jest environment) | | resetIntersectionMocking() | Reset the mocks on IntersectionObserver - Should be called in afterEach. (Done automatically in Jest environment) |

Testing Libraries

This library comes with built-in support for writing tests in both Jest and Vitest

Jest

Testing with Jest should work out of the box. Just import the react-intersection-observer/test-utils in your test files, and you can use the mocking methods.

Vitest

If you're running Vitest with globals, then it'll automatically mock the IntersectionObserver, just like running with Jest. Otherwise, you'll need to manually setup/reset the mocking in either the individual tests, or a setup file.

import { vi, beforeEach, afterEach } from "vitest";
import {
  setupIntersectionMocking,
  resetIntersectionMocking,
} from "react-intersection-observer/test-utils";

beforeEach(() => {
  setupIntersectionMocking(vi.fn);
});

afterEach(() => {
  resetIntersectionMocking();
});

You only need to do this if the test environment does not support beforeEach globally, alongside either jest.fn or vi.fn.

Other Testing Libraries

See the instructions for Vitest. You should be able to use a similar setup/reset code, adapted to the testing library you are using. Failing that, copy the code from test-utils.ts, and make your own version.

Fallback Behavior

You can create a Jest setup file that leverages the unsupported fallback option. In this case, you can override the IntersectionObserver in test files were you actively import react-intersection-observer/test-utils.

test-setup.js

import { defaultFallbackInView } from "react-intersection-observer";

defaultFallbackInView(true); // or `false` - whichever consistent behavior makes the most sense for your use case.

Alternatively, you can mock the Intersection Observer in all tests with a global setup file. Add react-intersection-observer/test-utils to setupFilesAfterEnv in the Jest config, or setupFiles in Vitest.

module.exports = {
  setupFilesAfterEnv: ["react-intersection-observer/test-utils"],
};

Test Example

import React from "react";
import { screen, render } from "@testing-library/react";
import { useInView } from "react-intersection-observer";
import {
  mockAllIsIntersecting,
  mockIsIntersecting,
  intersectionMockInstance,
} from "react-intersection-observer/test-utils";

const HookComponent = ({ options }) => {
  const { ref, inView } = useInView(options);
  return (
    <div ref={ref} data-testid="wrapper">
      {inView.toString()}
    </div>
  );
};

test("should create a hook inView", () => {
  render(<HookComponent />);

  // This causes all (existing) IntersectionObservers to be set as intersecting
  mockAllIsIntersecting(true);
  screen.getByText("true");
});

test("should create a hook inView with threshold", () => {
  render(<HookComponent options={{ threshold: 0.3 }} />);

  mockAllIsIntersecting(0.1);
  screen.getByText("false");

  // Once the threshold has been passed, it will trigger inView.
  mockAllIsIntersecting(0.3);
  screen.getByText("true");
});

test("should mock intersecing on specific hook", () => {
  render(<HookComponent />);
  const wrapper = screen.getByTestId("wrapper");

  // Set the intersection state on the wrapper.
  mockIsIntersecting(wrapper, 0.5);
  screen.getByText("true");
});

test("should create a hook and call observe", () => {
  const { getByTestId } = render(<HookComponent />);
  const wrapper = getByTestId("wrapper");
  // Access the `IntersectionObserver` instance for the wrapper Element.
  const instance = intersectionMockInstance(wrapper);

  expect(instance.observe).toHaveBeenCalledWith(wrapper);
});

Intersection Observer

Intersection Observer is the API used to determine if an element is inside the viewport or not. Browser support is excellent - With Safari adding support in 12.1, all major browsers now support Intersection Observers natively. Add the polyfill, so it doesn't break on older versions of iOS and IE11.

Unsupported fallback

If the client doesn't have support for the IntersectionObserver, then the default behavior is to throw an error. This will crash the React application, unless you capture it with an Error Boundary.

If you prefer, you can set a fallback inView value to use if the IntersectionObserver doesn't exist. This will make react-intersection-observer fail gracefully, but you must ensure your application can correctly handle all your observers firing either true or false at the same time.

You can set the fallback globally:

import { defaultFallbackInView } from "react-intersection-observer";

defaultFallbackInView(true); // or 'false'

You can also define the fallback locally on useInView or <InView> as an option. This will override the global fallback value.

import React from "react";
import { useInView } from "react-intersection-observer";

const Component = () => {
  const { ref, inView, entry } = useInView({
    fallbackInView: true,
  });

  return (
    <div ref={ref}>
      <h2>{`Header inside viewport ${inView}.`}</h2>
    </div>
  );
};

Polyfill

You can import the polyfill directly or use a service like https://cdnjs.cloudflare.com/polyfill to add it when needed.

yarn add intersection-observer

Then import it in your app:

import "intersection-observer";

If you are using Webpack (or similar) you could use dynamic imports, to load the Polyfill only if needed. A basic implementation could look something like this:

/**
 * Do feature detection, to figure out which polyfills needs to be imported.
 **/
async function loadPolyfills() {
  if (typeof window.IntersectionObserver === "undefined") {
    await import("intersection-observer");
  }
}

Low level API

You can access the observe method, that react-intersection-observer uses internally to create and destroy IntersectionObserver instances. This allows you to handle more advanced use cases, where you need full control over when and how observers are created.

import { observe } from "react-intersection-observer";

const destroy = observe(element, callback, options);

| Name | Type | Required | Description | | ------------ | -------------------------- | -------- | ---------------------------------------------------------- | | element | Element | true | DOM element to observe | | callback | ObserverInstanceCallback | true | The callback function that Intersection Observer will call | | options | IntersectionObserverInit | false | The options for the Intersection Observer |

The observe method returns an unobserve function, that you must call in order to destroy the observer again.

[!IMPORTANT] You most likely won't need this, but it can be useful if you need to handle IntersectionObservers outside React, or need full control over how instances are created.