브라우저 소스 업데이트 후 하나의 후원이 두 개의 알림을 발생시키는 이유

하나의 후원이 두 개의 알림을 발생시키는 이유

브라우저 소스를 업데이트하면 페이지가 다시 시작됩니다. 스크립트가 다시 서버에 연결하고, 이벤트를 구독하며, 알림 표시를 위한 핸들러를 생성합니다. 이전 핸들러가 제거되지 않았거나 두 개의 연결이 동시에 작동하면 하나의 후원 이벤트가 여러 번 처리됩니다.

업데이트 자체가 반드시 오류의 원인은 아닙니다. 업데이트는 연결 로직의 오류를 드러내는 경우가 많습니다. 예를 들어 초기화 함수가 페이지 로드 시, 연결 복구 시, 그리고 서비스 메시지 수신 후에 다시 실행될 수 있습니다. 각 실행마다 donation 이벤트에 대한 새 구독이 추가됩니다.

결과적으로 서버는 하나의 후원 객체를 보내지만 브라우저는 동일한 함수를 두 번 호출합니다. 때로는 서버 측에서 중복이 발생합니다. 애플리케이션이 새 연결을 별도의 수신자로 간주하여 이전 세션과 새 세션 모두에 이벤트를 전송하는 것입니다. 따라서 먼저 중복이 소스, 핸들러, 표시 단계 중 어디에서 발생하는지 파악해야 합니다.

중복이 발생하는 위치를 찾는 방법

간단한 테스트부터 시작하세요. 브라우저 소스 링크를 별도의 창이나 탭에서 열고 페이지 인스턴스를 하나만 남긴 뒤 테스트 이벤트를 보내세요. 알림이 한 번만 나타나면 원인은 대부분 장면 설정이나 소스의 여러 인스턴스와 관련이 있습니다. 별도 탭에서 이미 중복된다면 페이지 코드와 구독 메커니즘을 확인하세요.

후원 처리를 여러 단계로 나누는 것이 유용합니다. 이벤트 수신, 이벤트 검증, 알림 큐 배치, 렌더링입니다. 로그나 콘솔에 각 단계의 표시를 임시로 출력하세요. 수신 기록이 두 번 나타나면 문제는 시각적 레이어 이전에 있습니다. 이벤트가 한 번 수신되었지만 큐에 두 개의 항목이 있으면 핸들러의 오류입니다. 큐에 하나의 항목만 있는데 화면에 두 개의 알림이 표시되면 표시 함수와 HTML 컨테이너를 확인하세요.

진단을 위해 후원 데이터에 전달되는 경우 각 이벤트에 식별자를 추가하세요. 수신 시점과 표시 전에 이 식별자를 기록하세요. 두 호출에서 동일한 식별자는 하나의 이벤트가 재처리되었음을 보여줍니다. 두 개의 다른 식별자는 별도로 분석해야 할 두 개의 전송을 의미합니다.

탭 수만 확인하지 마세요. OBS에서는 장면 복사, 중첩 장면 추가, 또는 동일한 주소로 브라우저 소스를 다시 추가한 후에 두 개의 인스턴스가 나타날 수 있습니다. 때로는 하나의 소스가 별도의 레이어에 남아 있고 두 번째 소스가 그 위에 추가됩니다. 시각적으로는 이중 알림처럼 보이지만 이벤트는 한 번만 도착한 것입니다.

재연결 후 재구독

가장 흔한 원인은 핸들러가 연결할 때마다 추가되지만 연결 해제 시 제거되지 않는 것입니다. 단순화하면 문제는 다음과 같습니다. 함수가 알림 표시 핸들러로 socket.on을 실행하고, 그 다음 연결이 끊어지고, 애플리케이션이 다시 연결하여 socket.on을 반복합니다. 이후 하나의 수신 후원이 두 개의 함수를 호출합니다. 다음 재연결 시에는 더 많아질 수 있습니다.

동일한 오류가 일반 addEventListener에서도 발생합니다. 초기화 함수가 여러 번 호출되면 브라우저는 동일한 이벤트에 여러 리스너를 추가합니다. '초기화가 이미 완료됨' 플래그 확인이 항상 도움이 되는 것은 아닙니다. 전체 페이지 업데이트 시에는 변수가 초기화되지만, 동일한 페이지 내에서 재연결할 때는 문제가 지속됩니다.

구독은 연결 수명 주기당 한 번 생성해야 하며, 이전 구독은 새 구독 전에 명시적으로 제거해야 합니다. 이벤트 핸들러에는 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와 브라우저 소스에서 확인할 사항

별도 창에서 알림이 한 번만 표시되면 장면으로 넘어가세요. 미리보기를 중지하고 불필요한 레이어를 임시로 제거한 뒤 브라우저 소스 하나만 남기세요. 그런 다음 원하는 장면에서 동작을 확인하세요. 모든 장면과 필터를 동시에 확인하는 것보다 이 테스트가 더 빠릅니다.

• 동일한 페이지 주소를 가진 두 개의 소스를 찾으세요.
• 동일한 오버레이가 있을 수 있는 장면 복사본과 중첩 장면을 확인하세요.
• 알림이 브라우저 소스와 동일한 페이지를 가진 다른 레이어에서 동시에 출력되지 않는지 확인하세요.
• 설정 변경 후 장면을 전환하는 것만으로는 부족하며 소스를 완전히 다시 시작하세요.

때로는 URL이나 매개변수 업데이트 후 OBS에 이전 브라우저 소스 탭이 남아 있을 수 있습니다. 소스를 닫고 다시 추가하면 가설을 확인하는 데 도움이 되지만 코드 수정을 대체하지는 않습니다. 각 업데이트 후 문제가 다시 발생하면 핸들러의 재등록 또는 이중 연결을 찾으세요.

연결 해제 지연도 고려하세요. 업데이트 시 이전 세션이 즉시 닫히지 않을 수 있습니다. 서버가 몇 초 동안 세션을 활성 상태로 간주하면 그 사이에 도착한 이벤트가 두 세션에 모두 전달될 수 있습니다. 정상적인 서버 로직은 비활성 연결을 제거하고 페이지가 닫힌 후 구독을 남기지 않아야 합니다.

하나의 이벤트 중복 전송 방지

브라우저 소스가 올바르게 작동하더라도 하나의 이벤트가 때때로 다시 전송될 수 있습니다. 연결 복구, 메시지 재전송, 또는 이벤트 수신과 처리 확인 사이의 오류 시 이러한 일이 발생할 수 있습니다. 따라서 알림 핸들러는 반복에 강해야 합니다.

가장 좋은 방법은 후원의 고유 식별자를 확인하는 것입니다. 이벤트를 큐에 배치하기 전에 해당 식별자를 이미 처리된 이벤트 집합에 저장하세요. 해당 식별자가 이미 나타났다면 반복을 건너뛰어야 합니다. 목록이 무한정 커지지 않도록 제한된 시간 동안만 저장해야 합니다.

이를 위해 금액, 보낸 사람 이름 또는 메시지 텍스트만 사용하지 마세요. 두 개의 다른 후원이 동일한 데이터를 가질 수 있습니다. 시간 확인도 신뢰할 수 없습니다. 여러 개의 다른 후원이 거의 동시에 도착할 수 있기 때문입니다. 식별자가 없는 경우 임시로 필드 조합과 시간을 비교할 수 있지만 이는 두 이벤트를 잘못 병합할 위험이 있는 대체 방법입니다.

중복 방지는 애니메이션 내부가 아니라 알림 표시 이전에 위치해야 합니다. 그렇지 않으면 두 번째 호출이 여전히 페이지에 요소를 추가하거나 소리를 재생하거나 큐에 또 다른 항목을 넣을 것입니다. 큐를 별도로 제어하세요. 하나의 이벤트는 한 번만 큐에 추가되어야 하며, 반복 호출이 두 번째 독립 큐를 시작해서는 안 됩니다.

이벤트가 여러 탭이나 컴포넌트 사이에서 전달되는 경우 여러 수신자가 동시에 처리하지 않는지 확인하세요. 하나의 공통 메시지 채널이 여러 핸들러에 연결될 수 있습니다. 이 경우 하나의 소비자만 남기거나 어떤 컴포넌트가 알림 표시를 담당하는지 명시적으로 정의해야 합니다.

캐시 정리가 항상 도움이 되지 않는 이유

브라우저 소스 업데이트 후 캐시를 지우라는 조언을 자주 받습니다. 이는 이전 버전의 스크립트가 로드된 경우 상황을 해결할 수 있지만, 캐시는 이미 실행 중인 페이지의 불필요한 핸들러를 제거하지 않고 소스의 두 번째 사본을 닫지도 않습니다. 각 재연결 후 중복이 지속적으로 반복되면 원인은 거의 확실히 연결 로직이나 장면 구조에 있습니다.

실제로 새 버전의 파일이 로드되는지 확인하세요. 리소스 주소를 임시로 변경하거나 제공된 업데이트 메커니즘을 사용한 다음 브라우저 소스를 다시 시작하세요. 그런 다음 하나의 창과 하나의 소스 인스턴스로 테스트를 다시 실행하세요. 링크에 임의의 매개변수를 지속적으로 추가하지 마세요. 이는 많은 캐시 변형을 생성하고 진단을 복잡하게 만들 수 있습니다.

중간 캐시나 서비스 워커를 사용하는 경우에도 오래된 스크립트를 제공할 수 있습니다. 이 경우 로드된 파일의 버전과 예상하는 버전을 비교하세요. 그러나 오래된 파일의 경우에도 재구독 원인을 제거해야 합니다. 그렇지 않으면 다음 업데이트 후에 문제가 다시 발생합니다.

알림 코드에서 확인할 사항

먼저 socket.on, addEventListener, 연결 함수, 큐 시작이 호출되는 모든 위치를 찾으세요. 때로는 문제가 하나의 핸들러에 있지 않고 두 개의 다른 모듈이 독립적으로 donation 이벤트를 수신하고 각각 자체 표시를 시작하는 데 있습니다.

그런 다음 알림이 프레임워크를 통해 출력되는 경우 컴포넌트의 수명 주기를 확인하세요. 구독은 효과 또는 유사한 블록에 배치하고 정리 함수를 반환합니다. 이전 핸들러를 제거하지 않고 상태 업데이트마다 새 핸들러를 생성해서는 안 됩니다. 일반 JavaScript에서는 페이지 중지 시 올바르게 닫을 수 있도록 활성 소켓과 현재 핸들러에 대한 참조를 저장하는 것이 중요합니다.

재연결 타이머를 확인하세요. 새 타이머가 이전 타이머 위에서 시작되어서는 안 됩니다. 그렇지 않으면 여러 번의 연결 끊김 후 병렬 연결 시도가 생성되고 그와 함께 추가 구독이 생성됩니다. 더 이상 필요하지 않은 경우 각 타이머에 대해 clearTimeout 또는 clearInterval을 통한 정리가 필요합니다.

알림을 표시하는 코드를 별도로 살펴보세요. 동일한 객체에 대해 요소를 큐에 추가하고 동시에 표시 함수를 즉시 호출해서는 안 됩니다. 또한 요소의 상태 변경 시 애니메이션이 다시 시작되지 않는지 확인하세요. 로그에 수신 하나와 큐 항목 하나가 있는데 화면에 두 개의 알림이 표시되면 바로 여기에서 찾아야 합니다.

진단 체크리스트: 순서대로 해야 할 일

1. 브라우저 소스 URL을 별도 탭에서 열고 하나의 테스트 후원을 보내세요. OBS 외부에서 중복이 나타나는지 기록하세요.
2. 장면에 소스 인스턴스를 하나만 남기세요. 장면 복사본, 중첩 장면, 동일한 주소가 있을 수 있는 레이어를 확인하세요.
3. 수신, 큐 배치, 표시 단계에서 이벤트 식별자가 포함된 로그를 추가하세요. 이렇게 하면 객체 수가 어디에서 증가하는지 확인할 수 있습니다.
4. socket.on 및 addEventListener의 모든 호출을 찾으세요. socket.off 및 removeEventListener를 통해 동일한 함수 참조로 이전 핸들러가 제거되는지 확인하세요.
5. 재연결을 확인하세요. 이전 소켓이 닫히는지, 이전 타이머가 취소되는지, 이전 구독 위에 새 구독이 생성되지 않는지 확인하세요.
6. 큐 이전에 후원의 고유 식별자 확인을 추가한 다음 소스를 완전히 다시 시작하고 하나의 이벤트로 테스트를 반복하세요.

별도 탭에서 이벤트를 한 번 수신하는데 OBS에서 두 개의 알림을 표시하면 두 번째 소스 인스턴스나 장면 내 중복을 찾으세요. 별도 탭에서 이미 이벤트가 두 번 도착하면 구독, 연결, 서버 전송을 확인하세요. 수신과 큐가 한 번만 기록되는데 화면에 두 개의 알림이 표시되면 문제는 시각적 레이어에 있습니다.