DEV Community: Phuoc Nguyen

Lazy load a Google Map

Phuoc Nguyen — Mon, 08 Apr 2024 01:57:49 +0000

Google Maps is a powerful tool to add interactive maps to your website. However, embedding a Google Map can negatively affect your site's performance, especially on mobile devices. The map may take a while to load, slowing down your page and frustrating users.

Luckily, we can use lazy loading to defer loading the Google Map until it's actually needed. By using the IntersectionObserver API, we can detect when the map container enters the viewport and only load the map then. This can significantly improve your site's initial load time and performance.

In this post, we'll show you how to lazy load a Google Map in a React component using IntersectionObserver.

Creating the map container

To start, we need to create a container for our Google Map in our React component. By giving the container a ref, we can easily reference it later with IntersectionObserver.

const mapRef = React.useRef<HTMLDivElement>(null);

// Render
return (
    {/* Other content */}
    <div ref={mapRef} />
);

Setting up the IntersectionObserver

Now, we're going to set up an IntersectionObserver to keep an eye on the map container and load the map only when it enters the viewport.

To create an IntersectionObserver, we need to create an instance of the IntersectionObserver class. The constructor takes two arguments: a callback function to execute when the observed element intersects with the viewport, and an options object that specifies additional parameters for the observer.

We also define an options object that sets a visibility threshold of 0. This means that our callback function will be triggered as soon as even a single pixel of our map container is visible within the viewport.

In our case, we want to observe the map container and load the map only when it enters the viewport. To do this, we'll pass a callback function to the constructor that will iterate through each entry in the entries parameter and check if it's intersecting with the viewport using entry.isIntersecting. If it is, we'll load our Google Map and stop observing further changes by calling observer.unobserve(mapEle). This way, we're only loading the map once, and only when it's necessary.

React.useEffect(() => {
    const mapEle = mapRef.current;
    if (!mapEle) {
        return;
    }

    const observer = new IntersectionObserver((entries) => {
        entries.forEach((entry) => {
            if (entry.isIntersecting) {
                // Load the map ...
                observer.unobserve(mapEle);
            }
        });
    }, {
        threshold: 0,
    });
}, []);

Next, we call its observe() method with our map container element as its argument. This starts watching the element's visibility. Finally, we return a cleanup function from the useEffect() hook. This function unobserves our map container element when it's removed from the DOM or when our component is unmounted.

React.useEffect(() => {
    ...
    observer.observe(mapEle);

    return (): void => {
        observer.unobserve(mapEle);
    };
}, []);

Loading Google Maps with a specific callback

Once the IntersectionObserver callback is triggered, we can load the Google Maps. To achieve that, we'll create a script tag that loads the Google Maps JavaScript API. The API_KEY provided by Google will be passed to the src attribute of the script. Once the API is loaded, it will call the initMap function specified within the script.

const API_KEY = '...';

const script = document.createElement('script');
script.src = `https://maps.googleapis.com/maps/api/js?key=${API_KEY}&callback=initMap`;
script.async = true;
document.body.appendChild(script);

window.initMap = initMap;

The initMap function is responsible for creating a new instance of Google Map. It specifies the map container element and some initial options like center coordinates and zoom level.

const initMap = () => {
    const mapEle = mapRef.current;
    if (mapEle) {
        new window.google.maps.Map(mapEle, {
            center: new window.google.maps.LatLng(40.73061, -73.935242), // New York city
            zoom: 10,
        });
    }
};

Take a look at the demo below. You can scroll down to see how the map loads dynamically:

If you'd rather not rely on the callback parameter, there's another way to ensure that the Google Map API is fully loaded before we try to use it. We can listen to its load event. This is crucial because attempting to create a new instance of the Google Map before the API is fully loaded will result in an error.

Here's how to do it:

const script = document.createElement('script');
script.addEventListener('load', () => {
    new window.google.maps.Map(mapEle, {
        center: new window.google.maps.LatLng(40.73061, -73.935242), // New York city
        zoom: 10,
    });
});

Take a look at the demo below:

Conclusion

Using IntersectionObserver to lazy load our Google Map can greatly improve our website's performance. The map will only load when the user scrolls it into view, reducing the initial load time of the page.

This technique isn't just limited to Google Maps. It can be applied to any resource that's expensive to load. Lazy loading is a powerful tool that can optimize your site's performance and provide a better user experience.

If you want more helpful content like this, feel free to follow me:

Lazy load a video

Phuoc Nguyen — Fri, 05 Apr 2024 03:26:45 +0000

Lazy loading is an awesome technique that delays the loading of non-essential resources, such as images and videos, until they're actually needed. This can make a huge difference in how quickly a website loads, especially for pages with a lot of media content.

In one of our previous posts, we showed you how to lazy load images using the IntersectionObserver API. In this post, we'll take it a step further and show you how to use the same technique to lazy load videos too.

Using IntersectionObserver to detect when a video is visible

The IntersectionObserver API is a powerful tool that lets you know when an element enters or leaves the viewport. This is particularly useful for lazy loading because we only want to load a video when the user can actually see it.

Here's the code snippet that shows how we can do it:

const videoRef = React.useRef<HTMLVideoElement>(null);

React.useEffect(() => {
    const video = videoRef.current;
    if (!video) {
        return;
    }

    const observer = new IntersectionObserver((entries) => {
        entries.forEach((entry) => {
            if (entry.isIntersecting) {
                video.src = video.dataset.src;
                observer.unobserve(video);
            }
        });
    }, {
        threshold: 0,
    });

    observer.observe(video);

    return () => {
        observer.unobserve(video);
    };
}, []);

return (
    <video
        ref={videoRef}
        data-src="/path/to/video.mp4"
        controls
    />
);

In this example, we create a reference called videoRef and attach it to the <video> element. Then, we use a useEffect hook to create a new instance of IntersectionObserver that will watch the video element.

When the video becomes visible (i.e., it intersects with the viewport), the observer callback is triggered. Inside the callback, we set the src attribute of the video to the value of the data-src attribute, which contains the actual video URL.

To prevent the video from being loaded again if it leaves and re-enters the viewport, we unobserve the video element.

Check out the demo below to see it in action!

Video credit: City traffic by @xat-ch

Displaying a loading indicator

It's always a good idea to show a loading indicator while the video is loading. This lets the user know that something is happening. You can easily achieve this by conditionally rendering a loading spinner based on the video's loading state.

const [isLoading, setIsLoading] = React.useState(true);

const handleLoadedData = () => {
    setIsLoading(false);
};

return (
    <div className="container">
        {isLoading && <div className="loading">Loading...</div>}
        <video
            ref={videoRef}
            data-src="/path/to/video.mp4"
            onLoadedData={handleLoadedData}
            controls
        />
    </div>
);

To improve the user experience, we can add a isLoading state variable that starts out as true. We also attach an onLoadedData event handler to the video that sets isLoading to false once the video metadata has loaded.

To visually indicate to the user that the video is loading, we conditionally render a loading indicator element in the JSX if isLoading is true. This loading indicator can be any kind of spinner or placeholder you want.

Check out the demo below. Scroll down to the bottom to see the loading indicator appear before the video is completely loaded.

Conclusion

One way to improve your website's performance is by using IntersectionObserver to lazy load videos. This means that the videos won't load until the user can see them, which reduces page load time and saves bandwidth.

Don't forget to add a loading indicator when you implement lazy loading. This will let users know that content is coming and improve their experience on your website.

If you want more helpful content like this, feel free to follow me:

Lazy load an iframe

Phuoc Nguyen — Thu, 04 Apr 2024 01:32:17 +0000

In our previous posts, we learned how to use the Intersection Observer API to lazy load images and background images. This powerful tool allows us to detect when an element enters the viewport and take action accordingly, such as loading resources on demand.

Now, let's talk about iframes. They're commonly used to embed external content, like videos, maps, or ads. But iframes can be slow and resource-intensive, especially if they contain large or complex content. That's where lazy loading comes in. By deferring the loading of iframes until they're actually needed, you can improve your page's performance and user experience.

In this post, we'll dive into how to use the Intersection Observer API to lazy load iframes.

Setting up an iframe for lazy loading

Setting up lazy loading for an iframe is similar to lazy loading images. Instead of setting the src attribute directly, we'll use a custom data attribute like data-src. This way, the iframe won't load immediately when the page loads.

<iframe
    ref={iframeRef}
    data-src="https://path/to/iframe"
/>

We've added a ref to the iframe, which we'll use to observe it with the IntersectionObserver.

const iframeRef = React.useRef<HTMLIFrameElement>(null);

Setting up the IntersectionObserver

In the next step, we'll set up an IntersectionObserver to watch the iframe and detect when it comes into view. Once the iframe becomes visible, we'll grab the URL from the data-src attribute and use it to set the src attribute, which will start loading the iframe.

Here's a code snippet that uses the useEffect hook to create an instance of the IntersectionObserver:

React.useEffect(() => {
    const iframe = iframeRef.current;

    const observer = new IntersectionObserver(([entry]) => {
        if (entry.isIntersecting) {
            // Load the iframe when it's visible
            iframe.src = iframe.dataset.src;
            observer.unobserve(iframe);
        }
    }, {
        threshold: 0,
    });

    observer.observe(iframe);

    return () => {
        observer.disconnect();
    };
}, []);

In this code snippet, we're creating an Intersection Observer that watches an element (in this case, an iframe) to see if it's visible in the viewport. If it is, we grab the URL from the data-src attribute using iframe.dataset.src, and use it to set the src attribute of the iframe. Then, we stop observing the iframe since it's already been loaded.

Check out the demo below and see how it works by scrolling down to the bottom.

Video credit: Glacier express by @xat-ch

Improving user experience with loading indicators

To enhance the user experience, it's essential to display a loading indicator or placeholder while an iframe is loading. You can easily achieve this by adding a loading class to the iframe, which will display a loading indicator as a background image. This creates a placeholder where the iframe will be displayed.

<iframe data-src="..." className="loading"></iframe>

To define the loading class in CSS, we set its background property to an image file that contains a loading indicator. We use center center no-repeat to position the image at the center of the iframe and prevent it from repeating.

.loading {
    background: url('/path/to/loading.svg') center center no-repeat;
}

After the iframe finishes loading, you can remove the loading class and display its content instead of the placeholder. To achieve this, we simply add an event listener for the load event on the iframe.

const handleLoadFrame = () => {
    const iframe = iframeRef.current;
    if (iframe) {
        iframe.classList.remove('loading');
    }
};

// Render
<iframe onLoad={handleLoadFrame} />

If you're not interested in using a background image for the loading indicator, there's another option. We can use state variables to keep track of when the iframe is loading and when it's loaded.

To do this, we'll use an enum called Status with three possible values: NotLoaded, Loading, and Loaded. We'll also create a state variable called status to keep track of the current status of the iframe.

enum Status {
    NotLoaded,
    Loading,
    Loaded,
}

const [status, setStatus] = React.useState(Status.NotLoaded);

When the iframe is first displayed, it's set to NotLoaded. As soon as it begins to load, we change the status to Loading.

const observer = new IntersectionObserver((entries) => {
    entries.forEach((entry) => {
        if (entry.isIntersecting) {
            setStatus(Status.Loading);
        }
    });
}, {
    threshold: 0,
});

Once the iframe finishes loading, we update the status to Loaded. To achieve this, we can add an event listener for the load event on the iframe. When this event triggers, we set the status to Loaded.

const handleLoadFrame = () => {
    setStatus(Status.Loaded);
};

// Render
<iframe onLoad={handleLoadFrame} />

Using this setup, we can choose to display different components based on the current status of the iframe. For instance, while the iframe is loading, we could show a spinner or progress bar. Once it's completely loaded, we could then display the content of the iframe.

<div className="container">
    {status === Status.Loading && (
        <div className="loading">Loading ...</div>
    )}
    <iframe ... />
</div>

That's it! We've successfully created an iframe that only loads when it appears on the screen. This can significantly improve the performance of pages with multiple iframes.

Take a look at the demo below to see it in action:

Conclusion

Using the Intersection Observer API to lazy load iframes is an easy and effective way to boost your page's performance. By delaying the loading of iframes until they're actually visible in the viewport, you can speed up your page's initial load time and make for a smoother user experience. Just make sure you handle the loading states properly so your users know what's happening.

If you want more helpful content like this, feel free to follow me:

Lazy load a background image

Phuoc Nguyen — Wed, 03 Apr 2024 01:24:13 +0000

There are times when using a background image is a better option than using an img tag. For instance, if you want to display an image that's purely for decoration and doesn't convey important information to the user, a background image is a great choice. Also, if you have multiple instances of the same image on a page (like repeating patterns), using a background image is more efficient since it only needs to load once.

In our last post, we learned how to use IntersectionObserver to lazy load an image. In this post, we'll use the same technique to lazy load a background image of an element. Let's dive in!

Updating the background image attribute

When we want to set the background image of an element in CSS, we typically use the background-image property.

<div
    style={{
        backgroundImage: `url(...)`
    }}
/>

However, to lazy load the background image, we can use a similar approach to lazy loading an image. First, we replace the background-image style with a custom data attribute, such as data-background-src. Then, we monitor the intersection of the element. Once the element is visible in the viewport, we reset the background-image style with the image specified in the custom attribute.

To begin, we use a custom data attribute to show where the background image comes from. It's worth noting that the value of our custom attribute directly stores the image URL, without the url function found in the original background-image attribute.

<div
    ref={elementRef}
    data-background-src={`https://...`}
/>

The elementRef in React refers to the target element we want to observe. To create an IntersectionObserver, we use the sample code below with a callback function that takes an array of entries as its argument. The entries array contains information about the intersection between the observed element and the viewport.

The options object passed to the constructor of IntersectionObserver specifies a threshold of zero. This means that as soon as any part of the observed element intersects with any part of the viewport, the callback function will be called.

Inside the callback function, we loop over each entry in the entries array. If an entry's isIntersecting property is true, then we know that the observed element is now visible in the viewport.

Using the useEffect hook, we can watch the intersection changes of the element.

React.useEffect(() => {
    const element = elementRef.current;
    if (!element) {
        return;
    }

    const observer = new IntersectionObserver((entries) => {
        entries.forEach((entry) => {
            if (entry.isIntersecting) {
                // The element is visible ...
            }
        });
    }, {
        threshold: 0,
    });
    observer.observe(element);

    return (): void => {
        observer.unobserve(element);
    };
}, []);

To get the URL of our background image, we first need to reference the element using entry.target. Then, we retrieve the image URL from our custom data attribute data-background-src.

Once we have the URL, we remove the custom data attribute by calling ele.removeAttribute('data-background-src'). This step ensures that we don't accidentally reset the background image if the same code runs again, such as when an element is scrolled out of view and then back into view.

Finally, we update the background-image style by setting it equal to our retrieved URL using string interpolation: ele.style.backgroundImage = `url(${src})`. This will make sure our background image is displayed correctly.

// The element is visible
const ele = entry.target;
const src = ele.getAttribute('data-background-src');
ele.removeAttribute('data-background-src');
// Update the `background-image` style
ele.style.backgroundImage = `url(${src})`;

observer.unobserve(ele);

You can see it in action by checking out the live demo below.

Image credit: 10019, New York, United States by @benobro

Elevating user experience with a loading indicator

Let's take our user experience to the next level by adding a loading indicator that appears while the background image is loading. This lets users know that an image is on its way and helps prevent frustration and confusion.

We can achieve this by defining an enumeration with three possible values: NotLoaded, Loading, and Loaded. The NotLoaded value means the image hasn't loaded yet. The Loading value indicates that the image is currently loading. Lastly, the Loaded value indicates that the image has fully loaded.

 enum Status {
    NotLoaded,
    Loading,
    Loaded,
}

We're adding a new status state to manage the loading status of the background image. Initially, the state is set to NotLoaded.

const [status, setStatus] = React.useState(Status.NotLoaded);

Once the image becomes visible, the state changes to Loading. Here's how the status changes with the modified code:

const observer = new IntersectionObserver((entries) => {
    entries.forEach((entry) => {
        if (entry.isIntersecting) {
            const ele = entry.target;
            setStatus(Status.Loading);
        }
    });
}, {
    threshold: 0,
});

When the status state changes to Loading, we create a new Image element and set its source to the URL of our background image. Then, we add an event listener for the load event, which fires once the image finishes loading.

Inside this event listener, we update the status state to Loaded. This change triggers a re-render of our component, which also removes our custom data attribute and updates the background-image style with our retrieved URL.

const image = new Image();
image.src = src;
image.addEventListener('load', () => {
    setStatus(Status.Loaded);
    ele.removeAttribute('data-background-src');
    // Update the `background-image` style
    ele.style.backgroundImage = `url(${src})`;
});

When we update the state, it triggers a re-render, allowing us to display different content based on whether or not the background image has finished loading. For example, we can show a loading message by checking if the status is set to Loading.

<div className="container">
    {status === Status.Loading && (
        <div className="loading">Loading ...</div>
    )}
</div>

To see how to position the loading indicator, take a look at the previous post. You can also check out the demo below and scroll down to the bottom to see the loading indicator in action until the image is fully loaded.

Conclusion

To sum up, lazy loading background images is a great way to boost your website's performance. With the IntersectionObserver API, you can detect when an element is visible on the screen and load its background image dynamically. Plus, by adding a loading indicator, you can improve the user experience while the image is loading.

If you want more helpful content like this, feel free to follow me:

Lazy load an image

Phuoc Nguyen — Tue, 02 Apr 2024 01:36:50 +0000

Lazy loading images is a smart way to improve website performance. It's a technique that defers the loading of non-critical images until they're needed. By doing this, websites can reduce the initial load time of a webpage, which can have a big impact on user experience and engagement.

Lazy loading only loads images when they're necessary, so websites can minimize the amount of data that needs to be downloaded and processed. This results in faster page load times and better overall performance. Plus, lazy loading can help reduce server load and bandwidth usage, which is especially useful for sites with high traffic volumes or limited resources.

In this post, we'll show you how to lazy load an image using IntersectionObserver.

Introducing the loading attribute

Did you know that modern browsers support lazy loading of images with the loading attribute? This attribute is a relatively new addition to the HTML standard that makes it easy for developers to implement lazy loading without relying on third-party libraries or custom code.

When the loading attribute is added to an <img> tag, it tells the browser to defer loading the image until it's either within the viewport or has been scrolled into view. This can be especially useful for images that are placed below the fold or out of view, as they won't be loaded until they're actually needed.

<img src="..." loading="..." />

The loading attribute has two possible values: lazy and eager. By default, it's set to eager, which means the image will be loaded immediately, potentially slowing down the page. However, if you set it to lazy, the image will only be loaded when it enters the viewport. It's important to note that not all browsers support both values of the loading attribute, so it's a good idea to check for compatibility before using it in production.

To check if the loading attribute is supported in a browser, you can use JavaScript to see if loading is a property of HTMLImageElement.prototype. If it is, you can use the lazy loading technique. Here's an example:

if ('loading' in HTMLImageElement.prototype) {
    // `loading` attribute is supported
} else {
    // `loading` attribute is not supported
    // Use IntersectionObserver or other techniques for lazy loading
}

Take a look at the demo below:

Image credit: 10019, New York, United States by @benobro

The limitations of the loading attribute

While the loading attribute is great for implementing lazy loading on your website, it does have some limitations you should be aware of. One major limitation is that it only works for images, not other assets like videos or iframes. This means you'll need to use a different technique or library if you want to lazy load these assets.

Another limitation is browser support. While most modern browsers support the loading attribute, some older browsers may not recognize it and will simply ignore it. This can affect page performance if the image is loaded as usual.

Lastly, we can't customize the UI when an image is being loaded using the loading attribute. In the next sections, we'll explore how to use IntersectionObserver to replace the loading attribute.

Only loading images when visible

To prevent browsers from loading images automatically, we'll replace the src attribute with a custom data attribute named data-src. Its value is the same as the original src attribute.

Once the image is visible, we'll replace the data-src attribute with the src attribute, asking the browser to load the image as usual.

To achieve this, we'll use a React ref to represent the image element. The reference is then attached to the image via the ref attribute.

const imageRef = React.useRef<HTMLImageElement>(null);

// Render
<img
    ref={imageRef}
    data-src="..."
/>

Next, we'll use IntersectionObserver to keep an eye on the image and detect when it enters or exits the viewport.

In the following code, we're creating a new instance of IntersectionObserver. This observer calls a function when an observed element intersects with the root element or its own bounding box.

React.useEffect(() => {
    const image = imageRef.current;
    if (!image) {
        return;
    }

    const observer = new IntersectionObserver((entries) => {
        entries.forEach((entry) => {
            if (entry.isIntersecting) {
                // The image is visible
                const ele = entry.target;

                observer.unobserve(ele);
                ele.setAttribute('src', ele.getAttribute('data-src'));
                ele.removeAttribute('data-src');
            }
        });
    }, {
        threshold: 0,
    });
    observer.observe(image);

    return (): void => {
        observer.unobserve(image);
    };
}, []);

When an image becomes visible, we swap out the data-src attribute with the src attribute, which tells the browser to load the image as usual. We make sure to avoid loading images multiple times by unobserving the element once it's loaded.

The threshold option sets how much of an element needs to be visible before it's considered "intersecting". We set it to 0 so that even a single pixel of the image being visible will trigger its loading.

Lastly, to prevent memory leaks and improve performance, we detach the observer from the image element using its unobserve() method inside a cleanup function returned by the useEffect hook.

You can check out the live demo below to see it in action.

Enhancing user experience with a loading indicator

To take our user experience to the next level, let's talk about adding a loading indicator that shows up while an image is loading. This lets users know that an image is on its way and helps to prevent frustration or confusion.

To add a loading indicator, we can use CSS to create a spinner animation and then apply it to the image element. The first step is to add a new CSS class to our image element called loading.

<img
    ref={imageRef}
    data-src="..."
    className="loading"
/>

Now, let's define the loading class in our CSS definitions.

.loading {
    display: block;
    width: 100%;
    height: auto;
    background-image: url('/path/to/spinner.svg');
    background-repeat: no-repeat;
    background-position: center center;
}

.loading:not([src])::after {
    content: "";
    display: block;
    width: 100%;
    height: auto;
}

In this example, we've added a spinner SVG as the background image for our loading class. We've set the background-repeat property to no-repeat so that it only displays once and centered it inside the container using background-position.

To make sure the loading indicator always displays, we've added a pseudo-element ::after with content set to an empty string. This is useful when there isn't an existing src attribute (i.e., when data-src is still being used).

With this implementation, a spinner will appear while the image is loading. Once the image is fully loaded, the spinner disappears and the actual image is displayed.

On the other hand, using another external SVG could potentially slow down the page's performance as browsers need to load the file. Additionally, customizing the loading indicator isn't an easy task.

To tackle these issues, we can define an enum with three possible values: NotLoaded, Loading, and Loaded. The NotLoaded value means that the image hasn't been loaded yet. The Loading value indicates that the image is currently being loaded. Lastly, the Loaded value indicates that the image has been fully loaded.

 enum Status {
    NotLoaded,
    Loading,
    Loaded,
}

We add a new status state to manage the loading status of an image. At first, the state is set to NotLoaded.

const [status, setStatus] = React.useState(Status.NotLoaded);

Once the browser finishes loading the image, a function called handleLoadImage() updates the status state to Loaded.

const handleLoadImage = () => {
    setStatus(Status.Loaded);
};

// Render
<img onLoad={handleLoadImage} />

As soon as the image becomes visible, the state changes to Loading. Here's how the status changes with the modification code:

const observer = new IntersectionObserver((entries) => {
    entries.forEach((entry) => {
        if (entry.isIntersecting) {
            const ele = entry.target;
            setStatus(Status.Loading);
        }
    });
}, {
    threshold: 0,
});

When we update the state, it triggers a re-render, which lets us display different content based on whether or not an image has finished loading. For instance, we can show a loading message by checking if the status is set to Loading.

<div className="container">
    {status === Status.Loading && (
        <div className="loading">Loading ...</div>
    )}
</div>

To position the loading indicator, we use CSS to set its position to absolute within a container. This allows the loading indicator to be overlaid on top of the image while it's being loaded.

To get started, make sure that the parent container has a position: relative property set. This allows child elements with absolute positioning to be positioned relative to the parent container. Next, define the .loading class with an absolute position and set its left, top, width, and height properties to cover the entire parent container.

.container {
    position: relative;
}

.loading {
    position: absolute;
    left: 0;
    top: 0;
    height: 100%;
    width: 100%;
}

This implementation positions a loading indicator over an image's parent container while the image loads. Once the image is fully loaded, the indicator disappears and the actual image is displayed.

Check out the demo below and scroll down to the bottom to see the loading indicator in action until the image is fully loaded.

Conclusion

In conclusion, lazy loading images is an excellent way to boost your website's performance by decreasing the amount of data that needs to be loaded upfront. We can use IntersectionObserver to detect when an image is visible and only load it at that point, instead of loading all images when the page first loads.

Furthermore, we can add a loading indicator to give users feedback that an image is on its way and prevent frustration or confusion. By conditionally rendering different content based on whether or not the image has finished loading, we can provide a better user experience.

Overall, implementing lazy loading images with a loading indicator can significantly enhance the performance and user experience of your website.

If you want more helpful content like this, feel free to follow me:

Create a reusable component for IntersectionObserver

Phuoc Nguyen — Mon, 01 Apr 2024 01:42:24 +0000

In our previous post, we learned how to create a custom hook that simplifies the IntersectionObserver API logic. Now, let's explore another approach to reuse this implementation, but in a different way.

As React developers, we know how important it is to create reusable components. It reduces code duplication, improves maintainability, and enhances performance. By creating reusable components, we can easily use them throughout our application and across different projects, ensuring consistency in design and functionality.

Moreover, creating a reusable component for a specific task or feature enables us to update it quickly and efficiently if any changes or improvements are necessary. This saves time and effort compared to having to modify the same code in multiple places.

In this post, we'll create a reusable component for IntersectionObserver using a design pattern called Function as a Child (FAAC). But before we dive into the component implementation, let's explore what the FACC pattern is all about.

Introducing the Function as a Child pattern in React

When working with children props in React, you'll typically come across components or simple strings/numbers. But did you know that the children prop can also be a function?

Enter the Function as a Child (FAAC) pattern. This popular technique in React allows for more dynamic communication between parent and child components. Instead of directly passing down props, the parent component passes down a function as a child. The child component can then call this function with any necessary data, providing more flexibility and interactivity between components.

This pattern is especially useful when the child component needs to interact with its parent in some way. By passing a function as a child, the parent retains control over what data is being passed down, while still allowing the child to manipulate and use that data in a meaningful way.

The Function as a Child pattern is a widely used technique in many libraries and frameworks, including React Router, a popular routing library for React applications. This pattern allows the router to pass its routing information down to its child components, giving them access to the router's state and enabling them to navigate between different routes.

Here is a simple code snippet showing how to use React Router:

<Router>
    <nav>
        <ul>
            <li><Link to="/">Home</Link></li>
            <li><Link to="/about">About</Link></li>
            <li><Link to="/topics">Topics</Link></li>
        </ul>
    </nav>

    <Switch>
        {/* Render some UI here based on the current URL */}
        <Route exact path="/">
        {({ match }) => (
            // Render some UI here if the current URL matches "/"
        )}
        </Route>

        {/* Render some UI here based on the ID parameter */}
        <Route path="/topics/:topicId">
        {({ match }) => (
            // Render some UI here if the current URL matches "/topics/:topicId"
        )}
        </Route>

        {/* Render some UI here for any other URLs */}
        <Route path="/">
        {({ match }) => (
            // Render some UI here if no other routes match
        )}
        </Route>
    </Switch>
</Router>

Here's an example of how React Router passes routing information to its child components using a "Function as a Child". The Route component takes a function as its child, which receives an object containing information on whether the current route matches the specified path. This allows you to conditionally render UI based on the current URL.

Simplifying the IntersectionObserver API with a custom component

In the previous post, we discussed how the custom hook returns an array of two items - a React ref representing the element we want to watch for intersection changes, and a Boolean variable indicating whether the element is visible or not.

Now, we can simplify things even further by turning that custom hook into a component, using the Function as a Child pattern.

Here's a draft of the component implementation:

export const IntersectionWatcher = ({ children }) => {
    const [node, setNode] = React.useState<HTMLElement>(null);
    const [isVisible, setIsVisible] = React.useState(false);

    const ref = React.useCallback((nodeEle) => {
        setNode(nodeEle);
    }, []);

    return children({
        ref,
        isVisible,
    });
};

Our IntersectionWatcher component uses the FAAC pattern to make a highly customizable and reusable IntersectionObserver component. We pass a function as a child that returns an object with two properties: ref and isVisible.

The ref property is a callback that helps us track changes to a specific DOM element. By attaching the ref to the target element through the ref attribute, the callback function will update our internal node state. At first, the node state is set to null.

The isVisible property is a Boolean value indicating whether the observed element is currently visible in the viewport.

To encapsulate the IntersectionObserver API, we continue to use the useEffect hook, just like we did in the custom hook. Here's a quick reminder of the code snippet we used earlier:

export const IntersectionWatcher = ({ children }) => {
    React.useEffect(() => {
        if (!node) {
            return;
        }
        const observer = new IntersectionObserver(([entry]) => {
            setIsVisible(entry.isIntersecting);
        });
        observer.observe(node);

        return () => {
            observer.unobserve(node);
        };
    }, [node]);
};

Using the custom component

Using the IntersectionWatcher component is easy. Simply pass a function as a child that receives an object with two properties: ref and isVisible.

The ref property is a React callback ref that captures the DOM element we want to observe for intersection changes. The isVisible property is a Boolean value that tells us whether or not the observed element is currently visible in the viewport.

<IntersectionWatcher>
{
    ({ ref, isVisible }) => (
        /* Render the target element */
    )
}
</IntersectionWatcher>

In this function, we have the power to render any JSX elements we desire. By using the ref property, we can easily attach the intersection observer to any element that we wish to monitor for intersection changes via the ref attribute.

({ ref, isVisible }) => (
    <div className="element" ref={ref}>...</div>
)

We can use the isVisible property to show or hide UI elements based on whether or not they are currently visible in the viewport.

Here's an example:

({ ref, isVisible }) => (
    <div className="result">
        {isVisible ? 'Element is partially visible' : 'Element is not partially visible'}
    </div>
)

Check out the demo below. Just scroll up and down to see the message update automatically, telling you whether the target element is partially visible or not.

Taking component customization further

Our component can now detect whether an element is partially visible in the viewport. But what if we want to know if it's fully visible, as we did before? In our previous post, we achieved this by setting the threshold value to an array of 1.

const observer = new IntersectionObserver(([entry]) => {
    setIsVisible(entry.isIntersecting);
}, {
    threshold: [1],
});

To support the threshold value, we can make some changes to our IntersectionWatcher component. First, we'll add a new property called threshold. This property will take an array of numbers between 0 and 1, which will specify the percentage of the target's visibility at which the observer's callback should be executed.

Next, we'll pass this threshold value as an option to the IntersectionObserver constructor. In the updated implementation, we'll pass a second argument to IntersectionObserver that contains our threshold value as an options object.

Here's the updated version of the IntersectionWatcher component:

export const IntersectionWatcher = ({ children, threshold }) => {
    React.useEffect(() => {
        const observer = new IntersectionObserver(([entry]) => {
            setIsVisible(entry.isIntersecting);
        }, { threshold });
        // ...
    }, [node]);
};

By default, the threshold value is set to [0], which means that the callback function is called as soon as the target element intersects with the root element.

But, if you pass an array of values between 0 and 1 as the threshold prop when using IntersectionWatcher, you can customize when the callback function should be called based on how much of the target element is visible in the viewport. For example, a threshold value of [0.5] would call the callback function when at least 50% of the target element is visible.

Here's an example of how to use IntersectionWatcher with a custom threshold value:

<IntersectionWatcher threshold={[0.5]}>
{({ ref, isVisible }) => (
    <div ref={ref}>
        {isVisible ? 'At least 50% visible' : 'Less than 50% visible'}
    </div>
)}
</IntersectionWatcher>

To determine if an element is fully visible on the screen, we can set a threshold value of [1]. This ensures that the element is completely visible before taking any action.

By allowing for custom threshold values, our IntersectionObserver component becomes even more versatile and useful across a variety of use cases.

Give it a try by scrolling up and down in the playground below to see how this updated implementation works.

Conclusion

To wrap it up, the IntersectionObserver API is a handy tool that lets us know when a target element intersects with another element or the viewport. If we encapsulate this functionality in a custom hook or component, we can create solutions that are highly reusable and customizable for different scenarios.

With the help of React's hooks and Function as a child pattern, we can create components that are flexible and easy to use. Our IntersectionWatcher component is a good example of how these patterns can be used to build powerful and reusable code.

Create a reusable hook for IntersectionObserver

Phuoc Nguyen — Fri, 29 Mar 2024 05:00:34 +0000

In our previous post, we learned how to use the useEffect hook to integrate IntersectionObserver with React. But what if we want to use this implementation in other places? It's always a good idea to turn it into a reusable function that we can use in different components and projects.

Creating a reusable hook can save us a lot of time and effort. Instead of writing the same code multiple times, we can abstract it into a single function that can be used across different projects. This not only saves us time but also makes our code more organized and easier to maintain.

Moreover, creating a reusable hook allows us to share our code with the community. We can publish our hooks as NPM packages, which other developers can use in their own projects. This promotes code reuse and helps to build a stronger React ecosystem.

In this post, we'll learn how to create a custom hook that encapsulates the IntersectionObserver API logic. Let's dive in!

Simplifying the IntersectionObserver API with a custom hook

In the previous post, we introduced an implementation that uses a React ref to represent an element and a Boolean state to indicate whether the element is partially visible or not.

To make this implementation reusable, we created a useIntersectionObserver hook that encapsulates the IntersectionObserver logic. This custom hook returns an array containing two elements: ref and isVisible.

The ref element is a callback function that receives the DOM node as its argument. We attach this ref to the component's root element, which we want to observe for intersection. Once the ref is attached to the target element via the ref attribute, the callback will be executed to update our internal node state. Initially, the node state is set to null.

The second element returned by this hook is a Boolean value indicating if the observed element is currently intersecting with the viewport.

Here's how we can draft the hook implementation.

export const useIntersectionObserver = () => {
    const [node, setNode] = React.useState<HTMLElement>(null);
    const [isVisible, setIsVisible] = React.useState(false);

    const ref = React.useCallback((nodeEle) => {
        setNode(nodeEle);
    }, []);

    return [ref, isVisible];
};

To track changes in a node's intersection, we can use the useEffect() hook. This hook has two arguments: a callback function and an array of dependencies. In our case, we only need to run the effect when the node element exists, so we pass [node] as the second argument.

Inside the callback function, we first check if the node exists. If it does, we create a new instance of IntersectionObserver and pass it a callback that gets called every time there is an intersection change. The callback receives an array of IntersectionObserverEntry objects, but since we are only observing one element, we can safely assume that this array will always have only one element.

We then update our internal state with the current value of entry.isIntersecting, which tells us whether or not the observed element is currently intersecting with the viewport.

Finally, we return a cleanup function that stops observing the node when it's no longer needed. This ensures that we don't waste resources by observing elements that are no longer in use.

Here's the updated version of the hook for your reference:

export const useIntersectionObserver = () => {
    React.useEffect(() => {
        if (!node) {
            return;
        }
        const observer = new IntersectionObserver(([entry]) => {
            setIsVisible(entry.isIntersecting);
        });
        observer.observe(node);

        return () => {
            observer.unobserve(node);
        };
    }, [node]);

    return [ref, isVisible];
};

Using the custom hook

To use the useIntersectionObserver hook, we start by importing it into our component. Once imported, we simply call the hook and destructure its return values into variables.

import { useIntersectionObserver } from './useIntersectionObserver';

const [elementRef, isVisible] = useIntersectionObserver();

The first variable is a ref callback function that we pass to the element we want to observe for intersection. This is done using the ref attribute in JSX.

// Render
<div className="element" ref={elementRef}>
    ...
</div>

The second variable is a simple true or false value that tells us if the element is currently visible on the screen or not. We can use this value to show or hide content or take other actions based on whether or not an element is visible to the user.

// Render
<div className="result">
    {isVisible ? 'Element is partially visible' : 'Element is not partially visible'}
</div>

Take a look at the demo below. Simply scroll up and down to see the message update automatically, informing you whether or not the target element is partially visible.

Customizing the hook further

Now that our hook can detect whether an element is partially visible in the viewport, what if we want to know if it's fully visible, like we did before? In our previous post, we achieved this by setting the threshold value to an array of 1.

const observer = new IntersectionObserver(([entry]) => {
    setIsVisible(entry.isIntersecting);
}, {
    threshold: [1],
});

To support the threshold value, let's modify our useIntersectionObserver hook. We can add a new parameter called threshold that takes an array of numbers between 0 and 1. This array specifies the percentage of the target's visibility at which the observer's callback should be executed.

Next, we pass this threshold value as an option to the IntersectionObserver constructor. In the updated implementation, we pass a second argument to IntersectionObserver with an options object containing our threshold value.

export const useIntersectionObserver = ({
    threshold,
}: {
    threshold: number[],
}) => {
    React.useEffect(() => {
        const observer = new IntersectionObserver(([entry]) => {
            setIsVisible(entry.isIntersecting);
        }, {
            threshold,
        });

        // ...
    }, [node]);
};

Now, when we call our custom hook, we can pass in a threshold value as an argument. For instance, if we want to find out if an element is completely visible on the screen, we can set a threshold value of [1]. This will help us ensure that our element is fully visible before taking any action.

const [elementRef, isVisible] = useIntersectionObserver({
    threshold: [1],
});

Our custom hook just got even more flexible and reusable! We added support for the threshold parameter, making it suitable for various intersection detection scenarios.

Give it a go by scrolling up and down in the playground below to see how this updated implementation works.

Conclusion

In conclusion, we have learned how to make a reusable hook for IntersectionObserver in React. By putting the IntersectionObserver logic in a custom hook, we can easily use it across different components and projects. We also learned how to make this hook even more customizable by adding support for the threshold parameter.

Creating custom hooks is just one of the many ways we can make our code more modular and easier to maintain. It allows us to take complex logic and turn it into reusable building blocks that can be shared with other developers.

Use the IntersectionObserver API in React

Phuoc Nguyen — Thu, 28 Mar 2024 01:42:33 +0000

In our previous post, we covered the basics of the IntersectionObserver API, including its syntax and common methods. The good news is that we don't need to rely on any external libraries to use this API with React. By using the built-in React hooks, we can handle all the intersection observer functionality with ease.

In this post, we'll dive into how to use the IntersectionObserver API in React.

Checking if an element is partially visible

When working with React, it's not recommended to use DOM manipulation methods like querySelector and querySelectorAll to retrieve elements. Instead, we can use the useRef hook.

If you're new to useRef, I recommend checking out this series which covers basic and advanced usage of React refs with real-world examples.

To start, we create a ref using the useRef hook to reference the specific DOM element we want to observe for visibility changes. We attach the target element to the ref using the ref attribute.

Then, we set up a state variable called isVisible using the useState hook with an initial value of false.

const elementRef = React.useRef();
const [isVisible, setIsVisible] = React.useState(false);

// Render
return (
    <div ref={elementRef}>...</div>
);

Next, we're going to use the useEffect hook to set up an IntersectionObserver. This is a browser API that lets us know when an element becomes visible or hidden on the page. But before we can use the API, we need to get the element we want to observe.

To do this, we used the useRef hook to create a reference to the element. Then, we access the current property of the reference to get the actual element.

Once we have the element, we create an observer instance using the IntersectionObserver constructor. We pass in a callback function that will be called whenever the element intersects with the viewport.

The callback function receives an array of entries, but we only care about the first one. So, we use array destructuring to get it. This entry object contains information about whether or not the element is currently visible.

If the element is visible, we set our isVisible state variable to true. If it's not visible, we set isVisible to false. Finally, we call the observer's observe method with our target element.

To clean up after ourselves, we return a function from the useEffect hook that calls the observer's unobserve method on our target element. This ensures that when our component unmounts or the element is removed from the page, we stop observing it.

Here's an example of how to use the useEffect hook to set up an IntersectionObserver.

React.useEffect(() => {
    const ele = elementRef.current;
    if (!ele) {
        return;
    }

    const observer = new IntersectionObserver(([entry]) => {
        setIsVisible(entry.isIntersecting);
    });
    observer.observe(ele);

    return () => {
        observer.unobserve(ele);
    };
}, []);

Lastly, we create a div element that shows whether or not the observed element is partially visible.

// Render
return (
    <div>
        {isVisible ? 'Element is partially visible' : 'Element is not partially visible'}
    </div>
);

Check out the demo below. Scroll up and down to see how the message updates automatically, letting you know if the target element is visible or not.

Checking if an element is fully visible

To ensure that an element is fully visible, we can update our implementation using the intersectionRatio property of the entry object passed to the IntersectionObserver's callback function.

The intersectionRatio property is a value between 0 and 1 that represents the percentage of the targeted element that is currently visible within the viewport. If this value is equal to 1, then the entire element is visible.

To achieve this, we can modify our existing code by checking whether entry.intersectionRatio is equal to 1 or not. If it's equal to 1, then we can set our state variable isVisible to true, indicating that the element is fully visible. Otherwise, we set it to false.

Here's an example implementation:

React.useEffect(() => {
    const ele = elementRef.current;
    if (!ele) {
        return;
    }

    const observer = new IntersectionObserver(([entry]) => {
        setIsVisible(entry.intersectionRatio === 1);
    });
    observer.observe(ele);

    return () => {
        observer.unobserve(ele);
    };
}, []);

Although it may seem promising and workable in theory, in practice, it falls short. Go ahead and try scrolling down in the playground below. You'll notice that the message doesn't update even if you scroll over the entire element.

The reason why the approach to check if an element is fully visible doesn't work is because intersectionRatio only considers when the element is partially or not visible at all.

We can fix this issue by adding an extra option to the IntersectionObserver constructor. This option is called threshold, and it lets us specify at what percentage of visibility we want our callback function to be executed.

To make sure our callback function is called when the observed element is fully visible, we can set the threshold value to 1. This means that our callback function will only be executed when the entire observed element is visible in the viewport.

It's worth noting that the threshold option can also accept an array of numbers. Here's how we can modify our existing code to implement this solution:

React.useEffect(() => {
    const ele = elementRef.current;
    if (!ele) {
        return;
    }

    const observer = new IntersectionObserver(([entry]) => {
        setIsVisible(entry.isIntersecting);
    }, {
        threshold: 1,
    });
    observer.observe(ele);

    return () => {
        observer.unobserve(ele);
    };
}, []);

With this modification, the isVisible state variable now accurately shows whether or not the observed element is fully visible. Give it a try by scrolling up and down in the playground below to see how this updated implementation works.

Conclusion

In this post, we learned how to use the IntersectionObserver API with React. By encapsulating all the intersection observer functionality within the useEffect hook, we were able to check if an element is partially or fully visible using different threshold values.

Using the IntersectionObserver API can significantly improve an application's performance by reducing the number of calculations required to determine visibility changes. In our next post, we'll take it a step further and learn how to turn the implementation into a reusable hook and component.

If you want more helpful content like this, feel free to follow me:

An introduction to the IntersectionObserver API

Phuoc Nguyen — Wed, 27 Mar 2024 01:36:34 +0000

In our previous post, we discussed a few ways to check if an element is visible. We checked if it was within the window or its scrollable container, and even used the scroll event to track its visibility as users scrolled.

However, these methods had some drawbacks. In this post, we'll introduce a modern and efficient way to achieve the same functionality: the IntersectionObserver API.

This powerful tool allows developers to detect when an element enters or exits the viewport with ease. It's critical for optimizing website performance, as it enables lazy loading of images and other assets only when they're needed. This reduces page load times and improves the overall user experience.

Why you should use the IntersectionObserver API

The IntersectionObserver API is a game changer for web developers. It provides a simple and efficient way to implement lazy loading and other performance optimizations that can significantly reduce load times and improve the overall user experience.

In this series, we'll explore practical examples of how to use IntersectionObserver in the real world. By minimizing the amount of data that is loaded on a page, you can make your website faster and more efficient.

But that's not all. IntersectionObserver is highly customizable and can trigger a wide range of actions based on the intersection of an element with the viewport. This allows developers to create highly dynamic and interactive webpages that are tailored to the specific needs of their users.

IntersectionObserver browser compatibility

Good news! Most modern browsers support IntersectionObserver. According to caniuse.com, as of the time of writing, all major desktop browsers, including Chrome, Firefox, Safari, Edge, and Opera, support IntersectionObserver. On mobile devices, iOS Safari supports IntersectionObserver from version 12.2 onwards, while Android Chrome has supported it since version 51.

However, if you need to support older browsers like Internet Explorer or Safari 11 and below, you'll need to use a polyfill like intersection-observer. This polyfill provides the same functionality as the native API and can be easily installed via npm or included in your project through a CDN.

It's always a good idea to check the compatibility of any new feature or API before using it in production. You can use websites like caniuse.com or MDN web docs to learn more about browser compatibility and implementation details.

Understanding the IntersectionObserver API syntax

The IntersectionObserver API works by creating an observer object that is tied to a specific element on the page. This observer watches for changes in the intersection of the target element with the viewport and triggers a callback function whenever a change is detected.

Developers can use the callback function to perform a variety of actions, such as loading additional content, animating an element, or updating a progress bar. This allows for a seamless and engaging user experience.

To create an observer, we use the IntersectionObserver constructor. This constructor requires two arguments: a callback function and an options object. The callback function is called each time the target element intersects with the root element or with itself. The options object lets us specify additional configurations for the observer, such as the root element to observe and the threshold at which to trigger the callback.

Here's an example of how to create a new IntersectionObserver:

const observer = new IntersectionObserver(callbackFunction, optionsObject);

After creating our observer object, we can observe elements on our page by using the observe() method and passing the target element as an argument. Here's an example:

const targetElement = document.querySelector('#my-element');
observer.observe(targetElement);

This code will tell the observer to watch for any changes in the intersection of #my-element. When a change is detected, our callbackFunction will be triggered with information about the intersection ratio between the target element and its root element, as well as the visibility of the target element.

The options object in IntersectionObserver

When using the IntersectionObserver constructor, you can pass in an options object to configure the observer. The options object has several properties that can be set:

root specifies the element that serves as the viewport for checking the visibility of the target element. By default, this is set to the browser window.
rootMargin allows you to specify a margin around the root element, effectively expanding or shrinking its dimensions. This is useful when you want to detect when an element enters or exits a certain area around the viewport.
threshold sets a single number or an array of numbers between 0 and 1 that determine when the observer triggers a callback. For example, if we set threshold: 0.5, then our callback function will be called whenever at least half of the target element is visible in the viewport.

Here's an example of how you can create an observer with custom options:

const options = {
    root: null,
    rootMargin: '0px',
    threshold: [0, 0.25, 0.5, 0.75, 1],
};

const observer = new IntersectionObserver(callbackFunction, options);

This observer will trigger our callback function at five different thresholds - when the target element enters and exits full view (threshold: 1 and threshold:0), as well as at quarter (threshold: 0.25), half (threshold: 0.5) and three quarters (threshold: 0.75) visibility in relation to its parent container.

The root property

The root property is a powerful option of IntersectionObserver that allows you to specify which element should be used as the viewport for checking the visibility of a target element. By default, if no value is set for root, it will use the browser window.

Let's say we have a div with a class of .section containing a lot of images and content that we want to lazy load as the user scrolls down the page. However, we only want to start loading this content when it enters into view within another specific div with a class of .container.

To achieve this, we can create an observer with a custom root element. Here's how it works:

const observer = new IntersectionObserver(callbackFunction, {
    root: document.querySelector('.container'),
});

By specifying .container as the viewport instead of the browser window, the observer will only trigger our callback function once our target elements inside .section enter into .container. This optimization technique helps us to load only what is necessary at any given moment and avoid overloading resources unnecessarily.

The rootMargin property

The rootMargin property in the options object of an IntersectionObserver lets you set a margin around the root element. This is super useful when you want to detect when an element enters or exits a certain area around the viewport.

For instance, let's say we have a hero section that fills the entire screen, and we want to trigger an animation when the user scrolls down 50 pixels from the top of this section. We can make it happen by creating an observer with a rootMargin value of -50px.

const observer = new IntersectionObserver(callbackFunction, {
    rootMargin: '-50px',
});

Now, whenever the element we want to target intersects with the viewport within 50 pixels of its edge, our callback function will be triggered.

The rootMargin value is set as a string and can contain up to four space-separated values representing the top, right, bottom, and left margins, respectively. Here's an example:

const observer = new IntersectionObserver(callbackFunction, {
    rootMargin: '20px 0px -50px 10px',
});

In this example, we set some margins for our root element. We created a margin of 20 pixels on the top, no margin on the right, a margin of -50 pixels on the bottom, and a margin of 10 pixels on the left.

If we use negative values for rootMargin, we can actually shrink the size of our viewport area. This is handy when we want to detect elements that are only partially visible at the edge of our viewport.

It's important to note that if you don't set any value for rootMargin, it will default to 0px. So if you don't need any extra margin around your root element, you can just skip this option.

Understanding the callback function

The callback function is the heart of the IntersectionObserver API. It is what makes everything work. It is passed as the first argument to the IntersectionObserver constructor, and it gets called every time the target element intersects with the root element or with itself, as specified in the observer's options object.

When our target element is visible in the viewport, the callback function gets triggered, allowing us to perform a variety of actions such as loading additional content, animating an element, or updating a progress bar.

The callback function takes two arguments: an array of IntersectionObserverEntry objects and a reference to the observer itself. The IntersectionObserverEntry object contains information about the intersection between the target element and its root element, including properties such as isIntersecting, intersectionRatio, and boundingClientRect.

Here's an example of a basic callback function:

const callbackFunction = (entries, observer) => {
    entries.forEach((entry) => {
        if (entry.isIntersecting) {
            // Do something when target element enters viewport
        } else {
            // Do something when target element exits viewport
        }
    });
};

In this example, we use an arrow function to go through each entry in the entries array. We check if each entry is intersecting or not by using its isIntersecting property. If it is, we can do things like loading extra content or animating an element.

Keep in mind that we may be observing multiple elements at once with just one observer. This means our callback function will be called for each observed element whenever their intersection status changes. Therefore, we need to check which element specifically triggered our callback before doing anything to it.

Understanding the IntersectionObserverEntry object

The IntersectionObserverEntry object is a treasure trove of information about the intersection between our target element and its root element. It provides us with several properties that are essential for retrieving this information:

boundingClientRect gives us the position and dimensions of our target element relative to its parent container.
intersectionRatio provides us with the ratio of intersection area to the bounding box area of either the target or root element.
intersectionRect gives us the rectangle that describes the area of intersection between our target and root elements.
isIntersecting is a simple boolean value indicating whether or not our target element is intersecting with our root element.
rootBounds provides us with the position and dimensions of our root element relative to its parent container.

These properties are incredibly useful for a variety of calculations and checks when observing our elements. For example, we can use them to calculate how much of an image is visible in relation to its parent container, or to check if an element has fully entered or exited a specific viewport.

Here's an example of how we can use these properties:

const callbackFunction = (entries, observer) => {
    entries.forEach((entry) => {
        if (entry.isIntersecting) {
            console.log(`Element ${entry.target.id} is ${entry.intersectionRatio * 100}% visible`);
        } else {
            console.log(`Element ${entry.target.id} is not visible`);
        }
    });
};

In this example, we're using the intersectionRatio property to figure out how much of each element we're observing is currently visible within its parent container. This helps us perform certain actions, like loading more content or animating an element.

Disconnecting the observer

After we're done watching an element, we can disconnect the observer by calling its disconnect() method. This will stop the observer from monitoring any further changes to the target element.

Here's an example of how to disconnect an observer:

const targetElement = document.querySelector('#my-element');
observer.observe(targetElement);

// Some time later ...
observer.disconnect();

To prevent the observer from watching for changes in the intersection of #my-element, simply disconnect it. It's important to keep in mind that once an observer is disconnected, it can't be used again. So, if you need to start watching a new element, you'll have to create a new observer object.

Disconnecting the observer when it's no longer needed is a good practice to follow. It helps conserve system resources and ensures that your code runs efficiently.

Conclusion

In conclusion, the IntersectionObserver API is a game-changer for web developers who want to boost performance and enhance user experience. By detecting when elements enter or exit the viewport, we can load content lazily, animate elements on scroll, and perform other actions that speed up websites and make them more efficient.

Thanks to its customizable options and callback function, the IntersectionObserver API gives developers the flexibility they need to monitor multiple elements at once and respond to changes in their intersection status. Plus, using properties like root, rootMargin, threshold, and IntersectionObserverEntry, we can tailor our observers to fit specific use cases and get even better results.

Overall, if you're serious about creating a website that's more responsive, loads content faster, and runs more efficiently, then mastering the IntersectionObserver API is a must. With its ability to track element visibility on-the-fly, this API has become an essential part of modern web development practices.

If you want more helpful content like this, feel free to follow me:

Check if an element is visible in the viewport

Phuoc Nguyen — Tue, 26 Mar 2024 01:50:42 +0000

Knowing how to check if an element is visible in the viewport is incredibly useful in web development. Here are some real-life examples where this knowledge can come in handy:

Infinite scrolling: Websites that use infinite scrolling need to constantly check if new content is visible in the viewport to load more content.
Analytics: By tracking how long users spend looking at specific elements on a page, you can gain valuable insights into what's working and what's not.
Animations: When using animations, you'll want to make sure that elements are only animated when they're visible in the viewport. This helps improve website performance and ensures your animations look smooth and polished.

By understanding how to check if an element is visible in the viewport, you can create more dynamic and engaging websites that provide a better user experience.

Before diving into the IntersectionObserver API, there are a few approaches you can take to determine if an element is visible in the viewport. In this post, we'll explore some of them.

Checking if an element is visible in the window

If you're wondering how to check if an element is visible in the viewport, one way to do it is by using the element's getBoundingClientRect() method. This method gives you the size of the element and its position relative to the viewport. By comparing these values to the viewport's position and dimensions, you can easily determine whether the element is visible or not.

To help you out, here's an example function that uses the getBoundingClientRect() method:

const isElementVisible = (ele) => {
    const rect = ele.getBoundingClientRect();
    return (
        rect.top >= 0 &&
        rect.left >= 0 &&
        rect.bottom <= (window.innerHeight || document.documentElement.clientHeight) &&
        rect.right <= (window.innerWidth || document.documentElement.clientWidth)
    );
};

The isElementVisible function checks if an element is visible in the viewport. First, it gets the element's size and position relative to the viewport using the getBoundingClientRect() method. Then, it checks if all four sides of the element are within the bounds of the viewport.

To be visible, the element's top and left sides must be greater than or equal to zero. Additionally, the element's bottom and right sides must be less than or equal to either window.innerHeight or document.documentElement.clientHeight for height, and window.innerWidth or document.documentElement.clientWidth for width.

If all four sides of the element are visible in the viewport, isElementVisible returns true. Otherwise, it returns false.

Checking if an element is visible within a scrollable container

With a slight modification to the isElementVisible function, we can now determine if an element is visible within a scrollable container.

const isElementVisibleInContainer = (ele, container) => {
    const rect = ele.getBoundingClientRect();
    const containerRect = container.getBoundingClientRect();
    return (
        rect.top >= containerRect.top &&
        rect.left >= containerRect.left &&
        rect.bottom <= containerRect.bottom &&
        rect.right <= containerRect.right
    );
};

To determine if an element is visible within a scrollable container, the getBoundingClientRect() method is used to get the size and position of both the element and the container. Then, it checks if all four sides of the element are within the bounds of the container.

For an element to be considered visible in a scrollable container, its top and left sides must be greater than or equal to the container's top and left sides. In addition, its bottom and right sides must be less than or equal to the container's bottom and right sides.

Give it a try by scrolling up and down the playground below to see how it works.

Checking if an element is partially visible in a scrollable container

We can improve the isElementVisibleInContainer function by modifying it to check if an element is partially visible within a container. This modification can be useful when you want to trigger specific actions when an element becomes partially visible.

Here's the updated function:

const isElementPartiallyVisibleInContainer = (ele, container) => {
    const rect = ele.getBoundingClientRect();
    const containerRect = container.getBoundingClientRect();

    const topIsVisible = rect.top >= containerRect.top && rect.top < containerRect.bottom;
    const bottomIsVisible = rect.bottom > containerRect.top && rect.bottom <= containerRect.bottom;
    const leftIsVisible = rect.left >= containerRect.left && rect.left < containerRect.right;
    const rightIsVisible = rect.right > containerRect.left && rect.right <= containerRect.right;

    return (topIsVisible || bottomIsVisible) && (leftIsVisible || rightIsVisible);
};

The isElementPartiallyVisibleInContainer function is similar to the isElementVisibleInContainer function, but with a twist. Instead of checking if all four sides of the element are within the container, it only checks if any side of the element is within the container.

To find out if an element is partially visible in a scrollable container, we compare each side of the element to each side of the scrollable area. If any part of the element overlaps with any part of the scrollable area, we say it's partially visible.

Give it a try by scrolling up and down on the following playground to see how it works.

Using the scrollY and innerHeight properties

Another way to check if an element is visible in the viewport is by comparing the element's position with the current scroll position and viewport height. This approach is similar to the first method, but it doesn't require calling getBoundingClientRect().

Here's an example function that uses this method:

const isElementVisible = (ele) => {
    const scrollTop = window.scrollY;
    const windowHeight = window.innerHeight;
    const eleTop = ele.offsetTop;
    const eleHeight = ele.offsetHeight;

    return (
        eleTop - scrollTop < windowHeight &&
        eleTop + eleHeight > scrollTop
    );
}

First, the isElementVisible function retrieves the current scroll position of the window using window.scrollY, and the height of the viewport using window.innerHeight. It then obtains the top position of the element relative to its offset parent using el.offsetTop, as well as its height using el.offsetHeight.

The function returns a boolean value, indicating whether any part of the element is visible within the bounds of the viewport. Specifically, it checks if either (1) any part of the top edge of the element is above or at the top edge of the viewport AND any part of its bottom edge is below or at the bottom edge of it OR (2) all parts of its edges are inside or partially inside both edges of the viewport. If either condition is met, then the function returns true; otherwise, it returns false.

You can also modify the isElementVisible function to check if an element is partially visible within a scrollable container. This modification can be useful when you want to trigger specific actions when an element becomes partially visible.

Here is an updated version of the function:

const isElementPartiallyVisibleInContainer = (ele, container) => {
    const scrollTop = container.scrollTop;
    const containerHeight = container.offsetHeight;
    const eleTop = ele.offsetTop - container.offsetTop;
    const eleHeight = ele.offsetHeight;

    return (
        eleTop + eleHeight > scrollTop &&
        eleTop < scrollTop + containerHeight
    );
}

First, we get the current position of the scrollable container using scrollTop. Then, we calculate how much space is available in that container using offsetHeight. Next, we get the position of our target element relative to its parent using offsetTop and subtract that from container.offsetTop to get our target's position relative to its parent. Finally, we check if any part of our target is visible in its parent by comparing its top and bottom positions with those of its parent.

Try it out for yourself by scrolling up and down in the playground below.

Checking element visibility while users scroll

In web development, it's common to need to check if an element is visible to the user as they scroll down a page. One straightforward way to do this is to handle the scroll event. This involves listening for the scroll event on either the window object or the container element, and then checking if the element is currently visible within the viewport or its scrollable container.

To give you an idea of how this works, here's an example function that implements this approach:

const handleScroll = () => {
    const isVisble = isElementPartiallyVisibleInContainer(ele, container);
};

React.useEffect(() => {
    container.addEventListener('scroll', handleScroll);

    return () => {
        container.removeEventListener('scroll', handleScroll);
    };
}, []);

The drawbacks of using the scroll event to check element visibility

Although using the scroll event to determine element visibility is a viable approach, it has some limitations that you should be aware of.

Firstly, this method can be resource-intensive and can negatively impact page performance, especially if you're checking many elements or if the container being scrolled is large. This is due to the scroll event firing many times per second during scrolling, and each time it fires, you are performing calculations on all elements that need to be checked for visibility.

Secondly, when using this method, there may be instances where an element appears visible in the viewport but is not actually within view due to overlapping elements or other layout issues. For example, an element may be partially obscured by another element or only visible for a brief moment during scrolling.

Lastly, if you have multiple containers that can be scrolled independently (e.g., nested scrollable areas), this method might not work correctly since the calculation of elementTop and containerTop will depend on which container is currently being scrolled.

Overall, while using the scroll event to check element visibility can be useful in certain situations, it's important to keep its limitations in mind and use it judiciously to avoid impacting page performance.

Conclusion

To determine if an element is visible on a webpage, there are a few different methods you can use. The most straightforward approach is to use the getBoundingClientRect() method to check if all four sides of the element are within the viewport or container. Another way is to compare the element's position with the current scroll position and viewport height using scrollY and innerHeight. You can even modify these functions to check if an element is fully or partially visible within a scrollable container.

While using the scroll event to check element visibility can be helpful in some cases, it's important to be mindful of its limitations and use it wisely to avoid negatively impacting page performance. In this series, we'll explore how to achieve similar functionality with the IntersectionObserver API.

If you want more helpful content like this, feel free to follow me:

Practical examples of using IntersectionObserver with React

Phuoc Nguyen — Sat, 23 Mar 2024 09:24:17 +0000

Are you tired of endlessly scrolling through content only to find that the images and videos you wanted to see never even loaded? Do you want to boost your React app's performance by only rendering the content that's actually visible to your users? If so, you're in the right place!

In this series, we'll explore the power of the IntersectionObserver API and how it can be used to create fast and responsive React apps. Through practical examples, you'll learn how to use IntersectionObserver to lazy load images, videos, and other content. You'll also learn how to dynamically render components based on their visibility in the viewport.

By the end of this series, you'll have a solid understanding of how to use IntersectionObserver to improve your React app's performance and user experience. So why wait? Let's dive in!

If you want more helpful content like this, feel free to follow me:

Clipboard API fallback

Phuoc Nguyen — Thu, 21 Mar 2024 02:08:01 +0000

In our previous post, we learned how to use feature detection to check if the Clipboard API is supported. However, in cases where it isn't supported, we can use a fallback. One of the alternatives is the document.execCommand method.

To use document.execCommand as a fallback when the Clipboard API is not supported, here's an example:

if (navigator.clipboard) {
    // Clipboard API is supported
} else {
    // Clipboard API is not supported
    document.execCommand('copy');
}

Understanding document.execCommand method

The document.execCommand method is a method that developers can use to manipulate clipboard content. This method has been around since the early days of web development and is built into all modern browsers.

The document.execCommand method takes two arguments: a command identifier and a Boolean value that determines whether to show UI for the command. Here's an example:

document.execCommand('copy', false);

Here are some common commands you might encounter while using text editors:

copy: copies the selected text to the clipboard.
cut: cuts the selected text and stores it in the clipboard.
paste: pastes the content from clipboard to the current cursor position.
bold: makes selected text bold.
italic: makes selected text italic.

Want to see how these commands work in action? Check out this example that demonstrates using the execCommand method to copy text to the clipboard.

const writeToClipboard = (text) => {
    const textArea = document.createElement("textarea");
    textArea.value = text;

    // Styling to hide the textarea
    textArea.style.position = "fixed";
    textArea.style.top = "-9999px";
    textArea.style.left = "-9999px";

    document.body.appendChild(textArea);
    textArea.focus();
    textArea.select();

    try {
        const successful = document.execCommand("copy");
        const message = successful ? "successful" : "unsuccessful";
        console.log(`Copying text was ${message}`);
    } catch (error) {
        console.error("Unable to copy to clipboard", error);
    }

    document.body.removeChild(textArea);
};

The writeToClipboard function in the code above is a custom function that copies text to your clipboard.

First, the function creates a new text area element using the document.createElement method. The text to be copied is set as the value of this element.

Next, the function applies styling to hide the text area from view by setting its position to fixed and its top and left values to -9999px. This ensures that the text area is not visible on the screen but can still be accessed.

The newly created text area element is then added to the document body using document.body.appendChild(textArea).

The function then calls the focus method on the text area and selects all of its content using the select method.

Finally, the document.execCommand('copy') method is called, which copies the selected text to your clipboard. Any errors are caught by a try-catch block, and if there are no errors, the function removes the temporary text area from the document using document.body.removeChild(textArea).

Comparing document.execCommand and Clipboard API

When it comes to copying and pasting data, it's important to choose the right tool for the job. While both document.execCommand and the Clipboard API can be used for this purpose, they have some key differences that are worth noting.

One of the most significant differences is that document.execCommand is a synchronous method, meaning it can cause performance issues and slower page load times. On the other hand, the Clipboard API is asynchronous, which makes it a better choice for handling large or complex data sets.

Security is another important consideration. document.execCommand requires elevated permissions to execute certain commands, which can make it more difficult to use in some contexts - especially on mobile devices where users are less likely to grant permission for elevated access. The Clipboard API, on the other hand, provides a more secure way to access and modify clipboard data by requiring explicit user permission.

While document.execCommand may still be useful as a fallback option in some cases, developers should prioritize using the Clipboard API whenever possible due to its improved performance and security features.

Copying vs cutting text

Copying and cutting text are two common tasks that developers need to perform when building web applications. While both document.execCommand('copy') and the Clipboard API can be used to copy text, only document.execCommand can be used to cut text.

Cutting text is similar to copying text, but instead of copying the selected text to the clipboard, it removes it from the document and saves it to the clipboard. This can be useful when a user wants to move some selected text to a different location within a document or application.

However, it's important to note that just like copying text using document.execCommand, there are security concerns with cutting text as well. In some browsers, the method can only be executed as a result of a user action such as a click event.

On the other hand, the Clipboard API does not provide an explicit method for cutting text. Instead, developers need to use other methods such as manipulating the DOM or using JavaScript's string manipulation functions to remove and store selected text before adding it back in at a later time.

Ultimately, developers should consider their specific use case and browser compatibility requirements when deciding which method to use. While both methods have their pros and cons when it comes to copying and cutting text, it's important to choose the one that fits the situation best.

Security concerns with document.execCommand

One of the major drawbacks of using document.execCommand is its security concerns. As we mentioned earlier, executing commands such as "cut" or "paste" requires elevated permissions, which can pose a risk to users' security.

Moreover, some web browsers may block the execution of certain commands for security reasons. For instance, the "paste" command may be disabled on some particular devices due to concerns about sensitive data being pasted unintentionally.

To mitigate these risks, developers must use document.execCommand responsibly and only execute commands when necessary. They should also avoid using this method for sensitive operations such as copying or cutting passwords or other confidential information.

Overall, while document.execCommand can be a useful fallback option in some cases where the Clipboard API is not supported, developers should be aware of its potential security vulnerabilities and use it with caution.

Conclusion

In conclusion, while the document.execCommand method can be used as a fallback for the Clipboard API, there are several limitations that make it less desirable compared to the Clipboard API.

Firstly, the document.execCommand method is no longer recommended to use because it is deprecated. Secondly, the Clipboard API provides a more secure and reliable way to interact with clipboard content. It is also asynchronous, which prevents blocking of the main thread, and requires explicit user permission before accessing or modifying clipboard data.

Developers should prioritize using the Clipboard API whenever possible due to its improved performance and security features. However, there may be cases where document.execCommand is still useful, such as when the Clipboard API is not supported or when cutting text is required.

It's essential for developers to use these methods responsibly and only execute commands when necessary, while avoiding using them for sensitive operations. By doing so, we can ensure that our applications are secure and provide a better user experience.

If you want more helpful content like this, feel free to follow me:

DEV Community: Phuoc Nguyen

Lazy load a Google Map

Creating the map container

Setting up the IntersectionObserver

Loading Google Maps with a specific callback

Conclusion

Lazy load a video

Using IntersectionObserver to detect when a video is visible

Displaying a loading indicator

Conclusion

Lazy load an iframe

Setting up an iframe for lazy loading

Setting up the IntersectionObserver

Improving user experience with loading indicators

Conclusion

Lazy load a background image

Updating the background image attribute

Elevating user experience with a loading indicator

Conclusion

Lazy load an image

Introducing the loading attribute

The limitations of the loading attribute

Only loading images when visible

Enhancing user experience with a loading indicator

Conclusion

Create a reusable component for IntersectionObserver

Introducing the Function as a Child pattern in React

Simplifying the IntersectionObserver API with a custom component

Using the custom component

Taking component customization further

Conclusion

See also

Create a reusable hook for IntersectionObserver

Simplifying the IntersectionObserver API with a custom hook

Using the custom hook

Customizing the hook further

Conclusion

See also

Use the IntersectionObserver API in React

Checking if an element is partially visible

Checking if an element is fully visible

Conclusion

An introduction to the IntersectionObserver API

Why you should use the IntersectionObserver API

IntersectionObserver browser compatibility

Understanding the IntersectionObserver API syntax

The options object in IntersectionObserver

The root property

The rootMargin property

Understanding the callback function

Understanding the IntersectionObserverEntry object

Disconnecting the observer

Conclusion

Check if an element is visible in the viewport

Checking if an element is visible in the window

Checking if an element is visible within a scrollable container

Checking if an element is partially visible in a scrollable container

Using the scrollY and innerHeight properties

Checking element visibility while users scroll

The drawbacks of using the scroll event to check element visibility

Conclusion

Practical examples of using IntersectionObserver with React

Clipboard API fallback

Understanding document.execCommand method

Comparing document.execCommand and Clipboard API

Copying vs cutting text

Security concerns with document.execCommand

Conclusion