H5、小規模プログラム、Taro ロングリスト露出埋め込みポイントを取得するのに役立つ 1 つの記事

多くのフロントエンドの学生にとって、「埋葬」は直面したくないが、逃れることができないトピックであることがよくあります。なぜそう言えるのかというと、多くのフロントエンド学生は深く理解していると思うのですが、第一に、ポイントの埋め込みの問題は基本的にフロントエンドの「独占」であり、サーバー側は基本的に関与しません。第二に、埋め込みを追加することです。問題は、多くの場合、埋め込まれたポイントに必要な情報を取得するために、すでに書かれたコードに骨の折れる修正を加える必要さえあることです。

フロントエンドの埋め込みポイントは時間と労力がかかり、達成感がありませんが、オンラインビジネスデータ (ユーザーの購買行動、アクティビティコンバージョンなど) を収集する重要な方法として、埋め込みポイントは重要なデータサポートを提供します。製品戦略の調整、特に 618 などの場所、ダブル 11 やその他の主要なプロモーション活動では、埋没ポイントデータの収集は、戦略の策定、タイムリーな調整、プロモーション活動の最終的な収益効果の検証にとって非常に重要です。研究開発の学生は真剣に取り組む必要があります。この記事は、長年にわたるさまざまなプラットフォームプロジェクトの実践経験に基づいて、埋め込みポイント要件の開発における実践的な経験とスキルをまとめたものであり、この記事を共有することで、より多くの読者が開発の回り道を避け、開発を完了できることを願っています。埋め込みポイントの開発タスクを正確かつ効率的に実行し、大規模なプロモーションおよび通常の運用中に安定したデータによってビジネスがサポートされるようにします。

身近なところでは、さまざまな種類の埋設点の中で、露出埋設点が最も複雑で、最も包括的な技術を必要とする場合が多く、実装方法が無理があると最も影響が大きくなる可能性があるため、本記事では露出埋設点に焦点を当てて説明します。、特に長いリスト（またはスクロールビュー）内の要素の露出と埋め込みを実現するというアイデアと、穴を避けるスキル。

1. リスト内の要素の露出を監視する一般的な方法

長いリスト (またはスクロールビュー) 内の要素の露出埋め込みポイント、鍵となるのは、子要素の「露出」イベントを監視する方法です。「露出」とは、要素が画面の可視領域に入ること、つまりユーザーに見えることを意味しますが、これは人間の直感的な視覚体験ですが、コードでどのように判断するのでしょうか？現時点では、1. インターフェースから送信されたページデータに基づいて表示要素を推定する、2. スクロールビューのスクロールイベントをリッスンし、要素の相対位置をリアルタイムに計算する、3. の大きく 3 つの方法があります。ブラウザ (またはアプレット、Taro などの他のプラットフォーム) を使用します。標準 API は、要素と表示領域の交差部分の変更をリッスンします。これら 3 つの方法の具体的な原理、適用範囲、利点と欠点をそれぞれ以下に紹介します。

1.1 方法 1: インターフェースによって提供されるページングされたデータに従って可視要素を推定する

実装のアイデア: 長いリストのデータは、多くの場合、ページングインターフェイスを通じて読み込まれます。この機能を使用すると、単一ページのデータによって返されたディメンションに基づいて、要素の可視性を大まかに推定できます。特に、各インターフェイスによって返されたデータが使用されます現在表示されている要素リストとして;

アドバンテージ：

この方法の利点は、単純であることです。要素の露出は、ページングインターフェイスによって毎回要求されるデータに従ってのみ判断され、計算は非常に簡単です。

欠点:

欠点は、エラーが大きすぎることです。一方で、単一のページングインターフェイスによって要求されるデータは、多くの場合 1 画面を超えますが、他方では、リスト内の要素の高さも異なる可能性があり、データの数も異なります。ページングによって返される値も異なる場合があります。計算要素の露出誤差が大きすぎます。

明らかな欠点と誤差が大きいため、現在この方法で露光埋め込みを実装する人はほとんどいませんが、高精度を必要としないシーンや古くから存在するコードでは、この実装方法が今でも多く見られます。

1.2 方法 2: スクロールイベントをリッスンし、要素の相対位置をリアルタイムで計算する

実装アイデア: 長いリスト (またはスクロールビューコンテナー) のスクロールイベントを監視し、要素の座標 (位置やサイズ情報などを含む) の状態 (重複があるかどうか) を取得して、要素が「表示」されているかどうかを判断します。

アドバンテージ：

方法 1 に比べて精度が大幅に向上しており、計算方法が正しければ計算結果は正確であると言えます。
さらに、プラットフォームで共通の基本機能インターフェイスを使用しているため、互換性が向上しています。

欠点:

大量の計算と重大なパフォーマンス損失: この計算方法では、スクロールビューのスクロールイベントを監視し、スクロールコールバックイベント内でリスト内のすべての要素の位置座標をリアルタイムで計算する必要があります (すべての要素の位置を取得し、現在表示されている領域と比較してください)。これにより生じる計算量は非常に多く、多くの場合、ページ上でパフォーマンスの問題 (スライドフリーズなど) が発生します。
散在したコードと複雑なロジック: スクロールビューのスクロールイベントの監視に加えて、最初の画面のデータがロードまたは更新されるときに追加の計算を実行する必要があります。ページに対する全体的な複雑さとパフォーマンスへの影響は比較的大きくなります。
その他の問題: H5 で getBoundingClientRect() を頻繁に呼び出すと、ブラウザスタイルの再計算やレイアウトが発生するなど、他の追加の操作が発生する可能性があります。iframe では内部要素に直接アクセスできないなど。

この方法には、大量の計算、複雑なロジック、および低パフォーマンスが含まれますが (もちろん、コードの複雑性を犠牲にして、パフォーマンスの最適化を実行することもできますが、その後の更新やメンテナンスには役立ちません)、方法 3 の Web 側標準インターフェイス (2016) が登場する前は、計算精度が厳密に要求されるシナリオでは、これが唯一の選択肢であるように見えました。

1.3 方法 3: ブラウザ標準 API を使用して要素の表示領域の変化を監視する

実装のアイデア: Intersection Observer API は、ページ要素の交差する変更を監視するために特別に使用される Web 標準 API インターフェイスとして、2016 年に Chrone ブラウザで最初に提供され、その後数年間に主要なブラウザでサポートされました。このインターフェイスは、次の機能を提供します。他の要素またはウィンドウに対する要素の位置を非同期的にクエリします。これにより、ページ内の要素の交差 (可視性) の変化を効率的に監視できます。

アドバンテージ：

パフォーマンスの向上: ブラウザの基盤となる実装はそれに応じて最適化されており、パフォーマンスに問題はありません。監視はメインスレッドで実行されません (コールバックメソッドがメインスレッドでトリガーされる限り)。
少量の計算: ここでの少量の計算とは、Web 開発者が実行する必要がある計算操作を指します。これは、ほとんどの計算ブラウザー API がすでに計算を行っており、必要なシナリオに基づいて単純な計算を実行するだけでよいためです。処理は需要を満たすことができます。
計算結果はより正確です。ブラウザ API によって実装された計算結果は比較的正確であり、これについては疑いの余地がありません。
コードはより洗練されています。監視および計算ロジックのほとんどが API 内に実装されており、開発者のコード量が多すぎたり複雑すぎたりすることはなく、フォローアップメンテナンスをより活用できるようにコードがより簡潔になっています。

欠点:

新しいブラウザーのサポートが必要です (ドキュメントに記載されているブラウザーの互換性によると、実際にはほとんどの使用シナリオを満たします)。バージョンが低すぎるブラウザーはサポートしません。互換性が必要な場合は、解決策もあります。公式ポリフィルを通じて解決 (ポリフィルを導入すると、当然コード量の増加が避けられません。プロジェクトにパッケージ化した後、JS ファイルのサイズが 8kb 増加しましたが、これが唯一の欠点です); (w3c は、対応するポリフィルを公式に提供します)

以上のことから、この方法は現在最も推奨されている元素暴露モニタリングの実装方法であり、具体的な使用方法として、H5、アプレット、Taro のそれぞれの利用シーンを紹介します。

2. リスト内の要素暴露イベント監視の具体的な実装

2.1 Web(H5)端末

簡単に言うと、Intersection Observer API を使用してビュー要素の可視性を観察することは、主にいくつかのステップに分かれています。オブザーバーの作成、ターゲット要素への観察の追加、観察結果 (コールバック) の処理、および観察の停止です。

2.1.1 具体的な使用方法：

ステップ 1: オブザーバー (IntersectionObserver) を作成する

まず最初に、IntersectionObserverルートビュー (親ビューまたは現在のウィンドウ) に対するターゲット要素の交差状態の変化 (つまり、エレメント）。具体的な作成方法はWeb標準APIを利用したIntersectionObserver構築方法で、具体的なコードは以下の通りです。

let observer = new IntersectionObserver(callback, options);

その中には、callback要素の位置を監視するときにトリガーされるコールバックメソッドがあり、具体的な定義と使用方法は、観測結果を処理する3 番目のステップで紹介します。
optionsは観測モードをカスタマイズするためのパラメータであり、パラメータは次のように定義されます。
```
interface IntersectionObserverInit {
    root?: Element | Document | null;
    rootMargin?: string;
    threshold?: number | number[];
}
```
- root: 観測を指定するために使用される参照領域。通常はターゲット要素の親ビューコンテナまたはビューウィンドウ全体です(ターゲット要素の親要素である必要があります。指定されていないかnullの場合、デフォルトでブラウザウィンドウになります)。
- rootMargin: 参照領域 (ルート) の外側のマージン。「10px 20px 30px 40px」(上、右、下、左) などの CSS のマージン属性に似ており、参照オブジェクトの領域範囲を調整するために使用されます (縮小または拡大);
- しきい値: 交差比率のしきい値。観察する必要がある交差比率の臨界値をカスタマイズするために使用されます。要素の交差 (交差比率) が変化した場合、コールバックメソッドは変更が発生するたびに実行されるのではなく、変更が発生するたびにのみ実行されます。交差比率が設定されたしきい値に達するとトリガーされます。 Callback ( callback)。単一の値 (数値) または値のグループを指定できます。たとえば、0.25 に設定すると、交差が 0.25 に達した場合にのみコールバックがトリガーされます ( 0.25 に増加するか 0.25 に減少するとトリガーされます); if それが値のセットの場合、交差比率が任意の値に達したときにもコールバックがトリガーされます; (注: さらに、コールバックは要素が次の値に達したときにもトリガーされます)閾値に達したか否かに関わらず初めて追加されます）

たとえば、上図のしきい値設定状態では、要素が点線の位置にスライドし、親ビューの境界線と交差するたびにコールバックがトリガーされます。

ステップ 2: ターゲット要素に観測値を追加する

オブザーバーを使用すると、ターゲット要素を観察できます。具体的なコードは次のとおりです。

let target = document.querySelector('#listItem');
observer.observe(target);

観測値を追加するタイミングに注意し、対象の要素が作成された後に観測値が追加されるようにする必要があります。動的に作成された要素 (ページネーション読み込みデータなど) の場合は、観測値をターゲット要素に追加する必要があります。各要素が作成された後、新たに追加された要素が再度追加されます。

ステップ 3: 観察の処理

参照ビュー (ルート) と交差する観測対象要素の割合が設定されたしきい値に達すると、登録されたコールバックメソッド ( callback) がトリガーされます。コールバックメソッドの定義は次のとおりです。

interface IntersectionObserverCallback {
    (entries: IntersectionObserverEntry[], observer: IntersectionObserver): void;
}

コールバックメソッドが 2 つのパラメーターを受け取ることができることがわかります。

entries : IntersectionObserverEntry の配列。交差状態が変化する要素のコレクションです。各 IntersectionObserverEntry オブジェクトには、次の 6 つの属性があります。
- time: 交差点のタイムスタンプ (ミリ秒単位)。(文書の作成時間に対する交差点の変化時間)
- target: 観察されたターゲット要素は DOM ノードオブジェクトです。
- rootBounds: ルート要素の長方形の境界 (参照領域)
- boundingClientRect: 対象要素の境界情報境界の計算方法はElement.getBoundingClientRect()と同様です。
- IntersectionRect: ターゲット要素とルート要素の間の交差領域
- IntersectionRatio: ターゲット要素全体のサイズに対する、ターゲット要素がルート要素と交差する部分のサイズの比率、つまり、intersectionRect とboundingClientRect の比率。
- isIntersecting: 対象要素がルート要素と交差するかどうか(設定された閾値に従って判定)
オブザーバー: 現在のオブザーバー。

この情報を使用すると、ターゲット要素の可視状態の変化を簡単に監視し、その後の埋め込みポイントのレポート、データの記録、遅延読み込みなどのさまざまな処理を実行できます。

登録されたコールバック関数はメインスレッドで実行されるため、この関数の実行速度はできるだけ高速である必要があります。時間のかかる操作を実行する場合は、Window.requestIdleCallback() メソッドを使用することをお勧めします。

パート 4: 見るのをやめる

観測を停止する必要がある場合は、適切なタイミングで要素の観測を解放するか、すべてのターゲット要素の観測を終了することができます。

// 停止观察某个目标元素
observer.unobserve(target)

// 终止对所有目标元素可见性变化的观察，关闭监视器
observer.disconnect()

2.1.2 ヒント

isVisibleIntersection Observer API の V2 バージョンに新しい属性が追加されたことに注意してください (Chrome ブラウザの新しいバージョンではすでにサポートされていますが、Safari などの他のブラウザではサポートされていません)。この属性は、要素が交差かどうかを識別するために使用されます。「visible」（要素が可視領域内にあっても、他の要素やstyle属性のhidenなどに遮られて見えない要素がある場合があるため）、公式の説明ではパフォーマンスを確保するため、、このフィールドの値は正確ではない可能性があります。特別なシナリオを除いて、このフィールドを使用することはお勧めできません。ほとんどのシナリオではisIntersecting十分です。

興味のある方は、ドキュメントの説明を参照してください: Intersection Observer V2 の説明

2.1.3 Intersection Observer API のブラウザサポート

ブラウザ	プラットホーム	サポートされているバージョン	リリースタイム
クロム	パソコン	51	2016-05-25
クロームアンドロイド	アンドロイド	51	2016-06-08
WebView Android	アンドロイド	51	2016-06-08
サファリ	マックOS	12.1	2019-03-25
iOSのSafari	iOS	12.2	2019-03-25
角	パソコン	15	2017-04-05
Firefox	パソコン	55	2017-08-08
Android 版 Firefox	アンドロイド	55	2017-08-08
オペラ	パソコン	38	2016-06-08
オペラアンドロイド	アンドロイド	41	2016-10-25

特定の使用シナリオ (サポートされているブラウザーのバージョン) に応じて、標準 API を直接使用するか、下位バージョンのブラウザーと互換性を持たせるためにポリフィルまたはその他のメソッドを追加する必要があるかを決定できます。

2.2 ミニプログラム（WeChatミニプログラム）

WeChat アプレットは、Web 側のインターフェースと同様に、ミニプログラムバージョンの対応する API インターフェースを提供します。機能は Web 側の Intersection Observer API に似ており、使用方法は基本的に同じですが、相違点もありますいくつかの詳細、具体的な手順:

ステップ 1: オブザーバー (IntersectionObserver) を作成する

オブザーバーは、 WeChat アプレットフレームワークによって提供されるメソッドを通じてIntersectionObserver wx.createIntersectionObserver(Object component, Object options)簡単に作成できます。

Page({
  data: {
    appear: false
  },
  onLoad() {
    this._observer = wx.createIntersectionObserver(this,{
      thresholds: [0.2, 0.5]
    })
    //其他处理...
  },
  onUnload() {
    if (this._observer) this._observer.disconnect()
  }
})

Web 側の IntersectionObserver 構築メソッドと同様に、アプレットのこのステップではコールバックメソッドを設定する必要がなく、コールバックメソッドは後で観測を追加するときに登録される点が異なります。

入力パラメータの説明:component通常、現在のページまたはコンポーネントのインスタンスを渡す必要があります。optionsトリガーのしきい値、複数のターゲットノードを同時に観察するかどうか、およびその他の情報を定義できます。

ステップ2: 参照ノード(参照領域)を指定する

Web側作成時の仕様とは異なり、アプレット側では参照ノード(参照領域)を指定するためのインターフェースを2つ用意しています。

IntersectionObserver IntersectionObserver.relativeTo(string selector, Object margins) : セレクターを使用してノードを参照領域の 1 つとして指定します。つまり、ノードのレイアウト領域が参照領域として使用されます。
IntersectionObserver IntersectionObserver.relativeToViewport(Object margins)：ページ表示領域を参照領域の1つとして指定します

例：

this._observer = this._observer.relativeTo('.scroll-view')

参照領域は、によって拡張 (または縮小) することもできます。参照ノードが複数ある場合は、それらのレイアウト領域が参照領域とmarginsみなされます。交集

ステップ 3: オープンな観察

最初の 2 つの手順でオブザーバーを作成し、関連するパラメーター (トリガーしきい値、マルチターゲットなど) を設定し、参照領域を指定すると、ターゲット要素を観察できるようになります。ここでは、ターゲット要素はセレクターを使用して指定され (Web 側は要素インスタンスです)、交差する状態変更のコールバックメソッドをここで指定する必要があります。IntersectionObserver.observe(string targetSelector, function callback)

例：

this._observer.observe('.ball', (res) => {
    console.log(res);
    this.setData({
        appear: res.intersectionRatio > 0
    })
})

ステップ 4: コールバックを処理する

参照領域に対する要素の交差が変化すると (Web 側と同様、トリガーのタイミングは最初のステップでオブザーバーを作成するときに設定されたしきい値によって決まります)、対応するコールバックメソッドがトリガーされます。コールバックメソッドで受け入れられるパラメータは基本的に Web 側のパラメータと同じですが、相違点もあります。

アプレット側は単一のトリガーであり、コールバックメソッドの入力パラメータは単一の要素です (Web 側では複数のコールバックがまとめられ、入力パラメータは変化する要素の配列となります)。
アプレットの入力パラメータには、ターゲットノードのノード ID とカスタムデータが同時に含まれます。

ステップ 5: 聞くのをやめる

IntersectionObserver.disconnect()
聞くのをやめてください。コールバック関数は起動しなくなります

if (this._observer) this._observer.disconnect()

チップ

注: コンポーネントで、付属のコンポーネントライフサイクル関数に内部サブ要素の交差する変更監視を追加すると、この時点ではコンポーネントのレイアウトが完了していないため、正常に監視できない可能性があります。コンポーネント内のノードの作成が完了していません。

2.3 Taro フレームワーク (Taro3+React)

Taro は、対応する IntersectionObserver API も提供しています。API の定義と使用方法は、基本的に WeChat アプレット側と一致しています。Taro 自体は、H5 やアプレットなどの複数の端末をサポートしており、IntersectionObserver インターフェイスは、H5 および WeChat アプレットと内部互換性があります。アプレットと他のプラットフォームの連携とスムーズ化が行われています. 具体的には、H5 側では WeChat アプレット側の形式に従ってパッケージ化されています. その内部実装は、Web 側で Intersection Observer API を呼び出すことです. 基本的には、対応するプラットフォームアプレットのネイティブインターフェイスをブリッジします。

インターフェイスの定義と使用方法は WeChat アプレットに準拠しているため、Taro 側の具体的な使用方法についてはここでは説明しませんが、説明が必要なのは、Taro フレームワークの特殊性によるものです (アプレットの本来の方法と比較して)。アプレット側でスライディング露出モニターを開発する場合、エラーが発生しやすい、または特別な処理が必要な点がいくつかあります。

1. 監視が効かない問題

Taro ランタイムメカニズムにより、この時点では対応するデータ駆動型アプレット要素インスタンスがまだ作成またはマウントされていないため、Taro コンポーネントのデータ更新メソッド (setState など) の実行直後にリスナーを追加しても有効にならない場合があります。遅延を追加するか、Taro.nextTick コールバックで実行します (Taro の最新バージョンでは、デフォルトで、observe メソッドが Taro.nextTick に追加されています)。モニタリングの追加が有効にならない状況に遭遇した場合は、このメソッドを試すことができます。

Taro.nextTick(() => {
    //将监听添加时机（延迟作到下一个时间片再执行），解决监听添加时元素尚未创建导致的监听无效问题
    expoObjserver.relativeTo('.clpScrollView').observe('.coupon-item', result => {
        console.log(result.intersectionRatio);
        //...
    });
});

2. オブザーバーを作成するには、ネイティブコンポーネントインスタンスを渡す必要があります。

オブザーバーを作成するときは、アプレットのページまたはコンポーネントインスタンスを渡し、これを Taro コンポーネントまたはページで直接使用して、Taro レイヤーのページまたはコンポーネントのインスタンスを取得する必要があります。この 2 つは異なります。

アプレット層のコンポーネントインスタンスを取得する方法は次のとおりです。

純粋な Taro プロジェクトでは、Taro.getCurrentInstance().pageアプレットページを取得するインスタンスを直接使用できます。
Taro コンポーネントがネイティブカスタムコンポーネントの混合モードにコンパイルされている場合、 props.$scope アプレットのカスタムコンポーネントオブジェクトインスタンスを取得できます。

3. コールバックメソッドで対象要素のその他の情報を取得するにはどうすればよいですか?

作成と設定が正しければ、リストがスライドしたり、他の要素の位置が変化したりすると、対応するコールバックメソッドがトリガーされるはずです。コールバックメソッドでは、コールバックの入力パラメータを受け取り、それらを処理する必要があります (レポートなど)関連するビジネス情報）。Taro ドキュメントの定義によれば、コールバックメソッドの入力パラメータはObserveCallbackResult次の型です。

interface ObserveCallbackResult {
      /** 目标边界 */
      boundingClientRect: BoundingClientRectResult
      /** 相交比例 */
      intersectionRatio: number
      /** 相交区域的边界 */
      intersectionRect: IntersectionRectResult
      /** 参照区域的边界 */
      relativeRect: RelativeRectResult
      /** 相交检测时的时间戳 */
      time: number
    }

IntersectionRatio や時間などの交差点情報のみがあり、カスタムデータフィールドがないことがわかります (比較として、WeChat アプレットによって提供されるコールバックメソッドにはノード ID、ノードカスタムデータ属性データセット、その他の情報も含まれています)。 , では、Taro で対象要素の他のデータ情報を取得するにはどうすればよいでしょうか。

実際のデバッグでは、ドキュメントには ID とデータセットがありませんが、実際の戻り値にはこれら 2 つのフィールドがあることがわかりました。はは、これを見て何も問題ないと思いますか? 私は、これは単なるちょっとしたジョークだと思いました。 Taro ドキュメント。;実際の戻り値にはデータセットフィールドがありますが、残念ながらデータセットフィールドは常に空であり、実際の戻り結果 (結果) の例は次のとおりです。

{
    "id": "_n_82",
    "dataset": {},
    "time": 1687763057268,
    "boundingClientRect": {
        "x": 89.109375,
        "y": 19,
        ...
    },
    "intersectionRatio": 1,
    "intersectionRect": {
        "x": 89.109375,
        "y": 19,
        ...
    },
    "relativeRect": {
        "x": 82.109375,
        ...
    }
}

何？なぜ？これを見ると、誰もがキーボードを叩きたくなる衝動にかられると推定されます。心配しないで、まずキーボードがdataset空である理由を分析しましょう。
これは、datasetアプレットの特別なテンプレート属性であるためです。主な機能は、イベントコールバックのオブジェクト内の関連データを取得することです。Taro はこれらの機能を部分的にサポートしています。Taro は、ロジック層でのシミュレーションを通じてイベントコールバックオブジェクトをすでにサポートしていevent ます dataset. 合格 event.target.dataset または event.currentTarget.dataset 取得。ただし、このプロパティはロジック層でシミュレートされるため、実際にはテンプレートに設定されません。そのため、アプレット内にページのノードを取得する API (createIntersectionObserver など) がある場合、それらの API を取得できませんdataset。

前のポイントで述べたように、Taro によるアプレットデータセットのシミュレーションは、アプレットのロジック層で実装されます。このプロパティは実際にはテンプレートに設定されません。
ただし、アプレット内にページのノードを取得するための API (createIntersectionObserver など) がある場合、実際にはノードに対応する属性がないため、それらの API を取得できません。

--Taro 公式ドキュメントより: Taro-React-dataset

コールバックパラメータの直接値は空なので、要素のカスタムデータを取得するにはどうすればよいでしょうか?

解決策 1: taro-plugin-inject ソリューション

公式の解決策は、taro-plugin-injectプラグインを使用していくつかの共通属性をサブ要素に挿入することです。実際の検証では、プラグインの挿入後に対応する属性が実際にコールバックデータセットに表示されることがわかりましたが、その属性はこの方法は統一することしかできず、属性値の固定値を実際のデータに応じて動的に設定することができないため、このソリューションでは要求を満たすことができません。

//项目 config/index.js 中的 plugins 配置：
  plugins: [
    [
      '@tarojs/plugin-inject',
      {
        components: {
          View: {
            'data-index': "'dataIndex'",
            'data-info': "'dateInfo'"
          },
        },
      },
    ]
  ],
  
//实际返回值
{
    "id": "_n_82",
    "dataset": {
        "index": "dataIndex",
        "info": "dateInfo"
    },
    "time": 1687766275879,
    ...
}

解決策 2: Taro 仮想 DOM にアクセスする

React フレームワークの使用における違いの説明に関する Taro の公式ドキュメント ( Taro-React-lifecycle トリガーメカニズム) によると、Taro3 はアプレットのロジック層に Web 標準に準拠した BOM および DOM API を実装します。これらの API を通じて、対応する仮想 DOM ノード (TaroElement オブジェクト) を取得できますが、ロジック層によって実装されるため、対応する情報もdatasetノード上で表示される必要があります。

これは、 Taro DOM リファレンスドキュメントの TaroElement フィールドの説明でも確認されています。

では、どうすればそれを達成できるのでしょうか？コールバックパラメーターに必要なカスタムデータフィールドはありませんが、ノード ID 情報を取得できます。ノード ID を使用して、 Taro が提供する API を通じて対応する Taro 仮想 DOM ノードを取得し、そこから必要な情報を取得できdocument.getElementById();ますdataset。このノードのコードは以下のように表示されます。

Taro.nextTick(() => {
	//将监听添加时机（延迟作到下一个时间片再执行），解决监听添加时元素尚未创建导致的监听无效问题
	expoObjserver.relativeTo('.clpScrollView').observe('.coupon-item', result => {
		if (!result?.id) return;
		// !!!获取虚拟DOM节点
		const tarTaroElement = document.getElementById(result?.id);
		const dataInfo = tarTaroElement?.dataset; //拿到dataset信息
		console.log(tarTaroElement);
		console.log(dataInfo);
       //...
	});
});

これで目的のカスタムデータ（業務データ）が取得できたので、後は必要に応じてこれらのデータを自由に利用することで、Taroにおけるリストのスライド要素の公開と埋め込みが完了しました～

要約すると、上記のいくつかの一般的なソリューションと各プラットフォームへの特定の実装の導入を通じて、ロングリストのスライディング要素の露出監視の問題はもはや難しくなくなり、スライディング要素の露出監視は解決されました。、露出埋設ポイント、またはその他の高度なゲームプレイ (長いリストの最適化 - リソースの遅延読み込み、無限ループスクロールなど) は、将来的にはゆっくりできます。

参考文献

著者: 京東小売業丁新

出典: JD Cloud 開発者コミュニティ