Common Methods for Listening to List Item Exposure in Frontend Development

Data collection (埋点) is essential for front‑end analytics, especially for exposure tracking of list items during large‑scale promotions. The article first describes why exposure points matter and then focuses on three common solutions for detecting when an element becomes visible in a scrolling list.

Method 1: Estimate visibility from paginated data – Use the current page of data returned by an API as a rough estimate of which items are on screen. This approach is simple and low‑cost but suffers from large errors because page size may exceed the viewport and item heights vary.

Method 2: Listen to scroll events and compute positions – Attach a scroll listener to the container, retrieve each element’s bounding rectangle (e.g., via getBoundingClientRect() ), and compare it with the viewport to decide visibility. It offers higher precision and good compatibility, but the per‑frame calculations can be heavy, causing performance degradation and complex code.

Method 3: Use the IntersectionObserver API – A native browser API that asynchronously reports intersection changes between a target element and a root (viewport or another element). It provides high performance, minimal developer‑side computation, and accurate results. The main limitation is browser support; older browsers require a polyfill.

Web (H5) implementation – The typical workflow includes four steps:

Create an observer: let observer = new IntersectionObserver(callback, options);

Observe a target: observer.observe(document.querySelector('#listItem'));

Handle callback: receives an array of IntersectionObserverEntry objects containing properties such as time , target , rootBounds , boundingClientRect , intersectionRect , intersectionRatio , and isIntersecting .

Stop observing: observer.unobserve(target) or observer.disconnect() .

The article also lists the IntersectionObserverInit interface (root, rootMargin, threshold) and discusses performance tips, such as keeping the callback lightweight and using requestIdleCallback for heavy work.

Mini‑program (WeChat) implementation – Use wx.createIntersectionObserver(component, options) to create an observer, then call relativeTo(selector) or relativeToViewport() to set the reference area, and finally observe(targetSelector, callback) . The callback receives a single result object (instead of an array) with fields like id , time , boundingClientRect , intersectionRatio , etc. The article notes that the dataset field is empty due to logical‑layer simulation.

Two work‑arounds for accessing custom data in mini‑programs are presented:

Inject static attributes via taro-plugin-inject .

Retrieve the virtual DOM node by document.getElementById(result.id) and read its dataset .

Taro (multi‑platform) implementation – Taro’s IntersectionObserver API mirrors the mini‑program API and internally maps to the Web API on H5. Special considerations include delaying observer registration with Taro.nextTick to ensure elements are mounted, and obtaining the native component instance via Taro.getCurrentInstance().page or props.$scope when needed.

The article concludes that mastering these three methods—especially the IntersectionObserver API—enables reliable exposure tracking for long lists across Web, mini‑program, and Taro environments, facilitating downstream analytics, lazy loading, and other advanced use cases.