react-intersection-observer vs react-lazy-load vs react-lazy-load-image-component vs react-lazyload
Lazy Loading and Intersection Observation in React Applications
react-intersection-observerreact-lazy-loadreact-lazy-load-image-componentreact-lazyloadSimilar Packages:

Lazy Loading and Intersection Observation in React Applications

These four packages solve related but distinct problems around lazy loading content and detecting element visibility in React applications. react-intersection-observer provides a low-level hook and component wrapper for the native Intersection Observer API, giving developers fine-grained control over when elements enter or leave the viewport. react-lazy-load and react-lazyload both focus on lazy loading React components when they become visible, though they use different APIs and approaches. react-lazy-load-image-component is specialized for lazy loading images with built-in support for placeholders, blur effects, and progressive loading. Understanding the differences helps teams choose the right tool for their specific performance and UX requirements.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package
Downloads
Stars
Size
Issues
Publish
License
react-intersection-observer05,539164 kB54 months agoMIT
react-lazy-load098013.7 kB20-MIT
react-lazy-load-image-component01,55295.4 kB572 years agoMIT
react-lazyload05,90436.2 kB1612 years agoMIT

Lazy Loading and Intersection Observation in React: A Technical Deep-Dive

When building performance-focused React applications, loading content only when users need it becomes critical. The four packages we're comparing — react-intersection-observer, react-lazy-load, react-lazy-load-image-component, and react-lazyload — all tackle visibility detection and lazy loading, but they solve different problems with different levels of abstraction. Let's break down how each works and when to reach for them.

🔍 Core Purpose: What Each Package Actually Does

react-intersection-observer wraps the native Intersection Observer API in React hooks and components. It doesn't lazy load anything by default — it just tells you when elements enter or leave the viewport.

// react-intersection-observer: Hook-based visibility detection
import { useInView } from 'react-intersection-observer';

function MyComponent() {
  const { ref, inView } = useInView({
    threshold: 0.5,
    triggerOnce: true
  });

  return (
    <div ref={ref}>
      {inView ? <VisibleContent /> : <Placeholder />}
    </div>
  );
}

react-lazy-load lazy loads entire React components when they become visible. It handles the rendering logic internally.

// react-lazy-load: Component wrapper approach
import LazyLoad from 'react-lazy-load';

function MyComponent() {
  return (
    <LazyLoad height={200} offset={100}>
      <HeavyComponent />
    </LazyLoad>
  );
}

react-lazy-load-image-component specializes in image lazy loading with UX enhancements like blur effects and placeholders.

// react-lazy-load-image-component: Image-specific lazy loading
import { LazyLoadImage } from 'react-lazy-load-image-component';
import 'react-lazy-load-image-component/src/effects/blur.css';

function MyComponent() {
  return (
    <LazyLoadImage
      src="/images/photo.jpg"
      alt="Photo"
      effect="blur"
      placeholderSrc="/images/placeholder.jpg"
    />
  );
}

react-lazyload provides a similar component wrapper approach to react-lazy-load but with a different API structure.

// react-lazyload: Alternative component wrapper
import LazyLoad from 'react-lazyload';

function MyComponent() {
  return (
    <LazyLoad height={200} offset={100} once={true}>
      <HeavyComponent />
    </LazyLoad>
  );
}

📐 API Design: Hooks vs Components vs Specialized Wrappers

The API design choices significantly impact how you integrate these packages into your codebase.

react-intersection-observer offers both hooks and render props, giving you maximum flexibility.

// Hook approach (recommended)
import { useInView } from 'react-intersection-observer';

function AnalyticsTracker() {
  const { ref, inView } = useInView();
  
  useEffect(() => {
    if (inView) {
      trackImpression();
    }
  }, [inView]);
  
  return <div ref={ref}>Tracked content</div>;
}

// Component approach
import { InView } from 'react-intersection-observer';

function AnalyticsTracker() {
  return (
    <InView>
      {({ inView, ref }) => (
        <div ref={ref}>
          {inView ? 'Visible' : 'Hidden'}
        </div>
      )}
    </InView>
  );
}

react-lazy-load uses a simple wrapper component that children render only when visible.

import LazyLoad from 'react-lazy-load';

function ContentList() {
  return (
    <div>
      {items.map(item => (
        <LazyLoad key={item.id} height={300}>
          <ComplexCard data={item} />
        </LazyLoad>
      ))}
    </div>
  );
}

react-lazy-load-image-component provides a drop-in replacement for standard <img> tags with extra props.

import { LazyLoadImage, trackWindowScroll } from 'react-lazy-load-image-component';

// With scroll tracking for better performance
function ScrollableGallery() {
  return (
    <div className="gallery">
      {images.map(img => (
        <LazyLoadImage
          key={img.id}
          src={img.src}
          alt={img.alt}
          wrapperProps={{ className: 'image-wrapper' }}
        />
      ))}
    </div>
  );
}

react-lazyload uses similar wrapper patterns but with different prop names and behavior.

import LazyLoad from 'react-lazyload';

function ContentList() {
  return (
    <div>
      {items.map(item => (
        <LazyLoad 
          key={item.id} 
          height={300}
          once={true}
          placeholder={<Skeleton />}
        >
          <ComplexCard data={item} />
        </LazyLoad>
      ))}
    </div>
  );
}

⚡ Performance Characteristics and Optimization Options

Each package handles performance differently, which matters for large lists or scroll-heavy pages.

react-intersection-observer gives you direct control over Observer options like threshold, root margin, and tracking behavior.

import { useInView } from 'react-intersection-observer';

function OptimizedTracker() {
  const { ref, inView } = useInView({
    threshold: 0,        // Trigger when any pixel is visible
    rootMargin: '0px',   // No extra margin around viewport
    triggerOnce: true,   // Only trigger once (good for analytics)
    skip: false          // Can conditionally disable observation
  });

  return <div ref={ref}>Content</div>;
}

react-lazy-load supports offset loading and height placeholders to prevent layout shift.

import LazyLoad from 'react-lazy-load';

function OptimizedList() {
  return (
    <LazyLoad 
      height={200}           // Reserve space to prevent CLS
      offset={100}           // Start loading 100px before visible
      throttle={100}         // Throttle scroll events
      debounce={50}          // Debounce resize events
    >
      <HeavyComponent />
    </LazyLoad>
  );
}

react-lazy-load-image-component includes scroll position tracking to batch visibility checks.

import { LazyLoadImage, trackWindowScroll } from 'react-lazy-load-image-component';

// Wrap your scrollable container
function ScrollableContainer() {
  return (
    <div className="scroll-wrapper">
      {images.map(img => (
        <LazyLoadImage
          key={img.id}
          src={img.src}
          scrollPosition={scrollPosition}  // From trackWindowScroll
        />
      ))}
    </div>
  );
}

// Higher up in your component tree
function App() {
  const [scrollPosition, setScrollPosition] = useState(0);
  
  useEffect(() => {
    const handleScroll = () => setScrollPosition(window.scrollY);
    window.addEventListener('scroll', handleScroll);
    return () => window.removeEventListener('scroll', handleScroll);
  }, []);
  
  return <ScrollableContainer />;
}

react-lazyload offers similar optimization props with slightly different naming.

import LazyLoad from 'react-lazyload';

function OptimizedList() {
  return (
    <LazyLoad 
      height={200}
      offset={100}
      once={true}           // Load only once
      unmountIfInvisible={false}  // Keep mounted after load
      throttle={100}
      placeholder={<Skeleton />}
    >
      <HeavyComponent />
    </LazyLoad>
  );
}

🎨 UX Features: Placeholders, Effects, and Loading States

User experience during loading varies significantly between packages.

react-intersection-observer requires you to build your own loading states — it only tells you visibility.

import { useInView } from 'react-intersection-observer';

function CustomLoadingState() {
  const { ref, inView } = useInView({ triggerOnce: true });
  const [loaded, setLoaded] = useState(false);

  useEffect(() => {
    if (inView) {
      // Start loading
      loadData().then(() => setLoaded(true));
    }
  }, [inView]);

  return (
    <div ref={ref}>
      {!loaded && <Spinner />}
      {loaded && <Content />}
    </div>
  );
}

react-lazy-load supports custom placeholders but no built-in effects.

import LazyLoad from 'react-lazy-load';

function WithPlaceholder() {
  return (
    <LazyLoad 
      height={200}
      placeholder={<div className="skeleton">Loading...</div>}
    >
      <HeavyComponent />
    </LazyLoad>
  );
}

react-lazy-load-image-component shines with built-in visual effects.

import { LazyLoadImage } from 'react-lazy-load-image-component';
import 'react-lazy-load-image-component/src/effects/blur.css';
import 'react-lazy-load-image-component/src/effects/black-and-white.css';

function ImageGallery() {
  return (
    <div>
      {/* Blur effect */}
      <LazyLoadImage
        src="/photo1.jpg"
        effect="blur"
        placeholderSrc="/photo1-thumb.jpg"
      />
      
      {/* Black and white to color */}
      <LazyLoadImage
        src="/photo2.jpg"
        effect="black-and-white"
      />
      
      {/* Custom opacity transition */}
      <LazyLoadImage
        src="/photo3.jpg"
        wrapperClassName="custom-transition"
      />
    </div>
  );
}

react-lazyload supports placeholders with more configuration options.

import LazyLoad from 'react-lazyload';

function WithCustomPlaceholder() {
  return (
    <LazyLoad 
      height={200}
      placeholder={
        <div className="custom-placeholder">
          <Spinner />
          <p>Loading content...</p>
        </div>
      }
      unmountIfInvisible={false}
    >
      <HeavyComponent />
    </LazyLoad>
  );
}

🔧 Integration Patterns: Real-World Use Cases

Infinite Scroll Implementation

react-intersection-observer is the standard choice for infinite scroll.

import { useInView } from 'react-intersection-observer';

function InfiniteList() {
  const { ref, inView } = useInView();
  const [page, setPage] = useState(1);
  const [items, setItems] = useState([]);

  useEffect(() => {
    if (inView) {
      setPage(prev => prev + 1);
    }
  }, [inView]);

  useEffect(() => {
    fetchItems(page).then(newItems => {
      setItems(prev => [...prev, ...newItems]);
    });
  }, [page]);

  return (
    <div>
      {items.map(item => <Item key={item.id} data={item} />)}
      <div ref={ref}>Loading more...</div>
    </div>
  );
}

react-lazy-load works for lazy loading list items themselves.

import LazyLoad from 'react-lazy-load';

function LazyList() {
  return (
    <div>
      {items.map(item => (
        <LazyLoad key={item.id} height={100}>
          <ListItem data={item} />
        </LazyLoad>
      ))}
    </div>
  );
}

react-lazy-load-image-component handles images within infinite scroll.

import { LazyLoadImage } from 'react-lazy-load-image-component';

function ImageFeed() {
  return (
    <div>
      {posts.map(post => (
        <article key={post.id}>
          <LazyLoadImage src={post.image} alt={post.title} />
          <h3>{post.title}</h3>
        </article>
      ))}
    </div>
  );
}

react-lazyload provides similar list item lazy loading.

import LazyLoad from 'react-lazyload';

function LazyList() {
  return (
    <div>
      {items.map(item => (
        <LazyLoad key={item.id} height={100} once={true}>
          <ListItem data={item} />
        </LazyLoad>
      ))}
    </div>
  );
}

Analytics and Tracking

react-intersection-observer is purpose-built for this use case.

import { useInView } from 'react-intersection-observer';

function TrackedSection() {
  const { ref, inView } = useInView({
    threshold: 0.5,
    triggerOnce: true
  });

  useEffect(() => {
    if (inView) {
      analytics.track('section_viewed', { sectionId: 'pricing' });
    }
  }, [inView]);

  return (
    <section ref={ref} id="pricing">
      <PricingTable />
    </section>
  );
}

The other three packages are not designed for analytics tracking — they focus on rendering optimization.

⚠️ Maintenance Status and Long-Term Viability

Package maintenance affects your long-term technical debt.

react-intersection-observer shows active maintenance with regular updates and strong TypeScript support. It's the safest choice for new projects requiring visibility detection.

react-lazy-load receives occasional updates but has a smaller maintenance footprint. It works well for straightforward component lazy loading needs.

react-lazy-load-image-component maintains steady updates focused on image loading features. It's the most specialized package but well-maintained for its niche.

react-lazyload shows reduced maintenance activity compared to alternatives. Many teams have migrated to react-intersection-observer or native React.lazy() for new projects. Consider this primarily for legacy codebases already using it.

📊 Feature Comparison Summary

Featurereact-intersection-observerreact-lazy-loadreact-lazy-load-image-componentreact-lazyload
Primary UseVisibility detectionComponent lazy loadImage lazy loadComponent lazy load
API StyleHooks + ComponentsWrapper ComponentSpecialized ComponentWrapper Component
Built-in Effects❌ No❌ No✅ Yes (blur, etc.)❌ No
Placeholder SupportManual✅ Yes✅ Yes✅ Yes
Scroll TrackingNative ObserverThrottle/DebounceWindow scroll trackingThrottle/Debounce
TypeScript Support✅ Excellent✅ Good✅ Good⚠️ Limited
Active Maintenance✅ High⚠️ Moderate✅ Moderate⚠️ Low
Best ForAnalytics, infinite scrollHeavy componentsImages with UX effectsLegacy projects

💡 Practical Recommendations

For new projects requiring visibility detection: Start with react-intersection-observer. It gives you the most control and has the strongest maintenance track record. You can build custom lazy loading on top of it if needed.

For image-heavy applications: Use react-lazy-load-image-component. The built-in blur effects and placeholder handling save significant development time while improving Core Web Vitals scores.

For lazy loading complex components: Consider react-lazy-load for a simple wrapper approach, or evaluate React's native React.lazy() with Suspense for code-splitting at the bundle level.

For existing projects using react-lazyload: Plan a migration path to more actively maintained alternatives when possible. The API differences are manageable, and you'll benefit from better long-term support.

🎯 The Bottom Line

These packages solve overlapping but distinct problems. react-intersection-observer is your visibility detection primitive — use it when you need to know when things appear. react-lazy-load and react-lazyload lazy load components with different APIs. react-lazy-load-image-component specializes in images with enhanced UX.

Pick based on your specific need: visibility tracking, component lazy loading, or image optimization. Don't reach for a component lazy loader when you just need to detect visibility — and don't use a generic visibility hook when you need image-specific features like blur effects.

How to Choose: react-intersection-observer vs react-lazy-load vs react-lazy-load-image-component vs react-lazyload

  • react-intersection-observer:

    Choose react-intersection-observer when you need precise control over visibility detection without built-in lazy loading logic. It's ideal for analytics tracking, infinite scroll implementations, or triggering animations when elements come into view. This package gives you the raw Intersection Observer API wrapped in React-friendly hooks and components, making it the most flexible option for custom visibility-based behaviors.

  • react-lazy-load:

    Choose react-lazy-load when you want to lazy load entire React components with a simple wrapper API. It works well for heavy components that should only render when visible, such as complex charts, maps, or data-heavy sections. This package is best for projects that need component-level lazy loading without the complexity of React.lazy() and Suspense boundaries.

  • react-lazy-load-image-component:

    Choose react-lazy-load-image-component specifically for image lazy loading with enhanced UX features. It includes built-in support for placeholder images, blur-up effects, and progressive JPEG loading. This is the go-to choice for content-heavy sites, galleries, or e-commerce platforms where image performance directly impacts user experience and Core Web Vitals.

  • react-lazyload:

    Choose react-lazyload with caution as it shows signs of reduced maintenance activity. It was popular for lazy loading components and images with a straightforward API, but many teams have migrated to more actively maintained alternatives. Consider this only for legacy projects already using it, and evaluate react-intersection-observer or react-lazy-load for new development work.

README for react-intersection-observer

react-intersection-observer

Version Badge Test License Downloads npm package minimized gzipped size

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

Features

  • 🪝 Hooks or Component API - With useInView and useOnInView 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> useInView InView useOnInView

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>
  );
};

Note: The first false notification from the underlying IntersectionObserver is ignored so your handlers only run after a real visibility change. Subsequent transitions still report both true and false states as the element enters and leaves the viewport.

useOnInView hook

const inViewRef = useOnInView(
  (inView, entry) => {
    if (inView) {
      // Do something with the element that came into view
      console.log("Element is in view", entry.target);
    } else {
      console.log("Element left view", entry.target);
    }
  },
  options // Optional IntersectionObserver options
);

The useOnInView hook provides a more direct alternative to useInView. It takes a callback function and returns a ref that you can assign to the DOM element you want to monitor. Whenever the element enters or leaves the viewport, your callback will be triggered with the latest in-view state.

Key differences from useInView:

  • No re-renders - This hook doesn't update any state, making it ideal for performance-critical scenarios
  • Direct element access - Your callback receives the actual IntersectionObserverEntry with the target element
  • Boolean-first callback - The callback receives the current inView boolean as the first argument, matching the onChange signature from useInView
  • Similar options - Accepts all the same options as useInView except onChange, initialInView, and fallbackInView

Note: Just like useInView, the initial false notification is skipped. Your callback fires the first time the element becomes visible (and on every subsequent enter/leave transition).

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

const Component = () => {
  // Track when element appears without causing re-renders
  const trackingRef = useOnInView(
    (inView, entry) => {
      if (inView) {
        // Element is in view - perhaps log an impression
        console.log("Element appeared in view", entry.target);
      } else {
        console.log("Element left view", entry.target);
      }
    },
    {
      /* Optional options */
      threshold: 0.5,
      triggerOnce: true,
    },
  );

  return (
    <div ref={trackingRef}>
      <h2>This element is being tracked without re-renders</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;

Note: <InView> mirrors the hook behaviour—it suppresses the very first false notification so render props and onChange handlers only run after a genuine visibility change.

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.

NameTypeDefaultDescription
rootElementdocumentThe 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.
rootMarginstring'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%".
thresholdnumber or number[]0Number 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) => voidundefinedCall this function whenever the in view state changes. It will receive the inView boolean, alongside the current IntersectionObserverEntry.
trackVisibility 🧪booleanfalseA boolean indicating whether this Intersection Observer will track visibility changes on the target.
delay 🧪numberundefinedA 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.
skipbooleanfalseSkip 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.
triggerOncebooleanfalseOnly trigger the observer once.
initialInViewbooleanfalseSet 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.
fallbackInViewbooleanundefinedIf 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()

useOnInView accepts the same options as useInView except onChange, initialInView, and fallbackInView.

InView Props

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

NameTypeDefaultDescription
asIntrinsicElement'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 ReactNodeundefinedChildren 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

[!TIP] Consider using Vitest Browser Mode instead of jsdom or happy-dom. This option allows you to utilize the real browser implementation and triggers correctly when scrolling or adding elements to the viewport. You can skip the react-intersection-observer/test-utils, or use it as needed.

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.

MethodDescription
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/Vitest environment)
destroyIntersectionMocking()Destroy the mocked IntersectionObserver function, and return window.IntersectionObserver to the original browser implementation

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);
NameTypeRequiredDescription
elementElementtrueDOM element to observe
callbackObserverInstanceCallbacktrueThe callback function that Intersection Observer will call
optionsIntersectionObserverInitfalseThe 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.