ブラウザソース更新後に1件のドネーションでアラートが2回表示される理由

1件のドネーションでアラートが2回表示される理由

ブラウザソースを更新すると、ページが再起動します。スクリプトは再びサーバーに接続し、イベントを購読して、通知を表示するためのハンドラを作成します。古いハンドラが削除されていない場合や、2つの接続が同時に動作している場合、1つのドネーションイベントが複数回処理されます。

更新そのものが必ずしも不具合の原因ではありません。多くの場合、更新は接続ロジックのエラーを表面化させるだけです。たとえば、初期化関数がページ読み込み時に実行され、次に接続復元時に、さらに制御メッセージの受信後にもう一度実行されることがあります。実行のたびに donation イベントへの新しい購読が追加されます。

その結果、サーバーは1つのドネーションオブジェクトを送信しますが、ブラウザは同じ関数を2回呼び出します。サーバー側で重複が発生することもあります。アプリケーションが新しい接続を別の受信者とみなし、古いセッションと新しいセッションの両方にイベントを送信するのです。そのため、まず重複がどこで発生しているのかを特定する必要があります。ソース内、ハンドラ内、または表示段階のいずれかです。

重複が発生する箇所の見つけ方

まずは簡単なテストから始めましょう。ブラウザソースのリンクを別ウィンドウまたは別タブで開き、ページのインスタンスを1つだけにしてテストイベントを送信します。アラートが1回だけ表示される場合、原因はシーン設定やソースの複数インスタンスに関連している可能性が高いです。別タブですでに重複する場合は、ページのコードと購読の仕組みを確認してください。

ドネーションの処理をいくつかの段階に分けると便利です。イベントの受信、イベントの検証、アラートのキューへの追加、描画です。ログやコンソールに各段階のマークを一時的に出力します。受信の記録が2回現れる場合、問題は視覚的なレイヤーより前にあります。イベントは1回受信されたがキューに2つの要素がある場合、エラーはハンドラ内にあります。キューに1つの要素しかないのに画面に2つのアラートが表示される場合は、表示関数とHTMLコンテナを確認してください。

診断のために、ドネーションデータで渡される場合は各イベントにその識別子を追加してください。この識別子を受信時と表示前に記録します。2回の呼び出しで同じ識別子が現れる場合、1つのイベントが再処理されたことを示します。2つの異なる識別子は2回の配信を示しており、別々に調査する必要があります。

タブの数だけを確認しないでください。OBSでは、シーンのコピー、ネストされたシーンの追加、同じアドレスでブラウザソースを再度追加した後に、2つのインスタンスが現れることがあります。1つのソースが別のレイヤーに残り、2つ目がその上に追加されることもあります。見た目は二重のアラートに見えますが、イベントは1回しか届いていません。

再接続後の再購読

最も一般的な原因は、接続のたびにハンドラが追加されるものの、切断時に解除されないことです。簡略化すると、問題は次のようになります。関数がアラート表示用のハンドラで socket.on を実行し、その後接続が切断され、アプリケーションが再び接続して socket.on を繰り返します。その後、1件の受信ドネーションが2つの関数を呼び出します。次の再接続時にはさらに増える可能性があります。

同じエラーは通常の addEventListener でも発生します。初期化関数が複数回呼び出されると、ブラウザは同じイベントに複数のリスナーを追加します。「初期化済み」フラグによるチェックは常に役立つとは限りません。ページ全体を更新すると変数はリセットされますが、同じページ内での再接続では問題が残ります。

購読は接続のライフサイクルごとに1回だけ作成し、古い購読は新しいものの前に明示的に削除する必要があります。イベントハンドラには removeEventListener を使用し、接続時に渡した同じ関数参照を使います。ソケットを扱うライブラリでは通常、off、unsubscribe、または同様の切断方法が必要です。

ソケットの最小構成は次のようになります。const onDonation = data => showAlert(data); socket.off('donation', onDonation); socket.on('donation', onDonation); function cleanup() { socket.off('donation', onDonation); window.removeEventListener('beforeunload', cleanup); socket.close(); } window.addEventListener('beforeunload', cleanup);

ここで重要なのは特定のライブラリではなく、操作の順序です。ハンドラは変数に保持されるため、同じ参照で解除できます。新しい購読の前に古いものを削除し、ページを閉じるかソースを停止するときに cleanup を実行します。実行のたびに新しいソケットが作成される場合は、まず古いものを閉じてから新しいものを作成する必要があります。そうしないと、両方の接続が同じデータを受信し続ける可能性があります。

再接続時には、古い接続も閉じて関連するタイマーをクリアしてください。そうしないと、新しいソケットが動作している間に古いソケットがデータを受信し続ける可能性があります。これは特に、コードが前のタイマーをキャンセルせずに新しい再接続タイマーを開始する場合によく発生します。

OBSとブラウザソースで確認すべきこと

別ウィンドウでアラートが1回だけ表示される場合は、シーンに進んでください。プレビューを停止し、余分なレイヤーを一時的に削除して、ブラウザソースを1つだけ残します。その後、目的のシーンで動作を確認します。このテストは、すべてのシーンとフィルターを同時に確認するよりも速いです。

• 同じページアドレスを持つ2つのソースを探してください。
• 同じオーバーレイが含まれている可能性があるシーンのコピーとネストされたシーンを確認してください。
• アラートがブラウザソースと同じページを持つ別のレイヤーによって同時に出力されていないことを確認してください。
• 設定を変更した後は、シーンを切り替えるだけでなく、ソースを完全に再起動してください。

URLやパラメータを更新した後、OBSにブラウザソースの古いタブが残ることがあります。ソースを閉じて再度追加すると仮説を検証できますが、コードの修正の代わりにはなりません。更新のたびに問題が再発する場合は、ハンドラの再登録や二重接続を探してください。

切断の遅延も考慮してください。更新時に古いセッションが即座に閉じないことがあります。サーバーが数秒間それをアクティブとみなす場合、その間に届いたイベントが2つのセッションに入る可能性があります。正常なサーバーロジックは、非アクティブな接続を削除し、ページを閉じた後に購読を残さないようにする必要があります。

同じイベントの再配信に対する保護

ブラウザソースが正しく動作していても、1つのイベントが再配信されることがあります。これは接続の復元、メッセージの再送信、またはイベントの受信と処理確認の間の障害で発生する可能性があります。そのため、アラートハンドラは繰り返しに対して堅牢である必要があります。

最良の方法は、ドネーションの一意の識別子を確認することです。イベントをキューに追加する前に、その識別子を処理済みイベントのセットに保存します。その識別子がすでに出現している場合は、繰り返しをスキップする必要があります。リストは無限に増えないように、限られた期間だけ保持してください。

このために金額、送信者名、またはメッセージテキストだけを使用しないでください。2つの異なるドネーションが同じデータを持つ可能性があります。時間によるチェックも信頼できません。複数の異なるドネーションがほぼ同時に届く可能性があります。識別子がない場合は、一時的にフィールドの組み合わせと時間を比較できますが、これは2つのイベントを誤って統合するリスクがある代替手段です。

重複保護はアニメーション内ではなく、アラート表示の前に配置する必要があります。そうしないと、2回目の呼び出しでもページに要素が追加され、音声が再生され、キューにさらに1つのレコードが追加されます。キューを個別に制御してください。1つのイベントは1回だけキューに追加され、2回目の呼び出しで2つ目の独立したキューが開始されないようにする必要があります。

イベントが複数のタブやコンポーネント間で渡される場合は、複数の受信者が同時に処理していないか確認してください。1つの共通メッセージチャネルが複数のハンドラに接続されている可能性があります。その場合は、消費者を1つだけ残すか、どのコンポーネントがアラート表示を担当するかを明示的に定義する必要があります。

キャッシュのクリアが常に役立つとは限らない理由

ブラウザソースを更新した後、キャッシュをクリアすることをよく勧められます。これは古いバージョンのスクリプトが読み込まれた場合に状況を改善できますが、キャッシュはすでに動作しているページの余分なハンドラを削除せず、ソースの2つ目のコピーも閉じません。再接続のたびに重複が安定して繰り返される場合、原因はほぼ間違いなく接続ロジックまたはシーン構造にあります。

新しいバージョンのファイルが実際に読み込まれているか確認してください。リソースのアドレスを一時的に変更するか、用意された更新の仕組みを使用してから、ブラウザソースを再起動します。その後、1つのウィンドウと1つのソースインスタンスでテストを再度実行します。リンクにランダムなパラメータを常に追加しないでください。多くのキャッシュバリエーションが作成され、診断が複雑になる可能性があります。

中間キャッシュや service worker が使用されている場合、それも古いスクリプトを配信する可能性があります。その場合は、読み込まれたファイルのバージョンと、期待するバージョンを比較してください。ただし、古いファイルであっても再購読の原因を解消する必要があります。そうしないと、次の更新後に問題が再発します。

アラートコードで確認すべきこと

まず、socket.on、addEventListener、接続関数、キューの起動が呼び出されるすべての場所を見つけてください。問題が1つのハンドラではなく、2つの異なるモジュールが独立して donation イベントをリッスンし、それぞれが独自の表示を開始していることがあります。

次に、アラートがフレームワーク経由で出力される場合は、コンポーネントのライフサイクルを確認してください。購読はエフェクトまたは同様のブロックに配置し、クリーンアップ関数を返します。前のハンドラを削除せずに、状態の更新のたびに新しいハンドラを作成してはいけません。通常の JavaScript では、ページ停止時に正しく閉じられるように、アクティブなソケットと現在のハンドラへの参照を保持することが重要です。

再接続タイマーを確認してください。新しいタイマーは古いものの上で開始してはいけません。そうしないと、数回の切断後に並行した接続試行が作成され、それに伴って追加の購読も作成されます。各タイマーは、不要になったら clearTimeout または clearInterval でクリアする必要があります。

アラートを表示するコードを個別に確認してください。同じオブジェクトに対して、要素をキューに追加すると同時に表示関数をすぐに呼び出してはいけません。また、要素の状態変更時にアニメーションが再実行されていないか確認してください。ログに1回の受信と1回のキュー追加があり、画面に2つの通知がある場合は、まさにここを探す必要があります。

診断チェックリスト：順番に行うこと

1. ブラウザソースのURLを別タブで開き、テストドネーションを1件送信します。OBS外で重複が現れるか記録します。
2. シーンにソースのインスタンスを1つだけ残します。シーンのコピー、ネストされたシーン、同じアドレスが含まれている可能性があるレイヤーを確認します。
3. 受信、キューへの追加、表示の各段階でイベント識別子を含むログを追加します。これにより、どこでオブジェクトの数が増えるかがわかります。
4. socket.on と addEventListener のすべての呼び出しを見つけます。古いハンドラが同じ関数参照で socket.off と removeEventListener を介して解除されているか確認します。
5. 再接続を確認します。古いソケットが閉じられているか、古いタイマーがキャンセルされているか、以前の購読の上に新しい購読が作成されていないか確認します。
6. キューの前にドネーションの一意の識別子のチェックを追加し、ソースを完全に再起動して、1つのイベントでテストを繰り返します。

別タブではイベントが1回受信されるのに、OBSで2つのアラートが表示される場合は、ソースの2つ目のインスタンスまたはシーン内の重複を探してください。別タブですでにイベントが2回届く場合は、購読、接続、サーバー配信を確認してください。受信とキューが1回だけ記録されるのに画面に2つの通知がある場合は、問題は視覚的なレイヤーにあります。